A while back I had an interesting discussion with a friend of mine. He works as a software developer, team lead actually. His team was using Scrum and most of the team members had been using Scrum for several years.
Him: “Guess what happened at work! My team didn’t finish a single item”.
Me: “What do you mean? For an entire sprint?”
Him: “Yep, two weeks and at the end we had to move every single item over to the next sprint”.
Me: “Wow! That doesn’t sound like fun”
Him: “You bet, the product owner was just sitting in his chair. My team morale is way down. Never fun to disappoint other people, and frankly I think some of my team members felt worthless because of this”.
Me: “So what did you do?”
Him: “We increased the next sprint from two weeks to three weeks thinking that would mean less overhead and give us more time to finish stuff.”
This is obviously not a fun place to be in, not delivering anything after two weeks work.
No value delivered.
The business people were slightly disappointed.
Team morale was way down.
It is also extreme. This is the only case I’ve encountered where a team of several people hadn’t accomplished anything of what they had set out to do two weeks prior. I’ve seen teams not finish part of sprint backlog, but never like this. It’s not like they were slacking of either. Every member had put in long hours and were pulling their hair out.
Seeing symptoms and from that finding the root cause is complex and not an easy task. Most often there are several factors involved and some are out of your control. For now I’m going to focus on how one would approach a problem like this. My friend’s team was thinking that less overhead of sprint planning, preparing demo, doing a demo and retrospective would give the team more time and energy to focus on the actual items. That sounds logical and can sometimes be the case. However to me that way of thinking is more in line with “traditional” management than an agile approach. My take is that, the more you are struggling the more you should reflect on why you are struggling.
The whole construction that Scrum is based on is to regularly make the entire team think about how they do things. Reflecting on how things are done, is the key to progress and improvement.
Reflecting on how things are done, is the key to progress and improvement.
The retrospective in Scrum (and the like) is there to give the team time to connect the dots from struggle to the problems and going deep enough to finding the root cause. In a team that is struggling as much as my friends I’m arguing there needs to be more of this reflection and especially more often. Shorter sprints would naturally make them do that more often by having a retrospective more often. With a shorter sprint they would also be forced to focus on fewer items and then reflect on how that went. That is the true spirit of Kaizen.
I don’t know about you but if I’m both thinking about what to make for dinner and how I should tackle that leaking roof. I’ll most likely end up ordering pizza and fixing the roof with elaborate use of duct tape and anything else I could find laying around.
This was a very narrow scenario and question. The perfect system doesn’t exist, and likewise is Scrum a process with it’s own drawbacks. However when you use a method or process there is a lot to be gained from understanding the principles it was built on and how the different parts interplay.