Coding, Managing and Christianity

WIP Power

I’m on my way to work and today starts a new sprint, which means we plan it, but also review the statistics and results of the last sprint. I haven’t looked at the numbers yet, but they will be good. We got all, or at at least almost all of the planned work done. That would be now the 4th good sprint in a row and last week we went for a beer after work to celebrate the successful three prior sprints.

A few month ago it had looked very different. I dreaded to compile the numbers, because I knew that we hadn’t made it again. I was getting frustrated with my team; frustrated and overly critical when mistakes were made. It was obvious the team was buffering estimates and they were reluctant to take any risks. It was almost like they were afraid committing to anything. I thought about a reward system, or one could also say penalty system, when they didn’t make it. I looked at individual metrics to see who the problem is. - Doesn’t the Bible say “in humility consider other better than yourself”? I should have started with myself.

I learned one thing from the statistics - that we spent a lot of time with support and unplanned work. So far our practice was that we look at any incoming support request right away, because we really don’t have that many and they are usually quick to deal with. The thinking was: Rather than building a backlog, we might as well deal with it. I missed to see that things had changed. That is the old story of the frog in the pot of water, who doesn’t notice that he gets boiled, because the temperature increases steadily but slowly. It was the same for us. We didn’t notice it, because we were right in it. We have a data collection service and the system is mainly used by two analysts. However, they are very new in their role and since they had started the support requests coming from them skyrocketed. All the issues, or perceived issues were eating up to 40% of our capacity. So we had to change how we handle support. Requests go now to a smaller group, will be triaged and only a real emergency goes to the group. All other tickets go in the backlog and will be prioritized, estimated and planned for a sprint.

The sprint planning was another problem. Each time I pushed for overbooking, assuming that if I plan for 120%, I’ll get at least 90%. Well, I did not. Around that time we got a new product owner and she reminded me of what I learned a while ago: Limit the Work in Progress (WIP). That was the 2nd change. Since then we have been planning sprints to our capacity and stayed away from overbooking. We also set a limit on the “In-Progress” queue that now turns red in Jira when too many items are in progress. It should not have been a surprise that things went better from there on.

The final change was my attitude. I took a scrum meeting and apologized for my negative point of few. I spent a little time sharing what I value about each member of my team and vowed to be more focused on the positive. I will probably never be a cheerleader, but I can highlight what went well. If something does not go well, I can facilitate that we learn from it and move on. I also will stay away from cynicism, which seems to be my default response when I’m frustrated. Instead I will try to share my frustration in an “I” statement.

While all three changes were important and contributed to a better climate and higher productivity, I believe the biggest factor was limiting the WIP, hence the title and idea for this post. I would be curious to hear what experiences other development leaders have made with limiting the work in progress.