Which change-management approach is required to implement Kanban?

Well, there's the thing: the way I understand it, the Kanban method is not an end in itself – it is quite the other way round. Kanban is the change-management approach.

As lined out in the book that defined the method «I [David] subtitled this book, “Successful Evolutionary Change for Your Technology Business.” I did this to underscore the point that the main reason for adopting Kanban is change management. Everything else is secondary.» (emphasis added)

Over time the Kanban Method has evolved, and with the current material there are quite a few additional actionable tools available which hugely extend the original book. But for me, the core is still the same. You use the Kanban method to enable change – simultaneously giving people control over the processes (the process control or service delivery part) and enabling evolutionary change by making formerly intangible things visible and negotiable (the –evolutionary– change management part)

Of course, there is STATIK, the Systems Thinking Approach To Introducing Kanban, but once again, this is not an end in itself. And it only is an approach to introduce the Kanban method. All the organizational change that comes after that is not driven by STATIK, but by the Kanban method itself.

So, I guess what I'm trying to say is "Don't ask what you have to do for the Kanban method, ask what the Kanban method can do for you."

till next time
  Michael Mahlberg

When implementing Kanban, don't underestimate step 8 of STATIK

When you first start of with Kanban, you might hear that there is a very clear cut way to introduce it – it is called STATIK, the Systems Thinking Approach To Introducing Kanban.

For me this is not always the way to go, but it definitely is a way you should know. As long as you don't think that you can introduce the Kanban method with a half day (or one day) STATIK-Workshop.

Let's look at STATIK briefly: The way David Anderson describes it on his linked-in post STATIK consists of 9 steps. (There are other descriptions as well, most notably Mike Burrows' version from the Book "Kanban from the inside")

• Step 0: Identify Services
  [For each service]
  • Step 1: Understand what makes the service fit for purpose for the customer
  • Step 2: Understand sources of dissatisfaction with the current system
  • Step 3: Analyze demand
  • Step 4: Analyze capability
  • Step 5: Model workflow
  • Step 6: Discover classes of service
  • Step 7: Design the kanban system
  • Step 8: Socialize the design and negotiate implementation

(I just quoted the summary, the full description is available in David's above mentioned post on LinkedIn )

Starting with step 1 through 7

While it is true that you could hold a STATIK Workshop for the steps one to seven in a really short amount of time, I have never seen the Kanban method implemented this way. I have seen quite a lot of Kanban systems implemented this way. But that's not quite the same – defining a system that reflects a certain point in time is different from embodying a method that fosters ongoing change.

Why I think step 8 is the most important one

Remember – as the titel of the defining book says - it is an approach to change: "Successful Evolutionary Change for Your Technology Business". And I have yet to see a system with human actors that can be changed in a day. Especially because the goal is not to change it only once, but to enable it to continue to do so in an evolutionary manner.
Therefore I think that step 8 is the most underrated Step of STATIK and would strongly suggest to use the result of steps 1 to 7 (a hypothesis the current system) only as a starting point for the work that starts with step 8 – implementing an approach to collaboratively strive for improvement through evolutionary change.

till next time
  Michael Mahlberg

P.S.: For some inspiration on steps 1 to 7 you might also want to look intoAlexei Zheglov's Posts on the approach and the Canvas/A3.

How to single-handedly run a change initiative

That’s actually quite simple - you don’t!

A common way to facilitate change is by having change agents, and that actually seems to be exactly what is needed to make change happen. Yet the role of these change agents can vary tremendously – from someone requoting the initiative’s vision statement to everyone who wants to listen, to an agent of the workforce to seek out the best possible solution for the future.

Don’t get me wrong, I do love the idea of the “change agent” per se. I just found out that the name has so many meanings that it becomes either meaningless or extremely context-dependent. For my work – helping organizations adapting new ideas – I found that a change approach with a clear direction is quite helpful and very of a very small number (sometimes 1) of external consultants or coaches is brought in to facilitate this change.

Even though we would like as many people as possible to take an active part in the formulation of the new direction, most of the time that change needs some external insights that are not available from inside the system. As Jerry Weinberg would say: “The Fish is always the last one to see the water.”

So the kind of change agent we need in this case would be one who is amplifing the external influence and is the kernel of the internal change. Still not someone left to his own devices, but rather someone who acts in both directions as a focal point for the change. Multiplying the view from the outside and channeling the (numerous) questions that will arise from the inside. And while they will need to question the outside source often in the beginning, as time passes they will gain more and more knowledge – as will the whole organization – and will be able to drive more and more of the change from the inside.

There is a word in German that we use to call people who amplify the impact of others, we call them "Multiplikatoren" which would roughly translate to “Multipliers” in English. Due to an unexpected chain of event we ended up with the old English word “Multiplicator” to describe the role in a recent project.

I kind of like the word by now - the use of uncontemporary language makes it obvious that we don’t really mean “multiplier” in a mathematical sense and it still conveys the basic idea.

And IMHO having this kind of change agent is one of the key success factors for change inititives - lean, agile or else.

till next time
  Michael Mahlberg

“We need the historical data” is a complete straw man - at least for tickting (e.g. Jira) and version control (e.g. Subversion)

People get attached to tools. That is not a bad thing. It only becomes a problem once we become biased and start to rationalize our attachment with questionable reasoning.

One of the straw man arguments I hear a lot lately is the access to historical data that would be “lost” if we changed the system. Strangely enough this argument is used for at least two very different things – ticketing systems and versioning systems.

People tell me that they would love to change to a system that supports the team in modeling the actual flow of the work, but they have to stick with (a centrally managed installation of) Jira because otherwise “they would loose all the historical data”. In a completely different context other people tell me that they can’t move from the version control system subversion to the much newer version control system git because they would “no longer be able to access the older revisions.”

Event though both discussion are from different contexts, they share some similarities:

• Read-only access for the historical data was – upon enquiry – absolutely sufficient
• The relevant data could easily be kept available with very little effort.
• People had no experience with the proposed “new” tools
• In both cases a boatload of support processes was dependent on the old tools

The real challenge turned out to be training the people in a proper way and decoupling the support processes from the tools.

So, if there is talk about the necessity to access the historical data as a way to discourage switching to new tools, you might want to reconsider what is keeping you from switching to tools that are more appropriate for todays challenges. Is it really the need for historical data?

This is the 21st century.
Storage has become cheap.
Hardware has become cheap.

If you want to keep your historical data accessible, just buy a box to do so. Way cheaper than any sophisticated migration strategy.

On the other hand new tools require new ways of working – and whether that is quite as easy is something completely different.

I don’t want to say that changing tools is easy, my point here is that keeping the historical data is a straw man reason for not moving forward.

till next time
  Michael Mahlberg

Scrum-But or Inspect and Adapt?

For a couple of years now I have heard people condemning projects as “Scrum-But”, mostly without even looking at the projects. And sometimes even without any reference to what they consider to be a scrum-but.

“but” what?

As you probably can imagine after my last two posts, I am especially suspicious if people do that without looking into the scrum guide. I keep experiencing people proclaiming something is a scrum-but because of all kinds of misconceptions. Sometimes “they don't have 2 week iterations” (the scrum guide calls for “a time-box of one month or less”) or because “they don't use Unit-Tests” (the scrum-guide states that “Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.”)

While it might be preferable to have shorter timeboxes (as the agile manifesto clearly states: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” [emphasis added] ) and that it is much easier to have a thoroughly tested product if one does have automated tests including unit tests, this is more about common sense (or agile experience) – but definitely not part of scrum.

Apart from the fact that more often than not, the same people carry the battle cry of the agile credo inspect and adapt as a default answer to most everything, there is a certain irony in the fact that nowadays we seem to have a kind of method police around scrum while the first value pair of the preamble to the agile manifesto reads “Individuals and interactions over processes and tools.”

If you do it, do it right

Oh, and don’t get me wrong. If you want to call it scrum: go by the book. But by the right one!
And remember that “Scrum is a framework for developing and sustaining complex products.“). And while on a programming level the “Instantiation of such a [software] framework consists of composing and subclassing the existing classes.”) the fact of the matter is that the same is true for a process framework – you have to define the specifics for your environment to be able to use it!

So – how do you shape your process?

till next time
  Michael Mahlberg

Straighten! The second S of the 5S

(Seiton, 整頓, according to Wikipedia)

I am still not convinced that it was a good idea to only use English words that start with an ‘s’ for all the pillars of the 5S-System in the Wikipedia (and some other) explanation of the concept.
According to Hirano, who wrote one of the defining books on 5S, the second pillar is called ‘orderliness’ which – in my opinion – is much easier to interpret for software development purposes.

Ideas from production (as quoted from Wikipedia)

• Arrange all necessary items in order so they can be easily picked for use
• Prevent loss and waste of time
• Make it easy to find and pick up necessary items
• Ensure first-come-first-serve basis
• Make (the) workflow smooth and easy
• Can also be translated as “set in order”

The difference between ‘sort’ and ‘straighten’ is very subtle - especially when we think about software-development or other knowledge work, but if we consider the alternative translations ‘organization’ and ‘orderliness’, the difference becomes much clearer in my opinion.

How to apply these ideas to software development

While ‘organization’ calls for the removal of unnecessary clutter (be it in your File-System, on your physical desktop, on your computer’s desktop or anywhere else) ‘orderliness’ goes a step further and requires us to set the things that are not unnecessary – one might say those items that are necessary – in a definitive, understandable, reproducible order.

Let‘s look at other options to bring more orderliness into software-development

One of the things I tend to see here is the “automate ruthlessly“ or “ubiquitous automation” concept. Or, as they put it in the old days:

• The first time you do something, you just do it manually.
• The second time you do something similar, you wince at the repetition, but you do it anyway.
• The third time you do something similar, you automate.

But just using the tools of the trade in a more orderly fashion can make a huge difference. Using tags to categorize files (if your file-system supports such a thing), using a defined pattern for file names (not only for source code) and generally not only weeding out stuff but also ordering your tools and material falls into this category.

As James O. Coplien quotes in the foreword to the clean code book there is the old American (?) saying of “A place for everything and everything in its place” which really captures the whole concept very well for me.

What I propose in addition to Cope‘s explanation of this concept (a piece of code should be where you expect to find it) is to apply this idea to everything related to the value chain – from the first idea to the end-user actually interacting with the capability of the system that represents this idea.

• Where do the requirements belong?
• Where do the acceptance criteria live?
• Where would I find the swahili language translation of the help-files
• Where is machine specific configuration information placed? And how about user specific configuration?
• and so on...

Now what would you propose to do in our day-to-day work to get our software-development more ‘orderly’?

Till next time
  Michael Mahlberg