Attention: More explication will follow.
This post is just for all the attendees of Manage Agile Conference in Berlin.
In product development with collaboration of product management, development and operations, development often is the bottleneck – represented by a funnel:
Also it is typical that the product management has more ideas than the production funnel can execute:
With something like Portfolio Kanban, the organization can make this transparent and more manageable. Nevertheless, development limits the throughput.
Often it happens that too large packages must go through the funnel, resulting in longtime blockings:
Or even worse: the development team works on several of these large packages in parallel. This results in a later delivery of work results for all parallel packages:
In my experience, this well-known problem is too seldom resolved.
What often comes on top (especially in more technical products): Developers must help product management (for proof of concept, feasibility checks, checking of ideas, …). The capacity in the funnel is reduced by this support. The effect of narrowing the funnel is later delivery. Sure, somebody will notice…
Bugs are also capacity thieves. Due to poor quality (maybe due to high pressure), the development team spends a part of the capacity to fix bugs.
This reduces the time available for delivering valuable stuff which will be delivered later. Sure, somebody will notice… Pressure will increase, which leads to poorer quality. A vicious circle.
Daily business also can narrow the production funnel.
What can we now do about it?
Of course, the first step would be to identify if our development team is affected by this and to which extent (I guess most development teams are affected).
One pillar of Agile (not only Scrum) is transparency. Provide transparency about the capacity thieves in the production funnel allows us to argue and to find solutions. How to provide this transparency? Somehow the development team must gather data about the stolen time. Maybe you have a time tracking system in place – then you must ensure accurate bookings. Or you put a sheet of paper on the wall and let everybody write down once a day the stolen time. The gross capacity also needs to be recorded.
After a reasonable period, data is transferred to a spread sheet to do the math. The data can be shown as the following examples show:
As you can see, making the graphs visible to all stakeholders, makes it easier to make decisions. It also is a good input for the team retrospective.
Another helpful practice is to reduce the number of task switches due to capacity thieves. That means, concentrate them in a timeboxed meeting or timeslot or on one team member (rotating).
Also address malfunctions of the product owner:
• Insufficient product and/or market knowledge
• Poor requirement management skills
• Poor quality of requirements
The development team’s first responsibility is to deliver and not covering malfunctions. But also try to reduce inefficiencies and increase skills in the development team.
Spending time to support product management in ideation and requirements elicitations is not necessarily bad. Early involvement may later result in less risks, clearer requirements and better mutual understanding.
By consciously taking care of the production funnel width and keeping it as clear as possible the development team can deliver better and faster.
I hope, you enjoyed my new blog article. Feedback welcome!
In one retrospective I gave the team 10 minutes for a silent brainstorming. They started writing sticky notes. As expected, after about three minutes, the writing slowed significantly down. As experienced facilitator, you have to stand this phase of low activity with all eyes focused on you, begging for salvation.
But what happened now in my retrospective? One put out his smartphone, followed by another one. I couldn`t believe it. The remaining time, I kept monitoring the situation and thought about it. When the timer bell ringed, I appreciated the participation. Then I told them about my observation. The omnipresent distraction by smartphones (and the upcoming smartwatches), resulted in a few sticky notes. The deeper engagement was sacrificed for the easy distraction – what a pity!
Here a typical activity diagram for such a situation:
In the first activity phase, participants find the obvious topics – the low hanging fruit. The first activity phase is followed by a phase of low writing activity but high brain activity. This phase is crucial for the identification of more revealing, creative, relevant, and understanding topics. This leads in most cases to more sticky notes.
However participants seek for shortening their brainwork – if consciously or not – the result is the same: Low hanging results with only little potential.
Unexperienced facilitators fall into this trap frequently by stopping the brainstorming when nobody writes anymore and all stare at them or in the air. Often they feel well because they increased the efficiency of the retro by saving a few minutes.
What are your experiences? Somebody knows more about the background? Please comment here.
During a workshop with 8 team leads and managers, I realized that in general, they all had a certain knowledge about agile and Scrum but our discussions went around details of the Scrum Roles and Artifacts.
How can I help them to come to a better understanding? Teach them? Send them websites to read? No!
How about a game? Better. Or for those who don’t like games, a workshop.
What you need:
In this way, you can let them interactively update their knowledge and understanding about Scrum.
I played it once with a very positive feedback of the participants. I will try it in future with some more teams that show similar symptoms.
BTW, this game also can be played with other documents. I especially think of “Agile Manifesto” and “Kanban Properties and Principles”.