Post Image

LKCE13 – A Short Review (part II)

Today my first follow-up to the first round of session reviews of the LKCE13.

Kanban in IT Ops by Dragos Dumitriu

Dragos Dumitriu @ LKCE13Dragos is some of the leading figures in the Kanban crowd, and he contributed chapter 4 of “the” Kanban book by David Anderson (Successful Evolutionary Change for Your Technology Business).

He provided a brief overview of his engagement turning around a struggling Ops department by introducing and living Kanban. His slideset was quite interesting, will add the link as it becomes available.

Below a few ideas from his presentation that I might consider steal reusing in my own context in future.

  • Board layout particularly for teams with operational tasks:
    • Including a Triage column (unlimited, uncommitted) before Ready.
    • Instead of having tickets either lingering in “Active / In Progress” too long or coming back because the issue is not completely fixed, have a Monitor column before final closing.
    • Have one swim lane per service team on a large board.
  •  Color-code criticality of issues
  • Relate tickets in queue to occurring incidents and pull them up: This seems like a great idea, as often potential solutions / preventions for incidents are already in the backlog.
  • I heard this also mentioned in other sessions – the backlog must be cleaned up regularly and should not be allowed to grow too large. // This addresses the puzzle of how on earth one should keep a backlog of several hundred items in control.
  • Make sure to have a service perspective on things, also when it comes to the board layout. Make sure to have clear ownership for each service line.

Lessons Learned from caching 50+ Kanban Teams (@chrisach)

Chris shared his experiences from a big Kanban rollout and coaching initiative he was leading. I think the LKCE had a nice mix of intellectually inspiring / thought-provoking sessions and down-to-earth sharing of experiences like Chris’. I also liked his clean and very visual slides.

As other speakers he reminded us that context is hugely important in Kanban – there are few policies that can just be copied over.

In order to get Kanban established and making it stick, you need to grow it like a precious little plant. For that, you need time and dedication.

In your Kanban system you should build two qualities: stickiness (sustainability, resilience) and clarity (aligned with purpose).

To support the maturing of the system, they used spider web diagrams where they assessed the current stance of the depth in each of the practices. They then jointly defined targets for the next improvements. (Now that I write it I realize this sound pretty standard consulting practice but hey, why not?)

How did they train teams to “make it stick”? They applied a train-the coach concept and held 1-day-start-workshops followed by “boosts”. He said it was essential to do little theory but much practice in their own context. As soon as a team sees “their” actual stuff on the board, they get a boost in engagement and excitement.

You can find the slides as well as some interesting background info on the slide, a Kanban kick-start guide and more in Chris’ blog.

Kanban@SAP (Dr. Alexander Gerber, Dr. Martin Engel)

This was another really nice session transferring experiences from real-life projects. In this case about the Kanban system of a team which was responsible for large-scale agile / later Kanban rollout. Following the “eat your own dog food”, the team itself applied the Kanban method to create its own working system and to build credibility with their internal “clients”. In the session, they showed unpolished, real artifacts from their project.

Similar to Chris’ and Dimitri’s sessions, I mainly captured ideas / concepts to follow up or use later on.

I quite liked their concept of treating the Kanban rollout as an offer, resulting in pull from interested teams rather than pushing it out to all of them in an arbitrarily defined order. (They had Scrum rolled out before, and teams could develop towards Kanban with this offer). Like in Chris’ organization, they ran 1-day workshops with the objective to have the teams start with Kanban the next day plus coaching afterwards.

They mentioned a game called “A-1-I Game” focused on WIP limits. Dr. Google only found the “A1 Kanban Game“. Not sure if that’s the same, will check. Any hints welcome!

From their “proven” practices:

  • Regular “triage” meetings to clean up the backlog (with the results clearly visible in the Cumulative Flow Diagram).
  • They agreed on a “Team Charter” (which itself had a WIP limit of 10 to keep it digestible) for their explicit policies and rules. They defined an “advocate” for each rule who the owned it and watched over it in the day-to-day work, calling out breaks of this rules if needed. (Yes, collective ownership is a great thing, but sometimes having clear individual responsibility doesn’t hurt, does it 😉
  • They applied “Malik’s Garbage Collection” visualized on their board to regularly clean up stuff. (I could not find this described in English anywhere, but there’s a brief German PDF available for it [3] as well as a German book “Führen, Leisten, Leben: Wirksames Management für eine neue Zeit” (“Lead, perform, live”) by Fredmund Malik [4].

  • On their board, they had a WIP limit for tasks with external dependencies. For their context, that sounded like a good pragmatic approach to deal with them in a way that made them stick out (causing some pain) but not blocking the columns all the time.

Agile for Building, Lean for Learning (@regis_medina)

Regis made the statement that “agile is for building, lean for learning”, which he tried to substantiate in this session.

He started with stating that many lean elements / ideas can be found in agile, but not all. However, he was quite clear that agile and lean are different. What was unfortunately lacking was his definition of what “lean” and “agile” are.

He proposed that waterfall and agile approaches are for “production”. Most team became more successful when moving from waterfall to agile, but a few teams really rocketed. Why did this happen? Because they could use their skills best in the new environment – it’s all about the people.

On the other hand, he said lean is used for teams to learn how to improve – to create a learning environment and practicing. He drew on a sports analogy – practicing certain moves makes you more capable in the long run.

He named these lean exercises:

  • Define value
  • Deliver right the 1st time
  • Deliver on time every day

“In a lean environment, the manager acts as a teacher.” I doubt that this alone would be sufficient to yield the expected results.

At the end of the session, this question formed in my mind: Why can one not use “lean” to develop products? If lean is only about learning, where is business value (e.g. in the form of new or better products) created? Well if anything this triggered me to look up “lean” in wikipedia. Here’s the result.

Lean“, is a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination. Working from the perspective of the customer who consumes a product or service, “value” is defined as any action or process that a customer would be willing to pay for. [1]

The Toyota Production System (TPS) is the most prominent example for Lean. Below the wikipedia definition of agile software development.

“Agile software development” is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. [2]

Both have a very clear focus on creating value to the customer, which supports my doubt in Regis’ proposition.

Overall, this session left me with ambiguous feelings. While I liked the metaphor of exercising for learning, I do not necessarily agree with the clear distinction he draws between lean and agile or even the need for it. My feeling was that he reduced agile too much to its “mechanical” practices, rather than the powerful agile values which show great matches to the lean approach he described. I also wasn’t sure that the successful cases he quoted are truly specific to lean – for me it seemed well conceivable that the same would have happened in agile projects.

Well, with this I’m almost done with my reviews. There remain the three really interesting keynotes by Troy Magennis, Stephen Bungay and David Anderson, plus the Jimdo leadership session by Fridtjof and Arne as well as Pawel’s Fixing Portfolio Management. I hope to complete them over the next few days.






Leave a Reply

Your email address will not be published. Required fields are marked *

For a better user experience, please switch your device to portrait mode.