Meet "The Change Agent" at LKNA13

Like every year, the program of the Lean Kanban conference in North America is simply amazing. This year it's even more amazing because there is a track called "The Change Agent" and I am very honored to chair this track. I find it really marvelous that such an important conference puts the work of change agents to its agenda because whenever I visit conferences and listen to talks about advanced metrics, optimizing flow, risk management, etc., I often think to myself: "That's a good problem to have." There are so many excellent ideas out there of how to improve work life, however, the most important challenge is that you will have to make it happen. And that is exactly the point in time when you wish to have the skills of a change agent.

The summary of "The Change Agent" track reads like as follows:
There are no exact numbers but surveys show that 60 percent to 80 percent of change projects fail. The reason of failure is not the lack of processes, methods, frameworks or tools. Organizational change fails because of bad change leadership or the lack of a change process at all.
The vision of this track is that participants can lower their number of failed change initiatives. Speakers will present their experience what it needs to lead sustainable change initiatives in organizations. Topics like change resistance, emotions, behavioral aspects of change as well as tools and good practices are discussed.

To move one step closer towards the vision of this track, I proudly present the speakers (in order of their appearance):

Marius de Beer, "A Tale of Two Change Agents"
Klaus Leopold, "Good Practices to Start a Culture of Continuous Improvement"
Esther Derby, "The Language of Change"
Sigi Kaltenecker, "Strategic Change Management with Kanban"
Pawel Brodzinski, "Portfolio Kanban: A Backdoor to Organizational Evolution"

Looking forward to meeting you at the LKNA13 in Chicago, April 28 - May 2, 2013.

Feedback and Pull-based Knowledge Transfer

When I revisited a client about 1.5 years after we introduced knowledge transfer policies to their system I discovered something interesting: knowledge transfer tickets followed a slightly different process than tickets without knowledge transfer. They pass through an additional last process step called "Feedback & Learning". Whenever a mentor mentee pair finishes a ticket they give each other feedback about their (pair) work. When I say feedback, I mean true feedback and not the kind of "Everything is fine, wonderful and awesome, and you are a nice guy. (And now leave me alone.)" It is about learning and thus, true, critical, and appreciative feedback is required which is really something you'll have to learn. By the way, giving true feedback is part of the Kanban Change Leadership trainings I run together with Sigi Kaltenecker ;-)

But back to the example case... The "Feedback & Learning" step also requires the mentee to write an article for an internal knowledge base. After having this policy in place, the client reported back that they evolutionary built-up a knowledge base from zero to a quite mature state with very little effort in only 4 month. Even more, the number of knowledge transfer tickets was decreasing because people could look up in the knowledge base. Whenever they don't find the desired information, they add another knowledge transfer ticket to the board. You see the pattern? A pair is built, knowledge is transferred, and after the transfer knowledge is conserved. And so on...

Pull-based Knowledge Transfer

With another client we introduced a pull-based knowledge transfer policy: Each worker can put 'I want to learn' tickets in the knowledge transfer column of the input queue. 'I want to learn' tickets are green colored sticky notes which express the wish to learn something. When a work item enters the system where the desired knowledge could be transferred, the green sticky note is stapled on the work item and a pair is build in order to teach and learn. In this particular kanban system they assigned capacities for 7 simultaneous 'I want to learn' tickets which is approx. 15 % of the 46 people working with the system.

Knowledge Transfer or Not?

In my article "Knowledge Transfer with Kanban" I explained the very first experiences I made with knowledge transfer policies in kanban systems some years ago. I convinced quite a lot of organizations to give it a try when they faced this problem. In an audit with a client who introduced knowledge transfer through WIP limits I got the feedback that it works - but not under all circumstances. They reported two situations when it does not work for them:

1. When you want to transfer knowledge to a rookie but the work is much too specific. You would have to explain hours until the mentee would understand what you are talking about.
2. The work is too general. No knowledge transfer is needed because everyone could do the work on his/her own. 

A short remark to the second case: We know there are still good reasons for working in pairs not only for knowledge transfer but this is, however not part of this article - and no, I could not convince them to still work in pairs on these tickets. You know, it's not always easy to argue flow in capacity optimizing cultures...

Knowledge transfer makes sense - but not in all cases

In general one could say knowledge transfer makes sense - but not in all cases. So the solution was straight forward: we visualized it!

In the figure above you can see a divided input queue: WT and IQ. IQ stands for Input Queue and WT is an abbreviation for the German word Wissenstransfer which means knowledge transfer. And that's exactly what it is - we have two input queue columns: (i) work where it makes sense to transfer knowledge and (ii) work where it doesn't make sense. We introduced a policy like "whenever a senior developer discovers work that's worth for knowledge transfer she puts the ticket into the WT column. A pair is build and they work on the ticket as a team". Easy, isn't it?

After a couple of weeks the client reported back that the number of knowledge transfer tickets was greatly reduced. However, this was not the intention. As a consequence they changed the wording of their policy to: "Whenever a senior developer discovers a work which is NOT worth for knowledge transfer, she puts the work into the IQ column". See the difference? They basically made it the default case to transfer knowledge. They reported back that the number of knowledge transfer tickets was increasing again. Of course they also discussed the issue in a retrospective and rose the developers awareness that knowledge transfer is the expected behavior.

Knowledge Transfer with Kanban

One of the challenges I've to address quite frequently in system designs is knowledge transfer. For instance, some years ago one of my clients was in the situation that they have a lot of COBOL code in their system. That's not really a problem as such, however they noticed that COBOL developers die out slowly :-) So what are the options? They could probably tell their two remaining COBOL guys to sit in a corner until they retire and write down everything they know about their COBOL systems. Well, I am rather pessimistic that this will lead to a big success. Don't get me wrong. I see quite a lot of value in documentation, nevertheless when it comes to knowledge transfer, there are much better ways to succeed.

Pair Up!

When I was confronted with this situation the first time, a former experience from an XP team came into my mind. When we tried to figure out the WIP limits for their kanban they told me it must be something around 0.5 per person. Wow, half a work per person! That doesn't sound right. However, what they were (and still are) doing is pair programming which means that each user story is developed together by two persons. This inherits a lot of benefits. One of the biggest benefit was that knowledge about their system is spread among all developers. Ahhhh... That's exactly what we need for our COBOL guys. We want to spread the knowledge about the COBOL systems. Guess what we did? We set the WIP limits to "number_of_persons - 2" (there are two COBOL guys). Furthermore, we introduced a policy that each of the COBOL veterans has to work on a ticket with another guy. And guess what, it really worked. Knowledge was transferred and more and more people were aware of what's actually going on in the COBOL system.

Today, I propose this pattern every time when we have to address knowledge transfer in the improvement work. It is not always easy, especially if companies are trying to utilize their "resources" as much as possible. But that's another very long story… The explained pattern is the very basic idea of how to handle knowledge transfer. In later articles I will describe more variants.

Kanban does not force you to do Kanban

Last week I held an accredited Kanban training in Brno, CZ. There was quite a lot of Scrum knowledge in the room as Scrum trainers and practitioners were participating which of course led to some discussions regarding Kanban vs. Scrum. I am really not a fan of these discussions, nevertheless it turned out to be quite fruitful.

We could agree that Scrum tells you what a team has to do in order to become "hyper productive": cross functionality, Scrum Master, Product Owner, sprints, review, sprint planning, etc. are some of the prescriptions in order to improve within the Scrum mindset.

Let alone that Kanban is not a team-based approach, it can also be used on a team-level in order to improve. Kanban is about encouraging people to find their own way. So the Kanban way is not to prescribe what companies should do but rather help them find out for themselves what they have to change in order to improve. 

So what's the point now? I often feel very pushed when talking to Agile people. They sometimes appear to me like missionaries proclaiming the good news that they have the patent remedy to heal the world. I think the Kanban mindset is completely different. For me, a good Kanban coach or trainer does not force people to do Kanban. This would be a contradiction in terms! When it is about to encourage finding the own way, how could you force people to do it your way? It might turn out that some people prefer following prescriptions of a book or method instead of finding their own way. However, in this case following prescriptions is their own way. There are for sure plenty of reasons for it and in the end it might boil down to fears, personal believes and assumptions.

My assumption is there is not only one truth on how to run your business. I made a quick book search: Amazon finds 6,355 books on "software project management" (http://amzn.to/UKTMOj), 65,238 on "software development" (http://amzn.to/UKU3kt), and 813,167 books on "management" (http://amzn.to/UKWRhq). If there's only one truth, we should probably tell Amazon. They would be lucky to free some stock.

LKCE12 is now history

The Lean Kanban Central Europe Conference 2012 is now history. How was it? Well, it's hard to judge objectively as we together with it-agile were the organizers of the event. But my subjective impression was: I loved it! :-) Katrin and I wanted to make it typical Viennese and as we didn't even think about the illusion that it's possible to please every attendee, all decisions were based on two very simple rules: 1) It has to be fun for us and 2) don't scrimp on quality! The result was an awesome venue, traditional Austrian food, an evening party with a DJ who played Viennese style electronic music, a magician, and lots of small details we found important. Take a look at the photos to get some impressions of the Viennese Lean-Kanban party: www.lean-kanban.eu/pictures. Many thanks to Adrian Buturca and Jabe Bloom for the photos!

There's also a short video about the conference available:

Regarding the sessions it's again hard to judge objectively if the attendees could see a good program because I was part of the program board. However, take a look at the sessions overview and judge yourself: www.lean-kanban.eu/sessions All sessions were also recorded on video. A red V behind the session name indicates the video is already available.

If you now think, "Damn! I missed a cool conference", I can tell you that there is hope: go and book your ticket for Lean Kanban North America 2013 from April 28th to May 2nd in Chicago!!

Der Kanban Coaching Professional (KCP)

Im August wurde der Kanban Coaching Professional (KCP) geboren. Die Frage, ob die Welt einen KCP - also einen, von einer offiziellen Stelle abgesegneten Kanban-Coach - benötigt, ist für mich eher rhetorisch, da ich im Advisory Board dieses Programms bin und somit daran beteiligt war, den KCP ins Leben zu rufen.

Wissensmangel

Aber warum braucht es den KCP? Ich wiederhole mal ein paar Aussagen, die ich häufig über Kanban höre oder lese:

• Das Resultat von Kanban ist Scrum: Wenn man nur lange genug Kanban macht, kommt durch die Evolution am Ende Scrum heraus. Wenn nicht, dann ist man am Verbesserungs-Weg irgendwo stecken geblieben. Hmmm... Wenn das Ziel einer Kanban-Implementierung Scrum ist, wird Scrum rauskommen, ja. Wenn ich jedoch andere Ziele verfolge, wird was anderes herauskommen.
• Kanban ist nur Visualisierung der Arbeit: Das hat schon sehr viel Schönes, geht jedoch nicht weit genug. Kanban ist Visualisierung der Arbeit plus 5 weitere Praktiken (= 6 in Summe) und 4 Prinzipien…
• Kanban funktioniert in der Wartung aber nicht bei Produktentwicklung: Hiermit wird die empirische Evidenz hunderter erfolgreicher Kanban-Produktentwickler verneint. 
• Kanban ist nicht für agile Projekte geeignet: Ein Klassiker. In manchen Kanban-Projekten liegt der Zeitraum von der Idee bis zur Live-Schaltung eines Features im Stunden- oder Tagesbereich. Und das, obwohl es sequentielle Arbeitsschritte gibt (siehe auch "Gibt es wirklich keine Reihenfolge der Arbeitsschritte in der agilen Softwareentwicklung?").

Anforderungen an einen KCP

Jetzt sind Wissensmängel ja prinzipiell nicht schlecht, da sie Chancen zum Lernen eröffnen. Schwierig wird es nur, wenn Personen mit solchen Wissensmängeln in einem professionellen Umfeld z.B. als Coaches oder Consultants agieren. Die Kunden bekommen nicht zwangsläufig schlechte Arbeitsresultate, es ist jedoch unwahrscheinlich, dass das gesamte Potential von Kanban für die individuelle Situation nutzbar gemacht werden kann. Genau diese Qualitätssicherung wird durch den Kanban Coaching Professional sicher gestellt. Ein KCP hat mindestens...

• ein 3-tägiges fortgeschrittenes Kanban-Training besucht;
• über einen längeren Zeitraum Praxiserfahrung in einer oder mehreren Organisationen mit Kanban bewiesen;
• den Begutachtungsprozess des KCP Advisory Boards der Lean-Kanban University bestanden.

Wenn jemand diese hohen Qualitätsansprüche erfüllt, ist die Wahrscheinlichkeit verdammt hoch, dass der KCP Kanban nicht als Dogma versteht sondern als ein maßgeschneidertes, evolutionäres Vorgehen hin zu einer Kultur der kontinuierlichen Verbesserung und somit großen Mehrwert im professionellen Umfeld ermöglicht.

Details zum Kanban Coaching Professional gibt es auf der Seite der LKU unter www.leankanbanuniversity.com/lku-kcp