Post-Agile Development with Jim Benson

This month's meeting of Hamburg's Limited WIP Society took place on Nov 7 at it-agile's office. It was great to have Jim Benson (based in the US, in Seattle) a few days longer in the city, which gave us another opportunity to get in touch with him. The topic was "Post-Agile Development and Lean Coffee". (Although we didn't get to the Lean Coffee part:-)

There were appr. 25 people around who gathered in the presentation area after refreshments and networking in the kitchen. Luckily it was dark already, so we did not get too distracted by the wonderful view of the river Elbe and the harbor area. Jim first talked about his personal background, having almost graduated a study of psychology, followed by working in the transportation industry for many years. Understanding both people and flow of traffic to me sounds like the perfect qualification for a Kanban expert.

Jim used stickies to maneuver himself through his otherwise freestyle presentation in the following manner:

That worked out pretty well, as it both guided him through the session and provided flexibility to switch topics as well. Jim then talked about capacity planning. He stated that work doesn't fit, work flows. Therefore the widely used capacity model is wrong. Work flows like traffic: On a highway, when traffic flows best at up to 65% of its capacity, with more and more jams until the highway is fully utilized (100% capacity used – yay!) but traffic is stuck. In his view, a sprint is a capacity planning tool. He pointed out several flaws around Scrum's concepts of story points and velocity: The same amount of story points comprising a very different mix of stories (e.g. 20 small stories vs. one or 2 big ones) does not result in a comparable amount of work. In addition, story points are widely abused, as they are handy integer numbers (presenting what exactly?), making people and particularly managers wanting to make calculations with them (e.g. time/ money). A bit cheeky, this part resulted in the simple formula of Velocity = "an integer number" / arbitrary sprint length. He suggest standard daily question to focus on the exceptions, e.g. blockers instead of status or the three standard Scrum questions, as the status is already visual and up-to-date on the board. Most of us working with Scrum know the effect of the "sprint-end crunch time", where story completion is sped up in order to keep the commitment (which Jim doesn't seem to be a big fan of either ;). In his experience, the time before the sprint end is the one where most errors are made an quality is sacrificed (consciously or unconsciously) in order to make the promised scope. The easiest way to remember that is this kind-of-faked chart:

Jim then used the Cynefin model as a continuum of possible contexts for creating solutions to show where Scrum and Kanban fit.

• Simple - use of best practice – making toast is oretty much the same all over the world
• Complicated - use of good practices, Scrum and Kanban sit here, need a flexible working model
• Complex - emergent practices, often not apparent what is going on, need group and/ or experiment(s) to solve, then back to complicated.
• Chaotic - purely reactive mode. E.g. incidents in IT Operations are unplanned, often have a simple solution but are in the complex domain for long–term fixing.

We then had a brief discussion of longs (stickies that just sit there day over day on don't move) at the board. Jim stated that they tend to be in the complex domain, which means that they are really hard to resolve by one person alone. His tip was to spot them early, and then swarm on them! Spotting them is kind of a challenge as people tend to cover up their problems and going on and on and on on their own… He suggested watching people's expressions when putting them on the board, supported by questions like "Does any of these scare you / make you concerned?" or "Is your pulse going up?".

In order to improve your Kanban system, ask folks what the board is NOT telling you. He believes lean approaches like Kanban are easier to get across than Scrum as they bring a shared language between IT and the rest of the organization. Gradually increasing the horizontal scope of the board is a straightforward way to improve collaboration and alignment between teams or departments.

Running around his no less than 4 easels, he then demonstrated "Demand pull" - we'd better be producing what our customers want. He suggested putting more focus on demand pull rather than solely interior pull which is what most teams working with Kanban take care of.

Jim then gave us a brief glance at Personal Kanban, which he invented: You could start with a small board and 4 columns as simple like this: Ready – Planned for Today – Doing – Done. People systematically overestimate what they can get done, and he says this is a powerful tool to acknowledge this fact for one personally (often through repetition). The chance here is with minimal effort to constantly watch one's own work flow and learn from it.

As in his LKCE13 session, he stressed that people and processes are symbiotic. He introduced us to Deming' system of profound knowledge: "Deming advocated that all managers need to have what he called a System of Profound Knowledge, consisting of four parts:

1. Appreciation of a system: understanding the overall processes involving suppliers, producers, and customers (or recipients) of goods and services (explained below);
2. Knowledge of variation: the range and causes of variation in quality, and use of statistical sampling in measurements;
3. Theory of knowledge: the concepts explaining knowledge and the limits of what can be known.
4. Knowledge of psychology: concepts of human nature." (quoted from Wikipedia).

When forcing ourselves out of processes we separate processes from humanity, separating processes from culture.

He encouraged us to embrace what we can and cannot estimate. If you can't properly estimate something, don't force false numbers on it.

He then told us a closing story of a team with very capable but totally different individuals where Kanban finally got them to buy into "the same game" despite their opposing ways of working. One reason people seem to like working in a Kanban system might be that it can be seen as a game with the goal to move stuff to the other side of the board quickly and in a way that it never comes back. Kanban makes people see more than their single task.

After all these interesting insights, it was easy to follow up with a few more vivid discussions accompanied by a few more drinks. Thanks to Jim and it-agile for a really nice and valuable evening!