One of the first things I was told when I became a Scrum Master is that you need to allow a team to make mistakes and learn from those mistakes themselves. Don’t step in and catch them. This is an easy thing to say if you are teaching how to create a self organising team, but I’ve always found it a more difficult thing to do in practice.

This has regularly been on my mind but it recently became a lot more relevant. I had a team that had been together for about 6 months. We were doing OK but we hadn’t yet got to what I’d think of as high performing. We had a complex system with a number of different work-streams with different systems and tech stacks. We were consistently getting through most of our sprint but then not finishing circa 20% which was regularly on one particular tech stack/work-stream.

Then one week we had a curb ball thrown at us…. another team upgraded our AEM instance – havoc. Our dev environments all needed upgrading in a relatively unplanned way, our QA environments stopped working, our QAs were taken off the team to help with the upgrade, our releases to prod were blocked and we started to get a back-up of branches waiting to be merged… causing ongoing pain for weeks ahead. And the team stopped. They didn’t actually stop – they were still all hard at work, but we weren’t really getting through anything new and we weren’t clearing the decks. Even after the main blockers were resolved we had so much work open, being re-merged and tested, that it felt like we were just treading water.

This really magnified to us and to the wider business some of the issues we were having on the team. We already had one work-stream that we were struggling to get live. When our AEM work-stream ground to a halt suddenly it made it very obvious how much the other areas were having difficulty.

Take a long hard look in the mirror

It was at this point that I took a step back and tried to understand some of the issues we’d been having, and what affect I’d had on them. I realised that mainly I had been cushioning the team. I had been able to keep the wolf from the door and explain why projects had run on – a more questionable skill that most PMs have in spades after a few years on the job. And I had been running more of the process for the team without really having the by-in from them. We had in effect been running through the motions but we were not all running towards the same goal. I broke these lessons down into three main improvement points:

  • The team never heard from the business about why they needed certain things out for certain seasons and deadlines. I tended to take all these conversations in myself and didn’t tend to push the team myself on hard deadlines. Some of the team and wider department were also what I might describe as ‘anti-deadline’ and so the hard realities of delivery were very difficult conversations to have. This meant they weren’t really aware of the effects of not getting work out and so weren’t either bought into certain priorities and weren’t able to think strategically about their programming decisions.
  • I don’t like to be too process focused. Just saying ‘no’ and blindly following a process doesn’t seem sensible. But in this circumstance this meant the team didn’t always know the rules of the game. They had set the rules they worked to, but by allowing these rules to be bent too often, I had unwittingly not been structured enough for the guys to always know where they stood. So they were more reliant on me than they should have been.
  • We didn’t have a common agreement on what we were trying to achieve. The team is very multi-cultured as well as coming from very different working environments. We were all talking about aims such as continuous delivery, but this is an expansive topic and can mean all sorts of things to different people. We all had in our minds a clear view of what good looked like and even though we’d done a Kata and other team sessions to run through it, we still weren’t running in the same direction.

Learning To Be Mean

So what did I do?

The main thing I did felt like I was being a lot harder on the team. With self-organisation comes responsibility, and I hadn’t given them the responsibility. So I let them hear that getting working software to the business was important to the business, delays in delivery have negative consequences, and that we needed to change how we were working to improve work-streams where we weren’t delivering.

The next thing I did was be a lot tighter on process and give a stronger structure. I wrote out the sprint process as we currently had it understood. I actually insisted on tech tasks for a few sprints, and changed the board so that the tech tasks where more prominent. The board style was a massive fail with the team and was changed a sprint later, but the tech tasks did give us more detail and stopped us missing things.

Lastly I tried to give a stronger direction of where we were trying to go. With a stronger team agreement on some of the testing and continuous integration strategies we were putting in place.

What did the team do? Stepped Up

The first few sprints were hard. I was deliberately being a lot stronger and more opinionated than normal, and I was giving the guys bad news more than previously. It felt a little counter-intuitive for a scrum master and I was questioning whether it was the right decision.

But each retrospective was filled with considered ideas of how to improve and a lot of discussion, and this was a good sign. After a few sprints we had cleared through the backlog of work and when we brought in new work the team had a lot stronger opinions on how that work should be shaped and completed. The discussion had more voices and there seemed to be a greater shared understanding of what we were trying to achieve and motivation to achieve it.

I should make a note here that the team deserve a lot of kudos for this. I had a lot of difficult conversations over this period and at times morale was low. The guys very much took this on the chin and worked hard to change things for the better. With a different team I may well not have chosen to take this approach, it was only because they were all so diligent and close working that I could talk to them in such frank ways.

And all it took was for us to crash and burn for a sprint or two

Finally, I stepped back and the team ran a sprint without me to great affect. The velocity of each sprint began to increase considerably (twice as much as before the velocity crash, not accounting for some resource changes) and the top issues coming out of retrospective started to revolve around not having enough work ready for sprint planning. The tech bottleneck had gone and the bottleneck was now further up the delivery cycle. And all it took was for the team to crash and burn for a sprint or two.

 

 

Advertisements