Monthly Archives: July 2017

Keep the production funnel free

In product development with collaboration of product management, development and operations, development often is the bottleneck – represented by a funnel:

funnel_blank-1024

Also it is typical that the product management has more ideas than the production funnel can execute:

funnel_pm-1024

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:

large_tasks1

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:

large_tasks2

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…

funnel_reduced1-1024

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.

funnel_reduced2-1024

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.

table_tracking

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:

graph

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!