Sunday, August 09, 2020

Bringing Agile to non-IT work... those who don't remember history are doomed to repeat it

People tend forget that many of the agile approaches borrowed heavily from the Toyota Production System and its relatives, commonly known under the umbrella term "Lean."

These days we're experiencing an interesting development. People try to bring things they perceive as "typical agile practices" to non-IT work. For knowledge workers --a term coined by Peter Drucker in the 1960s-- this might perhaps be a valid approach. Even though I doubt it. For non-knowledge-worker work on the other hand, I would like to point out what happened here. Approaches taken from the Lean context of shop-floor management and vehicle design, related to continuous improvement and optimizing the flow of work, were translated into a very different environment -- that of software development. And even the considerable body of knowledge from other fields of expertise that is at the foundation of agile was put into a very specific context here. Actually, the so-called "agile manifesto" is called "Manifesto for Agile Software Development" and thus very specific with regards to the domain it targeted. So nowadays, when people try to "apply Agile to non-IT situations", they basically take the adaptations that have been made to non-IT approaches to make them helpful in Software Development and try to re-apply what's left of them back to non-IT work. Of course the original non-IT approaches have also evolved since the days that --just to pick an example-- Ken Schwaber and Jeff Sutherland read 1986 paper "The new new product development game" (sic!), and took parts of those ideas as a foundation of their own agile approach (Scrum). Hence it seems kind of silly to me to derive ideas for modern ways to organize non-IT work from the spin-offs from more than two decades ago instead of going directly to the source.

Of course sometimes re-applying the stuff we learned from agile software development actually works, but I think going directly to the source is a much better idea. Perhaps instead of trying to derive the helpful approaches non-knowledge-worker work from the shadows they cast unto the walls of the Agile world --to paraphrase Plato-- it might be a good idea to look at the origins and try to understand the original approaches to non-knowledge-worker work. Of course, oftentimes non-knowledge-worker work was simply called "work", back in the day. Directly adopting from approaches like Lean (from the 1950s) or New Work (which originated in the 1970s) might be an approach to improving work that avoids the 'Chinese-whispers' effect of the indirect approach via "Agile."

To end on a more positive note: the Kanban method is a great example of an approach that targets the challenges of the (non-it) knowledge worker and brings ideas from Lean and similar fields into a new context. And even though many people use the Kanban method in the realm of IT, it has many equally --if not more-- effective applications outside of IT. Maybe that's because the Kanban method avoids the triangulation via the older agile approaches and builds directly upon the common ancestors. I guess that is one of the reasons why David Anderson called the Kanban method "post-agile" even back in 2010.

till next time

  Michael Mahlberg

Sunday, May 24, 2020

Error: Customer unavailable! How do you manage flow now?

It’s Wednesday morning, you try to get an appointment with the stakeholder who is the most important customer for a work item that your team started to work on on Monday. And now you find out that they’re out of the office for the coming two weeks.

Now what?

You and your team invested 2 days already (for a 7 people team that would represent 14 person days of effort), and you all would really like to work on the topic.

After some inquiry about the requested feature it becomes clear that no one else knows what the requirements on this work item really are and now you’re faced with a tough decision: mark this card as blocked and become ‘idle’ as a team, or abandon the card (discard it) and let the customer bring up the topic later again?

There are drawbacks to both approaches –after all the situation is bad to begin with– but both follow the mantra to “accept reality” and are way better than following the wiscy approach where you start defining the result (e.g. by programming) without even knowing the requirements.

Let’s look at the implications of each approach.

For the following assume that we manage our work using ideas from the Kanban method and thus have the flow of our work visualised on a board including WIP-targets.

Option 1: put a blocker on the card if the customer is unavailable

Putting a blocker on a card is the normal way to make it visible to everyone that there seems to be no way to progress on the work represented by that card in a sensible way. At least if you apply the Kanban method. If your WIP-Target (mostly known as WIP-Limit) was already honored this creates a tremendous amount of slack for the team that worked on that card. In most cases more than you actually want and more than is wise from an economic point of view. But it reflects reality. If the relevant stakeholder is not available for an extended period of time this could be really expensive.

The important point here is that blocking the card fosters learning inside the system. People might come up with policies to make sure that the customer is actually available for before starting to work on the work item. Or they might come up with completely different ideas on how to mitigate this situation. Remember: Documentation isn’t bad per se.

Option 2: discard –or abandon– the work

On the other hand there is always the option of starting something new. In a system with a known capacity that usually means abandoning the old work – after all there are good reasons to limit the work in progress in a system. Amongst other reasons, allowing more work in has a very clear and negative impact on the lead time for the system as a whole. Discarding the work doesn’t necessarily mean that all the work already put into this item will be lost. It just means that the work item has to start its journey again from the far left side of the board and it might even take a couple of replenishment meetings (where stakeholders decide wich item to commit into the system) before work is started again. Some of the work will probably have to be redone because the world will have changed by the time work on that item again.

Here the systemic aspect is that discarding or abandoning a card fosters learning outside the system. Especially upstream, at the customer’s end. Customers might come up with the idea that it is a good idea to have more than one person who knows what the reasoning behind a requirement is. Or they might develop other smart ideas on how to handle this. Remember: there once was a whole body of knowledge called requirements engineering.

Either way: it is a chance for learning

Both approaches offer a chance to improve the system. While the former is targeted more at the system itself, the latter is target more towards the customer interface. Both are legitimate ways to “accept reality” and thus are way better than the alternative: wishful thinking and hoping you will guess the customer’s needs correctly.

till next time
  Michael Mahlberg

Sunday, April 26, 2020

Handling recurring work - some options from Lean and TPS

As someone who draws from the Kanban Method and its Lean and TPS ancestors when supporting change in organizations I regularly come across the question of “how to handle recurring work?”

And while neither the Kanban Method nor I have definite answers there are some options from Lean and TPS that can be integrated nicely into the workflow of 21st century knowledge workers.

I originally got the basic idea to adapt Kamishibai boards (see below) from @LukasDonSchmidt and I would have preferred to just link to a blogpost of his, but unfortunately I can’t find that out in the wild. Yet. (Didn’t you intend to write something, Lukas?)

Capacity allocation and recurring work

Assuming that you visualized your work using some kind of board and you use WIP-targets to manage flow, there is one challenge (amongst many others) that often arises. Small, recurring units of work that “need to” interrupt the flow of the big main work items. In an ideal world we might just strive for the knowledge worker’s equivalent to single-piece flow, but in the real world that is not always attainable or even feasible. To take a small business, non-IT example: the big Work Item might be an essay that needs a week to finish, and the small items could be fetching the mail and paying invoices.
One approach to handle this is to combine the concepts of different swim lanes for different work item types and capacity allocation. Let’s look at a small scale example for that.

Starting with this fictional, initial board for a very small –let’s say three person– writing agency, we see that the company has committed themselves to limit their sold “Options” ((Options for others, but things the people from our little agency committed to) to six “announced” articles and agreed to have a target number of articles they’re “writing” concurrently to two (thus allowing some work to be already in the “ready for B” column). Furthermore they agreed to have only one article at a time in the “copy edit” stage and one in the “delivery” stage. The “done” column in the example is unlimited (∞) and the invoicing process seems not to be part of this board.

But is this kind of work really the only thing that has to be done in this small company? Of course not.

Let’s take invoicing for example. Even if we assume that writing the invoice and sending it out is part of “delivery” then there still is the little thing of checking if all open invoice get paid some time. And most probably there are also invoices coming in that need to be paid. So there a many small things that need to be done and that we might want to visualize if they are important enough to justify the effort.

Taking the approach of capacity allocation a first solution might look like this:

The idea here is to simply start by allocating part of the day to the big chunks and reserving a smaller part for all the small chunks. Those small chunks might be things like fetching the mail, checking the payment of invoices or paying their own bills.

Following the original ideas behind the Kanban Method principle of “visualize work”, this whole setup is rather buggy. The description of the columns doesn't match with the actual work that's performed in that column, and probably the whole workflow is quite different for those smaller pieces of work.

So let's take another page from the Kanban method and let's have a look at what we actually do now (start with what you do now ) for those small items that we work on we find that we don't have a general workflow but instead the workflow for each card follows the steps of “pick a card”, “understand card”, “perform task”, and “reschedule card as necessary.” And even though this might be the actual workflow, for such small tasks it would not make much sense to separate “understand card” and “perform task” – especially since they happen repeatedly.

So, a more realistic model might only include columns like “options”, “doing”, and “ready to reschedule.”

Picture of a two swimlane board with different workflows for Standard and repeating work

In this picture we now have a Kanban board with two swim lanes. Each lane with its own work item type and both with separate work in progress targets.

Even though this board would actually work (and in many cases I've seen boards like this being really helpful) the actual workflow here is so generic that it doesn't really pull its weight to have a separate board for this.

Depending on details of the cadences (i.e. the rhythms in which work happens) and how much time each item takes to complete, the aforementioned challenge might also be addressed via the lean concept of Heijunka (workload levelling) in the way I mentioned in my earlier post.

Enter kamishibai…

Luckily, the Kanban board is not the only thing that made its way over from TPS into other applications of lean thinking. One of the important parts of the Kanban Method –and probably the most visible one– is the first principle: “Visualize (the work and the workflow).” Using visual representations for things important for the job to be done is a key tenet of visual management. Which in itself is a key component of lean production. Like other things from lean (e.g. 5S), visual management has to be adapted to knowledge work to reap its benefits in this realm as well. Kamishibai boards, which are sometimes used for recurring audits, can be used quite nicely to manage recurring tasks with low complexity like the ones described in the example above.

A simple kamishibai-board just consists of a place to put cards with different colored sides (e.g. red/green). Having a card with the green side up means it’s done, having it with the red side up means it is not yet done. Also, you have an indication of the cadences (the Rhythms in which you want to repeat the tasks) and the very moments those cadences start. Each time a cadence start you simply turn all the cards in that area to show the red side.

Now each time you intend to work on the recurring tasks, you just go to the board, pick a red one, do it and place it back again with the green side up.

Picture of a very simple Kamishibai-Board

In this example the mail has been fetched (green card), the receivables have been checked (green card) and the invoices have yet to be paid. All daily tasks will be turned to red at 9 o’clock and all weekly cards will be turned to red on Sundays at 9pm.

Do you have to do actual board design for this?

Certainly, even board with almost no explicit design like the one pictured above will already be sufficient for many situations. That doesn't mean that there are no approaches to designing such a board that can be helpful. First off let's start with the areas. In the example above we concentrated on weekly and daily recurring tasks – that might be completely different in your situation. Whatever the cadence of your recurring tasks is: make an area for that. For example, daily weekly and monthly or biweekly or any other cadence you actually need. A helpful practice here is to note down the point in time when cards should be turned back to “undone” next to the cadence name, so that everyone knows when the cards need to be turned back and the organization doesn’t become dependent on the knowledge of one single person who acts as a “keeper of the board.”

If you have more than just a few recurring tasks, it becomes a good idea to hang the board on the wall instead of wasting precious horizontal flat surface otherwise known as desk space. something metallic with magnets to hold the cards is a good idea here. Or you might to want to invest in professional T card holders as they are used for example in manufacturing (or just build them yourselves…).

Picture of a DIY T-Card-Holder

What about the cards?

Even with a simple board there are a lot of things you can do with the cards. By the way: a simple way to create cards with two sides of different color is to just stick two post-its together, back to back… Or to take a white card and mark the top off in the colors of your choosing. Lots of room for DIY ideas here.


Is it really worthwhile to talk about the colors? Can’t we choose whatever looks fine? E.g. blue for undone and yellow for done? Or whatever our mood suggests? Yes that would be an option and it would even work. But with visual workplace management we want to make things easy to recognize with as little mental load as possible. So I suggest to stick with color codes that fit with everyday expectation, and Green for “done” seems to be pretty universal while “to be done” works with any color that’s far enough away from green like Orange, Red, Purple and the like.

What to put on the card

Apart from a short description of the task, it turned out to be a good idea to also put some additional information on the card. Two of the most important improvements or adaptations for knowledge work are sizing and tracking.

Assumption is the mother of all screw-ups

One helpful piece of information to add to the card is the time it should take to complete the task. Also, to make it more plausible that the work gets done reliably, it is a good idea to note down how long it actually took. A good practice here is to write the expected time on the “to be done side” and the time it actually took on the “done” side. And make sure to adjust the time it should take in accordance with those numbers. At least each time you have to replace the card because there is no more space for more records. Then we’re not talking about estimations anymore but about actual data from measurements.

Card sizing (kind of a hack actually)

If you have a dedicated amount of time to take care of your recurring tasks, it is a good idea to have a rough idea how many of those you're going to handle in any one session. One way to visualize this is to just have different sizes for the cards reflecting their average effort (doesn’t work with the T-Card approach, btw). This way, you can easily see how much of your time slot for recurring work will be filled up by the cards just by having a space at your own work area reflecting the time you allocate for these recurring tasks by it’s size.
You still should try to have a healthy mix of cards from different cadences e.g. daily and weekly, so that you don't have to do all the weekly stuff at the end of the week (or whatever the largest cadence is – could well be quarter in many enterprises).

Kamishibai – a little more complex

Even though simple recurring tasks do not merit the creation of a board that reflects their workflow, some recurring tasks can become quite complex. For those we can combine the whole idea of kamishibai with some insights from the checklist manifesto. The aforementioned task of checking invoices or receivables may actually turn out to be a bit more complicated than it might seem at first glance. Especially when the business is prospering and the client base grows. It might look like fetch the list of open receivables, add invoices we wrote since the last time we checked our receivables, fetch bank statements, cross out invoices where we got the money from our list of receivables, update last-check-date on the list of open receivables. As we can see, this workflow is in no way a process of knowledge gathering but actually just a collection of steps to be performed. Therefore, it wouldn't be natural inside the Kanban method to have a column for each of the steps. Furthermore, this process is very specific to this one recurring task. So, what's more natural than to put it directly on the kamishibai card? This way you might end up with kamishibai cards with things like cadences written on them, with an “Effort”, with little checklists and with any additional information helpful in the specific context of that task. Quite enough to handle most simple recurring tasks. Should the tasks become so complex that they warrant their own workflow the quest for an appropriate solution starts again of course.

The right approach?

Is it more appropriate to takle recurring tasks based on the kamishibai ideas? Well - it depends. It depends on the maturity of the people using the boards, it depends on the type of the recurring tasks –the approach lined out here assumes that the recurring tasks are small–, it depends on the complexity of the recurring tasks –having checklists on the task-cards makes it easier for people to swarm on recurring tasks- etc.
In my personal opinion one of the biggest advantages is that the approach helps in separating “value items” or “products” from items that are mere “tasks“ and are neither visible to the customer nor appreciated in themselves.

This illustration shows the approaches “use Kanban boards for everything” (one way) and “Kanban boards for value stream work and kamishibai boards for recurring tasks” (another way) can be used to represent the exact same situation.

A multi-process Kanban board broken down into value-stream Kanban board and kamishibai board

Both the light blue and the yellow scenarios represent the same situation. With regard to the recurring tasks: Two cards to do, one card in progress and one card “done” (at least done until the next cycle starts).

The second scenario uses a kamishibai representation for the recurring tasks. The recurring cards that were in the “committed” state on the kanban board of scenario “one way” became “undone” (red) cards on the kamishibai board in the scenario “another way.” An additional advantage is that the different cadence for both cards –one occurs weekly, the other one each day– is immediately visible. The “in progress“ card from the Kanban representation is not visible in this instance of a kamishibai board because the person working on it has taken it along e.g. to use the checklist on it. The card from the “done” column became a green (“done“) card in the kamishibai version. Again with the advantage that the cadence of that card is obvious.

Try kamishibai

Before you try to handle all work alike, maybe give the approach of kamishibai for recurring work a chance – it might help more than you think.

till next time
   Michael Mahlberg

Sunday, December 22, 2019

Don't get hung up on ‘Business Agility’ too much

To quote a currently very popular insight:

“As long as you don’t have your Business Layer under control, it doesn’t matter how agile your teams are.”

And YES, there is some truth in that. But it can turn out to be a logical fallacy.

And that is where I have my beef with the lure of ‘Business Agility’, because a lot of people think, that it is enough to focus on that level now. Not in my experience.

Having the awareness is –as the mathematicians would probably say– necessary but not sufficient.

An organisation is a system of interconnected systems (or services to use the terminology from the Kanban method) and if these underlying systems don’t work then all the ‘business level coordination awareness’ in the world won’t change much about the delivery capability of your organisation.

You can invest as much as you want into power steering (Servolenkung in German) and slip control – as long as your car is sliding sideways on an ice slope with slicks for tyres it actually pays to invest into better tyres before you start fiddling with the higher level elements.

As long as your business analysts don’t know how to quantify a business value, your engineers don’t know how to reliably ship the product, your sales people don’t know about the capabilities of your delivery services (sometimes a.k.a. development teams), or –in short– your teams are still at a low ‘agile’ maturity you won’t be able to steer the business.

The bottom line is:

As long, as your team level maturity is too low, you can improve the business level as much as you want – it won’t make a difference.


The maturity of an organization has to be evolved as a whole. The evolution at team-level, business level and strategic level has to go hand in hand

till next time
  Michael Mahlberg

P.S.: But if you focus on Business Agility alone at least some people in the organization will feel good. For about six to twelve release-cycles. Because –in my experience– that’s how long it usually takes the organization to come to this realization. [That can be up to three years btw...]

Sunday, December 01, 2019

Let MoSCoW help you with facilitation and workshop design ;-)

Interactivity vs. Schedule

When designing a workshop –or any session– you facilitate one crucial aspect is timing. But timing gets complicated when you have lots of interactive parts in the session in question. And we know from research about training and oftentimes also from personal experience, that interactive elements are essential to successful sessions, so there is a serious incentive to include interactive stuff. The same holds true for other kinds of meetings as well – from design sessions to board meetings.

Balancing being on time an interactivity with MoSCoW

There is an old idea, made popular in the early days of agile by its extensive use in DSDM called MoSCoW. The capital letters in MoSCoW stand for Must Should Could Won’t and the «o»s are just there to make it sound nice. Without looking into the original priotization method too deeply, thinking about the design of a session in therm of MoSCoW categories helps a lot in balancing timeliness and interactivity. Especially if you combine the MoSCoW thinking with the concept of Heijunka or work (load) leveling.

Designing the session

In most sessions, especially in teaching, it is not a good idea to have all the musts at the beginning – because of the way people learn a schedule should not be a backlog where you put all the important stuff up front and the rest at the end anyway. The approach that I have seen to be usefull to a lot of facilitators, is to make shure that your schedule consists of a well balanced mix of must, should and could elements. What ‘well balanced’ means depends on the circumstances of course. Assuming we’re in a training situation and we know only very little about your audience, we might want to include more ‘could’ elements than we do when we’re working in a well known setting. This is the Heijunka part – heijunka literally means ‘leveling’, but in the context of lean the meaning is extended to something like ‘smart leveling.’

BTW: In meetings that need to have decisions at the end, one of the must items –come to decisions– needs to be at the end. So it’s a very good idea to have discardable parts in the schedule even if the sessions you’re facilitating is not a training.

Applying triage as you go

Now while we run the session we don‘t want to constantly check the clock to see if we’re either too fast or too slow. Quite to the contrary. We do look at the time often, but we use our projected agenda (including the MoSCoW classifications) to adjust as we go. When we’re ahead of the time (e.g. because the audience is faster than expeted) we can transport a bit more information and include the could element that we put in our internal agenda. Should we be slower than planned we cut one of the should elements. By using this approach it is way easier to keep the value for the participants high for the whole session. (As opposed to lumping all the unimportant stuff at the end, so that we also could skip it – as we would do it in a prioritized backlog apporach.]

Just give it a try...

till next time
  Michael Mahlberg

Sunday, September 08, 2019

Is that “start with what you do now”-principle from kanban still ‘true’?

One of the pillars of the Kanban method is the principle “Start with what you do now.”

Looking at it historically, this was especially related to the fact that there is no need for any additional roles, meetings, or titles when introducing the Kanban method. In the early days that was such a stark contrast to other process improvement approaches that you still can find the foundational principle “Initially, respect current roles, responsibilities & job titles” on some Kanban method websites. Today this message has become part of the “Start with what you do now”-principle (as the second bullet point).

Over the years the body of knowledge in the realm of Kanban has grown and with some of the “newer” ideas there are a number of aspects that seem to contradict this very notion.

One of the more prominent ideas in this respect is the whole landscape of “Discovery Kanban”, “Customer Kanban”, and “Upstream Kanban.” Basically this is the idea to not only manage the delivery of work through a Kanban system, but also manage and organize the discovery of options with a Kanban system. Conceptually this has been described by Patrick Steyaert and it has been incorporated in the Kanban method as can be found e.g. in the related book Essential Upstream Kanban.

Yet, many companies don’t actually have a managed options discovery process – so where does this leave us with regards to the "start with what you do now"-principle? One possible starting point is David Anderson’s example for combining discovery and delivery kanban. This is a little different from the approach Patrick is describing, and most probably not exactly how the items “on the left“ of your delivery Kanban system flow now. (That is of course regardless of whether you call them “ideas“, “options”, “feature requests”, “demands”, or anything else.) But in my experience it is a very feasible way to get to “(finding out and) starting with what you do now.” As in so many cases, even though there might not be any formal discovery process, once you start looking into the details of the existing items and their history you might find that there is an informal process to be uncovered. It might more or less conform to the concepts lined out in the system descibed by David J Anderson, or not. Even if it doesn’t, just by having a board conforming to those concepts, trying to fit the (existing or assumed) items on it and facilitating the discussions around it, there is a good chance that you either uncover the real process or already evolve the process to something a little bit more fit for purpose.

Still, you actually started with what you did then – no new roles, no new processes. Not initially at least. Probably some processes evolved from having the discussions about the relative position of items on the board and how to get them there. And that is already the Kanban method at work as a change-management approach.

till next time
  Michael Mahlberg

P.S.: Thanks to Tim for bringing up this issue about “start with what you do now.” Nice catch.

Sunday, August 11, 2019

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

Monday, July 15, 2019

Why are there no product owners in Kanban?

Or perhaps the better question would be: Are there no product owners in the Kanban method?

It is actually a question I hear more often lately – especially since I started to publicly rant against the misnomer that “product owner” has become.

The question doesn’t make too much sense

As I mentioned earlier it does not make too much sense to directly compare the Kanban method and Scrum because they exist on different levels. Same is true for their lingo.

The Kanban method neither promotes or prescribes roles

There is no formal definition of any role. (cf. Essential Kanban Condensed, p. 33) The aim of the Kanban method is to help create systems that can evolve, following an agreed upon –and in itself evolving– set of explicit policies. That being said, there are roles that the Kanban community has observed as emerging in many Kanban scenarios, but those are not prescriptive. (And of course, there’s more to the Kanban method than explicit policies – bear with me for the sake of the role argument with regard to the product owner)

Are there any product owners? Anywhere?

The first principle I ever heard when I learned about the Kanban Method was “Start with what you are doing now.” I'm personally quite fond of the statement “Accept reality.”

Accept reality

However you put it – the role that is described as a product owner in the original scrum literature (imho that would be Schwaber, 1995 or Schwaber, 2003) is very hard to find out in the fields. As a story goes which makes its round in Germany right now, some famous product development guru (if someone could point me to the source I would be happy to quote the original source) asked a room full of conference attendees how many of them were “product owners.” Almost everyone raised a hand. The next question was “Who could end their product tomorrow?” No one lifted a hand. Thus the stated conclusion was “So – we don’t have any product owners in the room.”
This might sound a bit harsh, but it points to a quite valid aspect of working together IMHO: the question of our understanding of that role.

What is a product owner?

In today’s reality, there are many people who are called product owners, but who aren’t really product owners in the original sense. That’s not as bad as it sounds. At least many people have a rough idea of what a product owner could be. The trouble is that there are many different interpretations of the role. Unfortunately only very few of them are coherent with the original definition. Given that the process descriptions out there use the term as it is interpreted in their context, problems arise when business analysts, subject matter experts, product managers, requirements engineers and other people working on the conceptual development of products are all collated into the umbrella term “product owner.” If you hold people accountable for ordering work items who are specialized in requirements analysis or if you try to get the conceptual sign-off for a new decision table implementation from someone who’s area of competence is customer management it is highly probable that you will be disappointed. “You” in this case can be anyone – from the CEO to the customer to yourself. I have witnessed huge disaggreements about the competencies of the different product owners (note the plural) that work together with a team. A lot of these arguments vanished when we dropped the name “product owner” and used terms appropriate for the real expectations and competencies. But then the process models had to be adapted to these new names. Which, in itself, is not necessarily a catastrophe, but –more often than not– only the end of an illusion. Those descriptions had to be adapted because they didn’t fit “anymore.“ Actually, they never had, but with the new wording, the discrepancies became visible. And all of a sudden, a model of the real –living– workflow became visible.

The Kanban method makes these things explicit by default

Amongst other things the Kanban method encompasses 6 practices –Visualize [work and workflow], Limit work in progress, Manage flow, Make policies explicit, Implement feedback loops and Improve Collaboratively, Evolve Experimentally.
By applying only two of them – “Visualizing” the real workflow and “making [the real ] policies explicit” – you already can find out if there are product owners in your actual workflow. And by applying the other practices and policies you can evolve (step by step) your technology business to an organization that is fitter for purpose than it is today. But that would fill a whole book. Or several. :-)

till next time
  Michael Mahlberg

Monday, May 27, 2019

We need more "Wax on - wax off"

(Thanks to Falk for brining up Mr. Miyagi here)

If you have never seen – or heard of – the 80ies movie “The Karate Kid“ the phrase “Wax on - wax off” probably won't mean much to you. Fair warning: spoilers ahead!

Amongst other things that happen in the movie, the relevant part here is that Daniel learns karate from Mr. Miyagi, the handyman for the family's apartment. Without delving too deep into the story, in the beginning, Daniel is demanding from Mr. Miyagi that he wants to learn kicking and punching, but Mr. Miyagi stalls him for quite a while giving him seemingly unrelated tasks to do in very specific manners. For example, Daniel has to shine a considerable amount of classic cars following a very explicit process, using one hand to apply the wax (wax on) and the other to polish (wax off) in precise circles. After a number of chores Daniel gets unhappy with being Mr. Miyagi's “slave” and Mr. Miyagi demonstrates that all those “chores” actually built capabilities which Daniel didn't have before and all the “techniques” he learned, like “paint the fence”, “sand the floor” or “wax on – wax off” could actually – once they where mastered – be quite powerful and effective tools (e.g. defensive karate techniques and blocks) that Daniel would use throughout his further Karate training and his tournaments.

Side Note: Of course there are clips on youtube depicting the "building the muscle memory" part of the story as well as for the part where “the learnings are applied.”

How does this relate to agile?

To me, it seems we have a lot of focus on advanced agile topics and managing agile teams (and I‘m not even talking about scaling agile) and less and less on the basics of working in an agile manner. But from my experience, it is paramount to have the basics at your disposal all the time. Even with all the “Agile Mindset” in the world a racing car team (like Wikispeed, who actually apply lean and agile approaches to building race cars) would not have much success if their team members weren’t highly skilled in their respective crafts. You can’t pick a random person from the street and just expect them to be proficient with a Torque wrench or a Gas metal arc welder.

IMHO honing the basic skills would do many agile initiatives good. Speaking from my personal experience, even if it seems tedious and even if it is not the sexy “punching and kicking” - every now and then it does help a lot to focus more on “wax on – wax off.”

till next time
  Michael Mahlberg

Sunday, May 05, 2019

Scaling ≠ at scale – Remember: «at scale» means something different than «scaled»!

It might be because I'm not a native speaker, but there is something about "scaling agile" or "scaled agile" that really has been bothering me these last couple of years.

As I wrote before in my recollection of events agile was described as something that works well for small teams.
IMHO at least two of the principles, namely "face-to-face communication" and "architectures, requirements and designs from self-organizion" are extremely hard to do in larger groups – unless you add additional constraints like structures (aka hierarchy) or special roles outside each individual group of people or team (aka specialists).

So what are we talking about, when we talk about Agile at scale? At scale means (according to to have something that is "at the required size to solve the problem." Scaling on the other hand means "a linear transformation that enlarges or diminishes objects."

What does that mean for scaling agile approaches?

Do we really want to scale e.g. the number of people involved in solving one specific problem? Because, actually the communication overhead does not scale linearly – it 'scales' according to Metcalfe's law and thus communication quickly becomes inefficient. (With 5 people there are only 10 unique ways of communication, with 12 people the number is already 66)

Therefore: Why do we keep talking about "scaling agile?"

I think we should talk about "appropriate solutions at scale" and strive for them. That might include approaches from the lean and agile communities, some implementation of the Kanban Method to facilitate the change and many other ideas that are appropriate for the actual challenges at hand. When we truly live in a volatile, uncertain, complex and ambiguous world, than maybe the solutions for big and complex organizations can also only evolve over time according to each specific organization.

till next time
  Michael Mahlberg

Sunday, April 14, 2019

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.

Sunday, March 31, 2019

How to visualize the (IMHO) most important metric of the Kanban method

In my humble opinion the Lead Time Distribution is the most important metric in the context of the Kanban method.

Your mileage may vary, but that would be the topic for another post.

A brief mailing list discussion about ways to get this in Excel triggered me to make a list of some of the approaches I use to get to that metric. (Only some of them with Excel)


  • Google Spreadsheet approach
  • Hand-rolled Excel
    • Percentiles for given durations
    • Dates for given percentiles
  • More versatile hand-rolled approach w/o Excel
  • Closing thoughts

Plot and percentiles in Google Spread-Sheet

I would feel remiss not to mention the works of Emily Webber:

This gives most of one could want for the evaluation of a physical board.

Unfortunately, it isn't Excel yet, but "only" google-docs. Exporting to Excel "kind of" works, but the most important formatting is rather distorted, so I wouldn't exactly recommend that route to get to Excel.

Maybe it is right for you, maybe not. Give it a shot.

Percentiles per given durations in Excel

I used Excel quite often to generate percentages (not yet percentiles), usually inversely by pointing out the percentile that a given duration falls into.

This leads to heat-maps like the one on the right (from my talk at the 2018 LKCE ) but you don't necessarily get the exact numbers for the percentiles – and it is achieved by a concatenation of manual bin sorting, Summing up the results for each bin and comparing that to the maximum number of occurrences for this type of work.

You can find a simplified example (for only on type of work) in [this Excel-Sheet.]( The raw data is in the first tab, the bin definition in the second and the evaluation in the third. All tabs are named accordingly.

Durations for given percentiles in Excel

Excel already has a built in function called PERCENTILE which yields the mathematically correct percentile over an array of numbers (e.g. lead-times)

For the Emily Webber Data this looks like this: (In the German Version of Excel they translated the names of the functions and hence PERCENTILE is called QUANTIL)

The more flexible approach (without Excel)

Still, sometimes this is not quite what you need and the whole structure of the "chains of Excel spreadsheets" which tends to arise from the Excel-based approach tends to become too brittle (or too solid) after the first two or three improvements-loops.

Nowadays I recommend evaluating Jupyter Notebooks for this kind of scenario. It seems to require programmings skills, since the statistics approach is based on (amongst others) Python, but actually it is quite approachable and most people who are comfortable with complex Excel sheets tend to fall in love with it quickly.

My colleague Martin for example is using this approach for a very flexible evaluation of data collected from physical boards.

It can look like this, but can be easily extended if you need more complex statistics or shapes.

Closing thoughts

IMHO – provided the work-items are coarse grained and the time you want to inspect is not too long – oftentimes it pays to ditch electronic tools in favor of more mechanical approaches as outlined in the talk I mentioned above. (Unfortunately in German)

And for more elaborate mathematical elaborations while still working in Excel I find Troy Magennis Excel-Sheets an extremely helpful ressource.

till next time
  Michael Mahlberg

Sunday, March 24, 2019

Attention bias or Dunning-Kruger?

There is a lot of talk these days about the Dunning Kruger effect and cognitive biases in general like the fundamental attribution error or attention bias. While the Dunning-Kruger effect essentially describes the learners misinterpretation (notably: overestimation) of their level of competence after they have acquired the basics of a topic, it is often used for bashing people who seem to be over-confident without really knowing much about subject they are talking about. But does it always have to be just Dunning-Kruger? I don't think so.

A while ago, someone made a nice – or rather not so nice, but unfortunately very on point – joke about the incompetence of a company that wanted to hire a developer with "8+ Years of Swift experience" in 2018, pointing out that the programming language Swift came into life only three or four years before that.

Being annoyed with a lot of enterprise recruiting myself I answered with a picture of the Suzuki Swift car that was in production from 1983 onwards...

After some laughter we realized that we had fallen prey to some kind of bias, because actually Swift as a programming language is way older than Apple’s incarnation of it. There is a scripting language called Swift, targeted towards parallel processing in the high performance computing area) ... from 2007.

We obviously fell prey to cognitive bias, but I'm still struggling to find out which one.

But that was a good cue to pull out my favorite visualization cognitive biases that used to be part of the wikipedia article on cognitive biases, but now they have a really stunning list of cognitive biases.

The fascinating take away from this whole story for me was, that for days after I had toyed around with the infografic and the list, I caught myself repeatedly being more aware of potential cognitive bias pitfalls. It might not help against the Dunning-Kruger effect (or does it? I don't know, I'm not an expert in that area ;-) ), but it surely helped me with looking twice.

Or –as Alan Lokos might have said once– "Don't believe everything you think!" :-)

  Michael Mahlberg

Sunday, March 03, 2019

What change initiatives can learn from steam engines

[I once saw this on a slide at a conference – I'd love to give due cerdit,
but I can't find the original source. The conference was “Tools 4 Agile
Teams” 2017, but I can't identify the session in this picture]

Structure > Culture > Strategy


Structure trumps Culture trumps Strategy

That sounds catchy, but actually there also is quite a bit of a story behind it.

The second part originates from the almost famous quote “Culture eats strategy for breakfast" that is often used to explain why so many strategically motivated changes just dry up at the department or team level.

The first part comes from what Craig Largman calls “Larman's Laws of Organizational Behavior” in which #5 reads "Culture follows structure" and implies that culture itself can not be changed directly but only by changing the structure.

Whether these statements are true is hard to decide – neither of them claims to have any hard scientific evidence. I, for one, certainly have seen more than one case where these observations not only held true, but were also helpful to keep in mind.

A great example on the domination of structure over the other aspects comes from a blog-post on the time when steam engines started to be replaced by electric motors. At that point in time, steam-engine powered factories had widely replaced individual workshops and the usual layout of the shop floor was optimized to make the best possible use of the power provided –via mechanical shafts– by the steam-engine.
Along came electric motors, which –theoretically– offered a huge benefit in efficiency and effectivity. But when factories shifted to electric motors nothing much changed initially. Simply replacing the gears, shafts and belts of the steam engine didn't really enable more efficiency or effectivity.
Only when the factories started to change the fundamental way they worked did the electrification make a difference. Once the newfound flexibility was leveraged and the shop floor layouts were rearranged to follow the flow of production work, a steep increase in both effectivity and efficiency became apparent.

Kind of how agile approaches to product development enable business agility, but need to be leveraged to really make a difference.

till next time
  Michael Mahlberg

P.S.: I haven't yet read the book on “Building the Agile Business“ that Peter Abraham and Neil Perkin wrote (simply because I didn't find the time to read it yet) but I do love at least one of the points they make in their above mentioned blog post. So by now the book is definitely on my "to read" list.

Sunday, February 17, 2019

Know thy commitment! (In Scrum or in Flow)

I wrote about commitments and commitment points earlier – this is a condensed version focusing on the distinction.

Commitment in Scrum (as part of the planning) was about the promise of a group of people.
(Caveat: The term is not in the Scrum guide in this way anymore)

Commitment in Flow is about the status of a work item.

In flow-based systems, “committed” for a work item means that this work item is being worked on now.

The work item is meant to be neither idling nor pulled back from the workflow until it is released (to the customer to whom it is meant to be of value).

In Scrum, “committed” for a team meant that the team strives to achieve a goal by all means necessary.

The team was meant to work towards this goal and deliver something that enabled the negotiated customer capability.

“Just” a distinction to be aware of in discussions about commitment...

till next time
  Michael Mahlberg