Wednesday, February 22, 2017

Stop Starting, Start Finishing

In a previous post I told the story of how we reduced our bottlenecks when I was working on two teams last year, and how we achieved to deliver the highest priority items first to our users. How? Both teams agreed to "stop starting, start finishing". To not pull any new story before you could not contribute to in progress stories anymore.

This lean approach worked so well! Unfortunately only until I handed over my second team to another tester. As soon as I returned full-time to my original product, the whole team fell back into old habits, starting work on new tickets while other tickets of higher priority were still in progress. At one point we even had a totally underestimated story which turned out to be an epic of its own; we dragged it from sprint to sprint and heavily struggled to finish it. Not that the team members did not want to support, but support was only provided on demand. With "on demand" meaning that you had to actively ask for it.

Beginning of this year, we faced long feedback cycles again. Too long for our liking. New features waited for input from our Product Owner. Code waited to be reviewed. Topics to test piled up. The situation wasn't too bad, but we felt things could be much faster and we generally should avoid to have half-finished tickets lying around, not providing value to anybody. So what caused this situation again? Sometimes the long waiting times were due to the fact that many of us are also involved in company-wide topics of our FlixTech organization, for instance to support our new chapter structure or recruiting new team members. At other times people just grabbed new topics to work on; not having bad intentions, but just being eager to work on something new.

In our sprint retrospective two weeks ago, we brainstormed ways to shorten our feedback cycle again. And came up with the same well-known approach which had already worked so well for us last year: Stop starting, start finishing. Whenever you finish something and have free capacity, ask the whole team if you can support someone else with their current work. Only if you really cannot support anybody, pull a new ticket. And now actually adhere to it!

The past sprint proved once more that this whole-team approach is highly valuable. The sprint went so smoothly, tickets never waited long for feedback and could be delivered to our users as soon as possible. We completed all of our highest priority topics and even many more smaller items on top. Team collaboration felt great and everybody was really supportive. It just worked; even though I could not cover testing for a whole week due to a lot of other important topics like recruiting interviews and the two workshop days with our users (it almost felt like I've been on vacation). My programmer teammates took over testing thoroughly, asking me for advice whenever needed, but proving they already learned a lot about testing. Simply awesome. So proud.

Maybe it's too soon to be proud, as we only adhered to this approach (again) for one sprint. What makes me think that this time is different is the following: No one waited for someone else asking for support. Everybody actively asked if they could support anybody and readily provided that support until the related ticket had been finished. We all agreed that the sprint went really well and we want to stick with this approach. I'm full of hope.

No comments:

Post a Comment