Scrum and the art of optimizing impact of critical resources

In this post I’ll talk, based upon own experience, about how the 3 Scrum questions increase the likelihood of serendipity to happen within your team, thereby increasing the impact of your critical developer resources.

A personal anecdote

Picture by naughty architect



I’d like to start with a personal anecdote. A couple of years ago, I needed to investigate a performance regression of in a development build of one of our products. After 2-3 days of profiling our java application, investigating different scenarios, benchmarking with earlier builds, etc. I could only conclude with a desperate: I don’t know what is causing this issue. Then, at the coffee machine, I ran into a friend-colleague of mine working in another team, we exchanged some chit-chat and I complained about me not being able to find the issue. He told me he had seen something similar a year ago, he had spent 2 weeks debugging the thing, all the way till the underlying Linux file system and had finally root caused it. Turned out that switching 1 compile option did the trick. So, after this 5 minutes conversation, not only had I solved the performance regression, I got a complete in-depth explanation of the root cause, effects and why our performance is impacted. It would have taken me days, if not weeks to figure that out on my own, while a 5 minute talk at the coffee machine fixed the issue! If only I had known that someone already encountered this problem and fixed it.

 

Impact of critical resources in software engineering

Software engineering is extremely knowledge intensive. Moreover, the difference in productivity of a good programmer vs. an average programmer is 10 to 1 compared to a 2-3 to 1 ratio in traditional engineering (check e.g. http://en.wikipedia.org/wiki/The_Mythical_Man-Month and http://philip.greenspun.com/ancient-history/managing-software-engineers for more background). Having access to an expert, even for only a brief moment in time can dramatically change the course of your software project, as my above anecdote illustrates. If you know in advance at what time and on what occasion you need to consult a subject matter expert (a critical resource for that matter), you make sure you plan for that. Due to the complex nature of software engineering, you often cannot plan that, you often don’t even know who to talk to in your organization. Still, being able to optimize the impact of your good programmers (your critical resources) is key in software engineering. Serendipity, i.e. fortunate coincidences, is how those leverage effects are often created.

In this piece I'll have a quick look on how Scrum and more specifically the daily standup and its three questions create an environment for serendipity to happen, thereby leveraging on your expert resources to create better solutions more efficiently. In a later post, I’ll talk about how to scale this beyond one team

The daily standup - Serendipity at play

Picture by digiarnie



One of the core practices being used in Scrum is the daily stand-up. The developers gather each day for a stand-up meeting where they answer 3 questions:

• What did I do since last 24h?
• What will I do the next 24h?
• What is blocking me?

By answering these three questions, the team members create a great deal of transparency between them. Information is shared on the progress, the upcoming work and what is blocking them. This last question is a formal request for "expert" help. When blocked, a team member will try to help out, pairs might be formed to work together on the blocking issue, or the Scrum master will take up the impediment and will start looking for help outside of the team. In doing so, the impact of critical resources (typically, the people that know the answer or that can help) is improved.



Answering the other two questions the team members decide who is best placed to work an a particular story, based on interest and knowledge. This in itself is already a form of optimizing the impact of critical resources. But there is more: another interesting thing is happening, one I witnessed myself numerous times in the different Scrum teams I was a part of. Answering the two first questions often creates serendipity to happen: one team member stating he/she will be working on story xyz, other team members making quick remarks (don't forget this, you should check that, let's work together on this one, I already did something similar, etc...). Sometimes these small interventions effectively reduce the time to develop the new story,  remind me of some subtle technical trickery I needed to take into account (without which I would have introduced bugs in the system)  or even help me come up with much better solutions then originally envisioned. This way, the knowledge and experience of the team members is leveraged. In my experience, these serendipitous interactions tend to happen quite often thanks to the 3 Scrum questions .



To conclude, within the team, using the daily stand-up and the 3 questions Scrum suggests work very well to create an atmosphere where you optimize the impact of your critical developer resources. As my example anecdote pointed out though, it is not trivial to create this effect beyond your team. I’ll go into more detail in a follow up post.

Your thoughts

I'm curious to see what you are thinking about this? Do you share the same experience that the three Scrum questions are a good way to enhance serendipity in your team, leading to better products or faster implementations? Do you have anecdotes to share where thanks to the three questions during the daily stand-up you came to better use of your expert resources?

I’m looking forward to your comments.

Nick Boucart works as a technology advisor for the software engineering group of Sirris, the collective center for the Belgian technology industry. The Software Engineering group focuses on the challenges faced by Belgian software intensive product builders. The group conducts industry driven research around those challenges and actively participates in different (international) research projects on topics like flexible software development, managing product variability and software innovation. Nick’s focus is mostly on flexible and agile software development and on community driven innovation for software intensive product builders. You can follow Nick on Twitter (@NickBoucart).