The AgileCoachCamp US in Columbus, Ohio, was in many ways an enlightening and awesome event. Pascal Pinck invited me to come, meeting him and talking to him was one of the highlights of the weekend. This won’t be my last post about ACCUS…
Session Title
Kanban Considered Harmful?
I had a few conversations at the SoCal Kanban/Lean Software meetup in LA (see my slides here) about situations where teams had failed to introduced Scrum, not succeeding in building working software every few weeks. Then someone came along and suggested Kanban, as this would not require iterations… I see an evil pattern there: Teams (and organisations) think they are agile once they introduced a framework (Scrum) or tool (Kanban). This is wrong. Both are meant for a single purpose: to challenge the status quo. To support continuous improvement of the way we work. So if you “succeed” in doing Scrum (Backlog, Burndown, potentially shippable etc.) but don’t continue to improve from there, you miss the point. If you “succeed” in putting a Kanban board on your wall, assign WIP limits that feel comfortable and never start improving, you miss the point.
I love Kanban, as it is used as a gentle tool to introduce change and lead to a continuous agile/lean transformation of the workplace and value network. As it leads to building the right things better, instead of the wrong things righter. I love Scrum, if after the initial (revolutionary) step you continually improve. If you don’t do that, you’re getting it wrong, and unfortunately Kanban is not only easier to introduce, is also easier to misuse in this sense.
Given the situation at the CoachCamp with so many experienced lean and agile coaches, I proposed a session with the provocative title “Kanban considered harmful?” It worked in luring the right people into the session, and the outcome that emerged totally astonished me…
Agile Adoption in the Large
We started discussing an excuse (my interpretation) for such a development:
- Scrum or Kanban is (really) introduced in a small setting of a big organisation and works as beacon (better software faster), so that
- Senior Management decides to roll out Agile in the big organisation (to save money), so that
- Teams and Managers do Agile without actually seeing the point, so that
- they don’t get it right.
I think that’s a poor excuse, as we (as agile practitioners) should tell senior management that this strategy is a sure setup for failure. Yet, senior managers expect a financial benefit from a change. So, we started to talk about
Managing Management Expectations
The Quality of Life Model
Read the picture like this:
- Senior Management expects to earn/save/protect money (arrow to the top). They expect a certain benefit. Should we tell them to expect less benefit? No! Benefits are multi-dimensional and interdependent:
- (read clockwise from the money arrow) Once we inspire our staff with a clear and compelling purpose,
- the will be better motivated,
- which lets us tap into the creative power of all our employees.
- This should lead to the creation of better products,
- better processes (if we give people the autonomy to define the best suitable process)
- leading to more customer satisfaction and
- more marketshare.
- and then, only then, we get more money, leading to a better Quality of Life for all.
There’s a lot of thinking to be done on this, it is boldly simplified in places, but I think this is a good starting point for a discussion.
And I was delighted that the outcome of my session was
not harmful 
