One of the biggest questions about this experiment has been ‘who’s doing the testing?’ I, as a full time tester, quit that to be the scrum master, right? And we only had the one tester on our squad. I don’t recommend dropping your tester in favour of a scrum master, a tester is a vital part of the team and they have experience, training and knowledge that you can’t just spread over the team. In this case, it just happened to be a tester who wanted to try out being a scrum master, and after the experiment we’re hoping to have a full time tester again to ensure testing is valued, executed to a high quality and to write and maintain automation.
The quality and speed of our testing wasn’t going to suffer over the experiment, this was a mission I gave myself. Since the testing would be spread between our designer and our developers it was up to me to ensure they knew what they were doing.
I ran a couple of ‘test 101’ sessions with the squad. I covered basics which would get them testing quickly:
Context driven testing
Basics of how to write a test plan
Happy path testing
Keeping scope small ( linked to CDT)
Recording what you’ve done
I ran the sessions informally, just two people and me. We had some paper to draw things on, such as happy path flow charts or mind maps. I brought my laptop to show previous test plans to refer to, or show off our tools and processes. It was interactive, in all sessions there were lots of questions and answers. Often the questions would bring up an opportunity for insight into another facet of testing I hadn’t considered. We covered whatever came up, and kept it under an hour.
Here are the benefits of minimal, up-front coaching:
Fast start, can pick up test cases right away
They can find gaps themselves
They come to me with random questions as they come up
New learning as it’s relevant
You learn better from doing
Less pressure to be perfect right away
When cases came up to be tested, I paired with whoever was doing the testing. Letting them ‘drive’ the mouse and the computer, and offering tips as they went through it. I buddied people through deploys. The highlight was buddying a developer leading a group deploy and three other members of the team were watching the process. It was great for increasing interaction and teamwork! The whole team got involved in deploying a change, it made it quite exciting.
The team dove into testing with me reviewing their test plans and giving advice. I paired up with them when they needed it, made myself available to answer questions and share blog posts and information as it came up.
We ran into some issues initially:
Access to various aspects of the database and test tools was restricted by the business. It wasn’t too much of a problem for our developers but our designer was locked out of some of the processes. We had to raise issues with our IT helpdesk and then wait for the request to get to the top of the queue.
Our designer was excited to learn how to test and also didn’t happen to have too much else on, so she dived into it. There was a temptation from the developers then to keep on developing and give the testing to the designer. This was the opposite of what I wanted, because it took our designer away from her design work and it put a lot of pressure on her.
We got around this by reminding everyone to test things in daily stand up, and by introducing a Work In Progress limit to our ‘doing’ column. That way if someone wanted to start something new into the sprint, they had to first test something that was already developed and ready for test.
As a follow up to the test 101 sessions I’d run, I assigned ‘homework’. I pulled stories from our backlog which had good acceptance criteria and gave them to people to write test plans for. They had no time pressure because these were stories which weren’t immediately going to be brought into the sprints. I encouraged them to team up to write the test plans, and to ask any questions they had. Then when they were happy with them, they flicked them back to me to ‘mark’. It was a lot of fun!
The first thing I had to do to prepare for this full time scrum master role was learn the crap out of it.
Let’s be clear on something: I love to learn. I studied English literature, psychology and women’s studies in university. I love to learn about the way humans think, what motivates us, and if I learn something about myself along the way, that’s even better. This part of the process was a joy to me, which is great because when something’s a joy you work harder and get more out of it.
I had a couple of questions:
What is agile?
Why do we use it?
What is the purpose of a scrum master?
What should I be doing every day?
I went through the training courses here on Growing Agile. Starting with the exploration of Agile’s foundation tenets, and why it’s useful. Then I started the Advanced Scrum Master training courses. (Which are amazing by the way *not sponsored content). I especially loved the ‘becoming a servant leader’ one. Start with Basics of Scrum
I read the executive summary of a book called The First 90 Days by Michael D. Watkins. It had insight into ways to be effective in my new role.
My main takeaways were:
Learn as much as possible
Consider my vulnerabilities
Look for the unexploited opportunities for growth
Find early wins
I also checked in with a few people. I had a one on one with the head of agile for our office. I asked him: If you had all the time in the world to do scrum master tasks, what would your priorities be?
His suggestions were:
Velocity reporting: to show that having a full time scrum master is worthwhile
Work on facilitation skills
Reporting back on the experiment happens at many levels: to the company, to the squad, to the agile guild
Ensure retros are productive
Record cycle times: this way you can streamline your grooming process. The ideal being all the stories are the same size.
His ultimate message to me though was to fix things from the bottom, then work up.
I chatted with scrum masters throughout the office (people working the role part time alongside their regular jobs). I talked through some challenges they were seeing. I sat in on other teams’ daily stand ups, groomings and sprint plannings, making notes to myself on what worked and what didn’t. Where it felt like people were empowered to speak and when it felt stilted.
I also agreed to a lot of things. Someone came to me at 12.10pm, as I was thinking of having lunch and asked me to run a retro for his guild. The retro was at 1pm. I said sure and I facilitated a retro for a guild I wasn’t involved in, bubbling up a lot of problems and some possible solutions.
I ran a meeting for brainstorming ideas and solutions for the sales and operations side of my business unit. Drilling into the many personas that they use for marketing and thinking up new ways of using them. I agreed to be observed during this session and had an in depth one on one afterwards about how it went.
I co-facilitated a squad kick off and an agile clinic, and I did a talk to the test guild about the whole experiment.
In short, I took any opportunity I could to learn, and to get feedback on how to improve. I had to work at this, it’s hard to be vulnerable and take criticism. It’s hard to put yourself out there. But I needed to it, so that I could grow and improve.
Then, of course, there were blog posts and Ted talks, which I made copious notes on. Those all led me to other blog posts, other Ted talks and more learnings. I’ll link a few of my favourites below, but first I’ll wrap up. In some ways it felt like I was getting away with something, to spend work time learning. Especially when I was watching Ted talks. But the fact is, it’s very effective way to learn and I got some real insights. The great thing was when I noticed the same messages and conclusions coming up over and over again. I can recognise that something failed in a meeting I facilitated because I’ve read about meetings so much. I can see when people need help because I’ve watched talks about vulnerabilities or uninspired workers. Knowing that I have those skills is invaluable.
My learning all this stuff about processes means I can apply it to my team. They don’t have to study for hours, because I’ve done it for them. They can get on with their jobs and I can work on making the things around them more efficient, and encourage better team dynamics.
Learning is awesome, do it more!
Here’s some of the highlights. I’m sure there’s a bunch of great ones I’ve missed as well, share your favourites in the comments maybe?
I’m a tester in a small delivery squad at Trade Me. Karen joined our team four months ago as a Product Delivery Manager and in this role she’s the person I report to. She was confused about Trade Me’s lack of dedicated scrum masters. Together we started an experiment to change things. This is the first in a series of blogs documenting one person’s deep dive into an agile experiment.
What was the challenge ?
I’d expressed interest in leadership and agile practises before. But as a tester in a busy squad, I was usually bogged down with the day to day testing work and ended up being a tester who sometimes ran meetings.
One day at our regular one on one catch up, Karen suggested I trial being a full time scrum master for six weeks.
This was confusing, because it wasn’t something I’d ever heard of anyone doing at Trade Me before. The idea was intriguing, but I didn’t know if she’d be allowed to try it. That I’d be allowed to try it. I didn’t understand how or if it would work. Karen, of course, has done this before, and knew that it was generally beneficial.
I was into the idea, but to make it happen we needed a few key things:
Support from the delivery team
Make sure test practices as established at Trade Me aren’t ignored
Support from the wider test guild
Courage to take it seriously
Support from the delivery team
I’m a senior tester, and the only tester on the team. If I switch roles the rest of the team had to be willing to take over the testing.
To find out if this was something they’d be keen on we floated the idea at a team retro. I’m lucky that this team is a high trust one. They’re supportive of people following their passions and trying new things.
We agreed that everyone would do a little testing. I’d be around to coach, guide and give support but that I wouldn’t do any testing on my own.
Make sure test practices as established at Trade Me aren’t ignored
In the past test practices at Trade Me has been locked down. Only testers were allowed to deploy things, for example. But in the last few years things have relaxed. I checked in with the Head of Test Practices to ensure that we wouldn’t be stepping on any toes. He was fine with it. “As long as someone is there for deploys, it doesn’t matter who.”
I made it a mission to ensure that the team understood the wider context of Trade Me testing. With particular focus on security, risk and quality of the code we were delivering.
Support from the wider test guild
Trade Me has a ‘two weeks in testing’ meeting. A representative from test in each business unit is present. The agenda is open anyone can add anything new or interesting and spend a couple of minutes talking about it. One my first day as a full time scrum master I went to this meeting and told everyone about the experiment.
“So you’ll all understand if you see some unfamiliar names in deploy chats or in test environments,” I said.
“What names should we be looking for?” A tester in another office asked. “In case they need help and we can give them some extra support.”
You know that bit in the Grinch Who Stole Christmas where the Grinch’s heart grows three sizes? That’s how I felt. Not only were the wider test team okay with the idea that my team would be testing, they wanted to support them. It was a huge vote of confidence.
My main guideline was to stop testing. To resist the urge to take a case here or there, and to step back and let the team work.
I would learn as much as I could about processes, scrum, team building and how to make a team successful.
I also wanted to make my progress visible by highlighting new processes and ideas to the team.
Courage to take it seriously
This was a personal challenge for me. I’d been a scrum master before, but only alongside also being a tester. It was hard to find time to explore what I could do as a scrum master, and I’d end up being a tester who sometimes ran some meetings.
To get the most out of the experiment, I had to take it seriously. Learn all I could and throw myself into the role.
To start with, I decided to journal the process. Every day I’d write some reflections on how the day had gone, what I’d learned and how I was feeling. This was a commitment to myself to do my best. It would also be useful when reporting back to the team, my boss and the company on how the experiment had gone.
Adding a scrum master swim lane to our team board helped me be accountable with what I was doing. It helped my clarify my to do list, and it let the team know what I was busy with.
I also tried to say yes more.
When asked to do a retro for another guild with less than an hour’s notice, I said yes. When the opportunity to facilitate a squad kick off for a team in another business unit came up, I said yes. I took the opportunity to be observed running a meeting so I could learn where my weaknesses were.
With my various ducks lined up, I dived into the experiment and became a full time scrum master.
I’ve got a series of blog posts about the challenges, learnings and surprises I encountered, so stay tuned!
We all know the benefits of teams. A bunch of people who work together over long periods of time and are fairly stable. They grow together and learn together and the team is worth more than the sum of the individuals. IF you’ve worked in one of these teams – you will know what I’m speaking about. It feels amazing.
However in most companies this idea of stable teams seems like an impossibility. People (often referred to as resources) are shifted all over like chess pieces not allowing time for the goodness of teams to grow. There is much that we as agile coaches can do here. I believe teams are possible in just about any environment – but it does require a very different mindset. We could also argue the point that if the word resources is used, is that company truly agile?
Ok… I hear you. For the sake of this blog post I’m going to put on a different lens.
I once worked with a tiny company, around 20 people. They worked for various clients on an hourly billing case. Every project the people were mixed and mashed into new teams, depending on what the client/project needed doing and who was available. The big thing for me here was that it WORKED. Sure they had problems. But when it came to team work – they were solid. This is what is called teaming. Forming haphazard teams and working together well and then disbanding.
So what did this little company do differently? Well they really focused on building trust between everyone. They played games in the office (board games) and regularly went out to lunch together – think once a week at least. They often went for drinks and coffee. Most weekends – they would hangout. Not everyone together, but in little groups. They all became friends. When they shifted teams, they were sad to leave their team buddies but also excited to work with other friends. They wouldn’t stick to their team for code reviews – everyone and anyone in the office could do this. Once a week they had a “formal” get together to show what they were busy with.
I also recently worked with an even smaller company of 10. Of this 8 were developers. We were running Scrum, but a fairly lose interpretation. The team would plan together and understand the work together. And then as they were committing they would form smaller teams for each story, 2 to 3 people. We called this a micro-team. The micro-team could work in any way they wanted, and in the daily stand-up they would explain their progress to the other micro-teams. If a team needed help they could ask anyone. This allowed them to partner with developers with the right skills for that problem and to also have someone working closely with them. One thing we watched out for and called out was favorites. You could only micro-team with the same people twice in a row – then you had to mix it up.
You might see flavors of pairing and mobbing in the above two stories. Now I have a new term “TEAMING”.
So with this new lens on, look around, to your left and your right. How can you figure out your team mates best skills and use them and your skills in the best way possible?
Bob has just completed a task. His task was to create the test case for a successful credit card transaction. He moves the task into ShowMe and finds someone on his team. In 5 minutes Bob has showed Julia (a developer on his team) his test case and made a few modifications based on feedback from Julia. The task can now move to done.
The ShowMe column promotes understanding and cross-skilling in a team. The ShowMe is for the person who completed the task. It is based on the rubber duck theory, that explaining what you have done out loud to someone (or thing) else will highlight most of the problems immediately.
We find more and more people today are working remotely as companies become global and people are prioritising flexibility. So we thought we’d find out a bit more about this. We’ve had remote meetings which were painful, and we’ve also had ones that were hugely successful, enjoyable and engaging! We were interested to hear what others are doing: how and why they work remotely. So we ran a survey to get a better understanding of how people were doing agile remotely across the world. If you haven’t yet filled it in, please do so, we might update the report in the future if we get more data.
If you’ve never experienced a remote meeting that works feel free to join our Virtual Lean Coffee meetup to see how we run Lean Coffee with people from around the world. Or get in touch via and we will facilitate a remote workshop with your team for free.
We use ‘remote’ and ‘distributed’ to mean at least one member of your team is not sitting within 6 m of all other members. Here is an infographic of the survey results, or you can access it here: https://infogram.com/remote_team_survey_results.
Recently we attended the SUGSA Coaching Day where we presented a session on Coaching Tools. In preparation for this we did a silent brainstorm. When we say ‘tools’ we mean anything that can help you be a better coach. We quickly came up with 33 tools that we think help us be better coaches. We ran the session as an informal sit in a circle and pick a card, then we explained the card and for topics some ran a quick activity for participants to practice. There were some great conversations and debates – thank you everyone!
You can download these cards below. Perhaps print them out, and write your thoughts for each topic on the paper. Some of them are vague – so feel free to leave a comment for us to explain. If you are a coach – please let us know if there are any you would add.
Some tweets from the event:
“1 thing is a potential option, 2 is a dilemma, 3 is a choice – use powerful questions to open up choices”
“People vs. Objects – If you are going to coach people, you have to give trust continuously, over and over again”
“Work on yourself until you can see that ‘Problem’ person in your team as a person, because that person knows how you see them”
“”What’s the behavior you are modeling to your team?” If you want ppl to admit their mistakes,start admitting yours.”
“Being right versus the best outcome”
“Let’s stop talking about whether we’re Agile or not and start talking about what’s working and what’s not.”