Two tricks that boosted our development productivity in three days

In the past few years, I’ve seen some scrum teams and always felt that something was amiss. On the surface it looked good: they filled in the roles, held the events just as described in the scrum guide but at the end, they could not look more transparent, predictable and productive than traditional development teams.

I am a founder at Samebug. We applied scrum since we grew our team to 9 and I had the same uncomfortable feeling for a few weeks until an experienced scrum master joined us. He made a few changes that in a short time improved a lot. I was glad of seeing this improvement for a while then felt a little dissatisfied again. Here are a few reasons.

On the sprint planning meetings, the team always committed to just a couple of stories: much less than I expected to. If you think I am too greedy, that’s ok. I run a startup, I need to get results before we run out of funds, so I am impatient.

During the sprints, I was not able to feel the progress. The stories got broken up to tons of task cards that moved almost daily, but it is hard to know if we came closer to the goals or not.

On the daily scrums, I did not feel that the team was breaking through their obstacles. It was more like a status report to each other without the goals being reached.

I have seen the implemented features first on the sprint review demos which were too late to make changes and it was not the result I envisioned. I did my best to define the vision more precisely without any more success.

Please don’t misunderstand me. The team did a great job implementing what I asked them, but we still progressed much slower than we needed. They are amazing: all talented, working hard and loving the product we are creating. However, we needed to find a way to fill this gap in order for the team to become more productive.

I applied to a Scrum Alliance Product Owner Course held by Iain McKenna. In the beginning, we had to fill up the course backlog with questions that need to be answered. After thinking through the symptoms, I mentioned before I came up with this: “how to make the team focus on goals instead of tasks”.

The same question came up many times in different forms during the course. Iain kept telling me that I have to find the reason for my behaviour. Initially, I felt it like a new age mumbo-jumbo without any helpful information.

Later he brought us a little closer: I have to add problems and questions to the backlog rather than features. Good one, but we still weren’t there.

Then he gave a great example. He set up the fire and started to tell an old story about an assembly course many years ago where he always fell asleep. The title of the was “As a trainer, I want coffee to keep the students awake”. It had a few acceptance criteria also. Iain asked us to give solutions and tell what is missing from the story. We tried hard without any real success because the story itself did not let us think. It wasn’t open for other solutions like providing tea or just finding more interesting ways to teach. After letting us struggle for a few minutes, he showed a technique I call story zooming. It looked like this:

The trick is simple: move the benefit one line up thus converting it into a goal, then fill up the advantage with something logical then give this new story to the team.

This opens up the scene for them to start thinking and give their solutions to achieve the same benefit. Since they answer, they will automatically keep the goal in focus instead of tasks that have to be completed to achieve it. (It was thanks to this that I later realised that the team also gives better goals than me.)

The course was great; I can recommend anyone who wants to be a product owner in a dynamic scrum team.

After returning from the course, I faced a different problem: we are committed to a milestone with six stories and only eighteen workdays left. I knew that for any of the stories the team would predict at least a week. It’s not because they are lazy or unmotivated: they want to ship the best possible solution — even by missing the deadline. I was determined to meet it.

I sat down with the scrum master to find a way out of this situation. We found an incredibly sounding solution: three-day sprints, one for each story. We called the team together and agreed to the following:

• We order the stories with active contribution from the team (they played investors)
• We zoom out the stories to let the team find better solutions
• We don’t break the stories down to technical tasks: there is always one card on the doing column and everyone works on that
• The team’s responsibility is to move the card to done in a day
• The team has to demonstrate shipped versions before the end of the sprint letting the team review it and give feedback
• DoD: tested, tracked, deployed to production

It wasn’t an easy switch. On the first planning meeting, the first task the team came up with was “Krisz creates a clickable prototype” that takes a few hours. I got upset and raised my voice (and still feel guilty about that). I emphasised that we agreed not to split stories into technical details. Asked them to set up a plan in an hour then everyone has to start working without waiting for each other.

In an hour we sat together watching my screen and intensively discussing the user journey using a very crude prototype that together with the working product was completely enough for everyone to understand what the user will do and how clearly. In the end, we had two one-day stories. We agreed that we do not start the second one until finishing the first.

It was easy to feel the progress during the sprint. The results without getting to the nity gritty details:

• The team finished the stories,
• Shipped daily,
• Demonstrated what they have before shipping,
• Came up with two additional stories that were needed to meet the goal,
• Shipped those ones, too;
• We got user feedback before the sprint deadline
• The team enjoyed the quick cycle

We learned a lot from the first quick sprint:

• We found the minimal (hopefully viable) solution for the problem
• It was impossible to switch to a different task while waiting for someone else — so they had to keep up the focus
• The daily scrums became reasonable — we discussed who needs what and when to get closer to the goals
• It was easy to recognize procrastinating due to long-term values
• The team felt ownership over the goals — simply because I handed it over to them using the story zooming.

I can’t tell the future from this single sprint. What I see, however, that two simple tricks amazingly changed the team’s mindset that affected in productivity immediately. They provided more value without feeling that they had to work more. They took over my impatience to see the result and get feedback from the users. We agreed to keep up this for the rest fifteen days then maybe the team will write another article about their feelings on this new process

If you have any comments or feedback on this we’d love to hear it in the comments below. If you liked this blog don’t forget to give it a clap and share it on your favourite social media.

If you want to get in touch with Iain, visit his site for contact info.