Matthias Bohlen visited us on September the 15th and gave us some Feedback on our process. He reminded us as well about the core ideas ob Kanban (看板) and what we can improve.

1. visualize the workflow
   • we are doing it with our kanban board
2. limit the work in progress
   • also done.
   • low limits encourage collaboration (but might create bottlenecks).
3. measure and manage flow
   • cycle time: from starting the work on an item till it is done.
   • lead time: from a customer request to the deployment of the feature.
   • we are even measuring more but we can improve on the visibility of this metrics.
4. make process policies explicit (and as visible as possible)
   • know when a card may be pulled
   • priorities of the stories
   • explicit process steps
5. improve collaboratively using models
   • theory of constraints: look out for bottlenecks
   • W. Edwards. Deming: System of profound knowledge with its 14 key principles

Side notes:

Little's law (1961) cycle_time = work_in_progress / throughput In our case: 2.5 days = 3 stories / 1.2 (stories/day)

Allen-Cunneen formula (simplified variant) length_of_the_queue = rho^2 / (1-rho) where rho is the utilization of the system rho = arrival_rate / departure_rate

• We had already put a priority on the first column (analysis of the stories), somewhat stretching the pull-principle. The reason was that the second column (development) was starving a few times. The standard solution would have been to increase the WIP limit (from 1 story to 2 stories).
• The standard solution for queues building up before a bottleneck is to elevate the bottleneck, e.g. following the five focusing steps. In our case tasks were piling up before the done column for stories in development.
  • The bottleneck can always be found on the right side of the queue, as everything piles up in front of the obstacle and not after it.
  • After examining the board more closely we found out that the real bottleneck was not clearly represented on the board: It is mainly the transition from the story with all its tasks to the done column.
  • So, getting a big story really “done” seems to be hard for us. We saw the problems of the size of the story (bigger than the others) and the dependencies between the tasks. (There are theoretical results on how the batch size and the variation in the batch size influences the flow.)
  • Matthias elaborated the five focusing steps a bit more: See bellow: five focusing steps
  • Tips to get a story smaller: http://xp123.com/articles/twenty-ways-to-split-stories/¹⁾
• We already knew that real feedback is at the heart of Agile. Matthias gave us two pointers that elaborate the central role of learning:
  • Dan North, "Deliberate discovery": Focus on building knowledge about what you know least.
  • The WIP-Limits give an opportunity to meet a kaizen moment (改善). It might be a very difficult situation if the team hits the limit, but after solving the situation people tend to feel stronger.
• Matthias asked us whether there are special stories that e.g. need to meet some deadline. We found two:
  • Somehow the “story” of preparing the weekly presentation/demo was a story of this kind.
  • Another categorization (that was not made explicit yet) was the distinction of general Cultivate stories and the Android-specific stories. We later on acted on this by using green story cards for Android-stories.
  • Team and customer could create a Service-Level-Agreement (like: For stories with a deadline a specific capacity could be allocated, so that they are guaranteed to be done in time.²⁾

1. Identify: Done, see above.
2. Decide how to exploit: The constraint is the transition to “Done”. It could be better “exploited” by defining smaller stories. As a result the problem will be smaller.
3. Subordinate to the above decision: Let only as much stories through so that they can take this transition easily. This is already done by Kanban by the WIP limits. They propagate a signal to the front, to stop work that would not go through the bottleneck.
4. Elevate: Now we should think how the bottleneck character could be removed from the “Done” column. For example the developers could think of themselves as surgeons: Open a wound, do the surgery, close the wound. And, this perspective should be taken for each task! As a result the effort for “integrating so many tasks to a whole story” can not be so heavy anymore. Mocking could be another way to reduce the dependencies between the tasks.
5. Rinse and repeat. Stay flexible.