«Creating Feedback Loops» is not about having meetings

In many modern approaches to work, like The Kanban Method, Lean Startup, Agile Software Development, or DevOps, Feedback is an essential part of the approach.

Sometimes the role of feedback is explicit, whereas in some cases it is more of an implicit assumption that is only visible upon deeper inspection.

The Kanban Method has it pointed out explicitly as (currently) the fifth practice (Establish feedback loops) while the DevOps movement has one of its "three ways of DevOps" dedicated to it (The second way: the principles of feedback) which in itself consists of five principles.

“Let’s have more meetings” – a common misconception

Unfortunately, some of the currently popular approaches have introduced the notion that implementing feedback loops implies having some special meetings for feedback.

Feedback like that, could be a daily meeting regarding the current status of the work – especially focusing on problems or things to solve, or an event-based meetings, like post deployment retrospection.

For example, if you look into The Kanban Method, you'll find a whole slew of other meetings to be held at different cadences to foster more feedback in your work.

While these meetings can be very helpful, they are not at all the best way to get real feedaback, really quick.

The problem with meetings as the primary source of feedback

The trouble with feedback that only comes periodically, and is dependent on human interaction, is that most of the time it comes too late.

Consider some feedback loops from outside the work organization world:

• The speedometer of your car gives you feedback about your current speed – just waiting for the speeding tickets to come in would be way too slow as a feedback loop.
• Or how about another thing in your car that you get information about: the oil in the motor via the oil warning lamp and the oil dipstick. For certain kinds of information the dipstick, at which we look from time to time gives us enough feedback. For the important short-term feedback that the oil pressure is too low, we need faster feedback. That's why your car comes with an oil pressure warning lamp.

How can we create feedback loops inherent in the ways we work?

What we actually want when we talk about feedback, is usually a very prompt response from the system we are interacting with. This system can be anything from a technical system through a physical system or a mechanical system to a system consisting of people interacting with one another.

One of the best ways to get early feedback is to actually remove inventory.

You may have heard that removing inventory is a central tenant of all the lean approaches, but when thinking specifically about feedback, removing inventory has the added benefit of making sure that we get our feedback earlier.

So really, what we mean by “creating feedback loops” is finding ways to see the final impact of the things we just did as early as possible instead of waiting for the effects to happen somewhere very far down stream.

till next time
  Michael Mahlberg

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

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.”

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.

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…).

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.

Colors?

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.

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

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.

Therefore:

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...]

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.

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 YourDictonary.com) 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

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)

Content:

• 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: https://emilywebber.co.uk/a-tool-for-tracking-kanban-projects-that-you-can-cut-out-and-keep/

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.](http://www.consulting-guild.de/files/ExampleHeatMap-GeneratedData.xlsx) 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

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

or

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.

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

Why all the boards for your lean and agile teams should be visible all the time

A simple answer would be: spatial memory.

A slightly longer answer could be: spatial memory and confirmation bias.

(Oh, and by the way: They should be visible all the time only for the people who need to see the information on them)

But let's put that into context. Why are spatial memory and confirmation bias important for the way we use boards in Agile teams?

As many people have pointed out in the past Agile doesn't fix any problems, it just makes them visible, so that it is easier to do something about them. One of the tools agile teams started to use early on to facilitate this is visualization. A team, working towards a goal, visualizes the information they need to know about. This can be all kind of information –which might be a topic for another blog-post–, but one of the most prominent visualization techniques is the taskboard. Taskboards are especially helpful for knowledge workers because the very nature of our work makes it impossible to directly perceive the status of the work – let alone knowing how much work is currently in progress. The Kanban method went so far as to have the notion of ‘making invisible work visible’ at its very heart, albeit many so-called Kanban-boards are merely task-boards.

To really make use of this visualization we need to leverage spatial memory and counter confirmation bias.

Why spatial memory?

If the great benefit of (Task-)boards is, that they make work tangible and agile only makes problems visible, then it is important, that we help our brain to make use of this information. With a visible board, it is plausible that the amount of information displayed is still manageable. With electronic boards on the other hand: not so much.

Physical work (what David Allen –of getting-things-done fame– calls "cranking widgets") takes up a defined amount of space and most of the time also a defined location. So, for example, when working on some home-made stuff, during sanding it is easy to remember that “the blocks on the left side of the table still need work, and those in the upper row need some special treatment because they felt ’strange’.“ In this case, ‘left-hand side’ would be associated with unfinished and ‘top row’ with special treatment needed.

Likewise, if we have a number of boards physically placed throughout the workspace, location gets mapped to meaning. After a while, we just ’know’ that we have to look at the board on the wall behind Jenny to see the current status of Portfolio initiatives. Or at the board in the hallway to see the state of affairs with regard to the committed user-related features.

One could argue that having electronic boards for the same information works almost the same, because with electronic boards we just ‘know’ that we have to go to «boards»->«companywide»->«MyDepartment»->«Initiatives» to find the portfolio information and we have to go to «boards»->«MyDepartment»->«Stories» to see the committed user-related features. But this draws on a different kind of memory, which is accessed a lot slower. And takes more energy to activate. At least that's one of the learnings I took away from Sharon Bowman’s “Training from the Back of the Room”.

Even our figures of speech are quite informative here. Getting a ‘picture or the situation’ or having the ‘big picture’ are good examples of this.

And glancing at the walls just takes somewhere between a fraction of a second and a couple of seconds, depending on how much information you want to absorb. It even happens without conscious effort. Just walking by the feature-board in the hallway and the portfolio-board behind Jenny's desk gives you a certain amount of situational awareness - whether you want it or not.

What about confirmation bias?

Unfortunately, even though one of the original ideas behind Agile approaches was to make problems visible most humans are influenced by confirmation bias. We tend to look for helpful clues to help us to confirm whether a course of action is feasible. In earlier times that was helpful – and it even is helpful today as Jeffry Levine explains convincingly on quora. We wouldn’t be able to act in the world if we didn’t apply filters to the huge amount of information that comes at us all the time. And re-thinking topics we already thought about would –most of the time– be a waste of the rare resource mental power.

One of the implications of this is that we –in general– don’t go out there and look for things that are not as expected. We probably won’t open the portfolio board every day to check whether the portfolio item that our current feature relates to just got flagged ‘canceled.’ And neither is it likely that all portfolio managers look at the detail boards all the time. But, in my personal experience, they develop quite a keen eye for an agglomeration of blockers on features if they pass that wall several times a day.

To help people tackle problems and issues they care about it does help to make this information visible. Especially in those cases where nobody would actively look for the unwelcome information.

It's called visual management for a reason

Even if Agile and the Kanban method have both somewhat evolved from their roots in Lean, the whole board idea is based on visual control and the enormous lever for self-management it provides.

So, if you use boards, make sure the important ones are visible all the time to the right people.

till next time
  Michael Mahlberg

The Anti-Pattern of Jira-(Mail)-Notifications

When you use Jira the way it was meant to be used – as a bug tracker with customer facing interfaces – it might be quite okay to use mail notifications. after all, in this scenario it is quite possible, if not even intended, that issues enter the system without any interaction from the people working with the system.

If you use Jira as a replacement for a physical (agile) board things are different.

One of my favorite tweets reads something like “Individuals and interactions over assigning someone a jira ticket without even talking to them.” This not-so-subtle reference to the first value-pair of the Manifesto for Agile Software Development summarizes nicely what’s wrong with many so-called(2) agile projects these days. There are other things as well –lots of them actually- but for now let’s track focus on this issue.

The original statement "[…we have come to value] Individuals and interactions over processes and tools“ puts a very strong focus on people and their interactions. And in the early agile projects I experienced (around the turn of the century) that was a big part of what it was about. Visualization (index cards pinned on boards) was mostly used to enable self organization and document thing that the people already had talked about. As a friend of mine pointed out much later, when asked about using a physical boards: “The intelligence congregates in front of the board.“

When working in an agile team (e.g. a team really using XP) and if that team decided to use a (physical) board, everyone sitting in the vicinity of the board notices when something the team is working on changes its status. Because each time something enters a new state –a state for which the members of the team themselves have decided that it is relevant for their work–, a person walks up to the board and moves a card. Whether or not that is of interest right now is everyones own decision. But –since the whole team sits together and works on a common goal, without several other project interfering from the side– it is very probable that people will come and have a look rather soon. Even though they would all be informed at the next standup anyway.

This approach is quite powerful, when the cards represent things the people who work with them actually know.

Appearance: Real Life Jira Notifications
“Jira mail notifications do exactly the same” - yes, sometimes they can... “and you don‘t even have to be in the same room” – yes, that is where the trouble starts (because for all Jira knows, you could be in several rooms at once) “and you can even have them for lots of projects” – yes, and this is where it really starts to become a problem. (Because in real live we have those boards in different rooms and we only notice thing that happen where we are. When we get information for things that are not relevant for us now we tend to go numb for that input channel to avoid information overload.)

I saw many organizations where people configured their mail-program in such a way, that Jira notifications got sorted away without ever distracting them from important work. (There words, not mine. Seems to me like those notifications where not important for what they did most of the time.) For me this is the final indicator that the organization has started to value tools and processes over individuals and interactions. In an Environment where the board has the same importance that the physical boards had in the early days, it would probably be visible all the time and everything that happened on the board would be of at least some relevance to everyone in the team. Because –as mentioned earlier– they all work on the same goal. Of course that is not feasible for all environments, but then maybe other approaches would be more useful. But that would be another story.

If you try to work in an agile manner and think you need Jira mail notifications something might be wrong. If you work in a lean manner things might be slightly different but only to a point. And once you “need” mail rules and filters to manage your jira mail notifications, something definitely is wrong from a lean and agile point of view.

Give switching of those notifications a try – after all, you can always look at the board to find out what’s up - can’t you? (If you can’t you've got yet another problem)
Try to find out what you loose if you switch them of altogether and devise ways to address those needs. (Mail-Notifiations might be helpful in a distributed setting, but then again an IP-connected Lava-Lamp might be helpful for more than just the build status...)

till next time
  Michael Mahlberg

What’s up with all these Manifestos?

We all know the Manifesto for Agile Software Development, right?
Well, all generalizations are dangerous. And the idea that the Agile manifesto is well known doesn’t hold much substance as soon as we talk to people who are not part of the Agile movement. The word “Agile” in itself seems to be well known by now - the Agile Manifesto not so much.

Not only are a lot of people unaware that there actually is a second part of the Manifesto, containing the twelve principles of Agile Software Development. Many people I speak to haven't even actually read the first page, containing the value assumptions of the Manifesto for Agile Software Development.

What happens if “Agile” as a concept spreads so widely, while only few have actually read the original manifesto?
For one thing, there are a lot of different interpretations out there. I guess that would be the case even if everyone in a so-called Agile project actually did read the full Manifesto, but the fact they didn't, doesn't exactly make it better. Probably related to this, there is a phenomenon I have observed within the Agile community: a growing frustration with bad implementations of Agile and the whole "Agile Industrial Complex."

What about the Manifestos?

Some people took it upon themselves to point out some of the worst interpretations of Agile by creating manifestos that highlight specific anti-patterns.

The “Dark Manifesto for Agile Software Development”

The dark manifesto highlights an anti-pattern that I would call “superficial Agile.” It manifests itself in just focusing on the left-hand side of the first page of the manifesto –the things valued more by the creators of the Agile manifesto than those on the right hand side– without looking at the right side or even going into the depth of the principles.

The “Manifesto for Half-Arsed Agile Software Development”

This manifesto focuses on the problem that organizations, that grew big by applying a non-Agile mindset, probably (often, in my experience) have a hard time really embracing an Agile mindset.

The “Agile Quitters Manifesto”

The Agile quitters manifesto is a very glum or even bitter statement about many things that derail Agile intentions nowadays. Basically I translate its message as “If you want the benefits of Agile, get out of the Agile Industry.”

Unfortunately, these ironic and sometimes even sarcastic manifestos only speak to people who share the mindset and experience of those who wrote them. To others –especially without explanation– they often look like people whining without making any suggestions on how to improve the current state of affairs.

Serious critique by Uncle Bob

In his 2014 critique on the corruption of Agile Robert C. Martin (one of the original authors of the Agile Manifesto) already pointed out that there is a real danger in focusing either on the cultural aspect of Agile or the practices aspect of it.
His conclusion:

“Agile is a culture expressed through a set of practices“

is something we should try to keep in mind.

Suggestions and a call to action by Martin Fowler

In his keynote at Agile Australia 2018 Martin Fowler, another original author of the Agile Manifesto, took a more positive stand without ignoring the fact that a lot has gone wrong with the current way Agile is spreading. But he also encourages all of us not to go the way of the Agile quitters but instead carry the Agile movement forward.

So now what?

Let's not get frustrated by these Manifestos, but instead let's take them as a warning sign and try to bring reason and meaning back into Agile. Let's put more emphasis on “starting where you are now” and “evolutionary change”, as Kanban-Lingo would have it. Evolution in this sense means selection of the best fit. The best fit for the current situation at this point in time. And what constitutes “the best fitting solution” is certain to change over time. As Keaynes allegedly said “When my information changes, I change my mind. What do you do?” – so stop imposing one-size-fits-all-solutions on people and perhaps try an alternative path to agility. Don’t focus on “scaling Agile” (which is kind of an oxymoron in itself), but instead try to be Agile in your teams. And maybe have a look at evolutionary models to build Business Agility.

till next time
  Michael Mahlberg

Meeting hacks: playing the right cards

Some meeting run very smoothly. Others don't.
For today let's look at one special kind of meeting - requirements preparation (refinement meetings –to use scrum-inspired lingo– are one instance of this meeting type, but there are many others that fall into the same category). Those meetings share some common attributes:

• Usually they are time-boxed
• The intention is to talk about numerous topics of a similar nature
• All of the discussed items should be elevated in quality, depth or detail to reach some –more or less well defined– threshold
• [optional, but very common] Often those meeting tend to overrun and annoy a lot of the participants

How to make it better

With experienced participants or an experienced facilitator, these meetings tend to run much better - neither breaking the time box nor annoying the participants. What can we do to make this kind of meeting work better for teams without a facilitator, or those just starting of with the practice? Over the years I have seen two behaviors that seem to drive up both the annoyance-level and the time required for the meeting more than most others.

Too much detail

The first behavior we tend to fall into, is to discuss an item in way more detail than is required for the current level of decision making. A special case of this is bike shedding where almost everyone is discussing details of an irrelevant topic because that happens to be the easiest way to contribute. But even without this phenomenon, it happens all the time and with the best of intentions.

Off-topic discussions

Another driver for the discussion going ‘off the rails’ is exactly that: getting off-topic. Often by deepening the discussion on topics triggered by talking about the original item, but actually straying away from the context of the item under discussion. Even worse, many of these spontaneous discussions completely disregard the purpose of the meeting and morph into heated arguments about unrelated issues.

Cards on the table

Oftentimes, some of the people in the room may notice these effects, but due to a number of phycological barriers, it can be hard for them to voice their concern. Reasons not to speak up might be the impression that they are the only ones with that concern, past experience that trying to stop an argument only extends it, a difference in rank and many others.
Using playing cards (or planning poker cards) as a means to assist in the management of the two behaviors mentioned above, has proven to be an effective self-facilitation tool. I typically use the Aces and the Jokers from a traditional card deck or the question mark and the coffee cup from a planning poker deck.

• Ace indicates that the discussion is lost in detail
• Joker is used to denote the fact that the discussion has run off-topic.

When using planning poker cards I tend to use the question mark as a symbol for too much detail and the coffee cup to indicate getting off-topic.
In any case it is a good idea to post the rules visibly so that the group doesn't have to remember –or even discuss– the meaning of the cards.

Rules of engagement

Just discussing the meaning of the cards and being physically in possession of them already raises everyone’s awareness of (at least) these two ways to derail even well-structured elaborations, but some additional rules on how to use the cards make this technique even more valuable.

I suggest these three rules:

1. If one person holds up an, card nothing happens. The discussion may continue. (This allows for a simple verification of the personal impression without interrupting the potentially important discussion and simultaneously gives permission for other people to ‘voice’ their opinion.)

2. If a second person holds up a card of the same type the discussion is tabled for the moment, and a reminder to pick it up again is posted on a jointly visible spot. (I also reduce the time of the main discussion by a minute or so –depending on the group– for each Ace.)

   Furthermore, I tent to use two different spots for the different types of cards, because those different concerns need to be addressed differently. In most cases I find it important to make sure that the Aces (too much detail) get picked up before the meeting is closed.

   It is up to the participants whether they want to do anything about the Jokers after the meeting, but for the Aces the next (third) rule seems to be an extremely valuable practice:

3. Take time at the end of the meeting to agree on a further course of action for each of the topics posted under «too much detail». For those items the ‘course of action’ tends to be an agreement on «who is going to clarify the details with whom until when?» (Pro tip: Don't elaborate on the details in this meeting, just schedule a follow up meeting and agree to convene again to share the results of that meeting.)

Since I started using this approach, I've seen a steep improvement in the way people conduct refinement meetings, Sprint-Plannings and other “lets discuss this number of similar topics in a fixed time” meetings.

Maybe this approach also works for you?

till next time
  Michael Mahlberg

Negotiating changes

aka “What’s all this talk about «experiments» and «safe to fail» about?”

Inspect and adapt may sound nice, but all too often, I only see adapt. Without inspect. That’s one of the reasons I like the more systemic approach from Kanban so much:

• the Principle: Agree to pursue improvement through evolutionary change
• the Practice: Improve collaboratively, evolve experimentally (using the scientific method)

What's the big difference here?
Most of all, using the scientific method implies an approach based on observable effects of changes. Concepts like the Cynefin Model or the Toyota Kata include things like a ‘probe’ – a safe to fail experiment.

Let's illustrate this with an example from a “scrum by name”-team from the recent past. After some tension about a change, a friend of mine –who was responsible for organizational matters in that situation– agreed to “go ahead and implement the idea”, adding that he already knew that it would be “a waste of time.“
For me this approach was a good example for the traditional mindset of simply adapting without employing the scientific method.

Whatever one did in that situation, it should not be a waste of time. As the late Jerry Weinberg once said: “You can’t always win – but you can always learn.”

Instead of simply implementing that change, the systems thinking approach would be to run it as an experiment!

So what would that mean?

• Firstly talk with all parties concerned about the (observable!) attributes of the work that should not change (e.g. «the Standup should not become longer») and how to measure or recognize any unwanted changes.
• Then talk about the things that should change and how to measure and recognize these changes. And don’t forget that you need a baseline for that – otherwise it’s hard to recognize whether things have improved or not.
• Agree upon the next time you evaluate the data and decide on whether you want to proceed with this change you're experimenting on. You might want keep the change, roll it forward or roll it back.
  Rinse and repeat. (This is by the way one way to implement a PDSA loop)

A concrete example

This may sound difficult, but coming back to an example from an earlier post –having the PO attend the daily Scrum– it may be as simple as:

• We don’t want the daily Scrum to be longer than it is now and we don’t want an increased number of meetings with the PO. Now we have 15 minutes standups and an average of 4 meetings with the PO per week.
• We do want the PO to be have more situational awareness. We would know that if he called us less often about the schedule. Today he calls every other day.
• We will decide how to proceed in three weeks after we lived through one and a half iterations or if the daily is longer than 30 Minutes twice in a row (this part of what makes the experiment safe to fail, along with the small size of it).

[BTW: ‘We’ in this example might or might not include the PO - that’s a question of the individual setup and the maturity of the team and organization.]

Now if the experiment ‘fails’ (e.g. the things that shouldn’t have changed changed and those that should didn’t) that still delivered value: the team learned that they need a different way to involve the PO and can work on other approaches to include them. If, on the other hand, everything works out as desired it is just a matter of agreeing to continue with those new rules.

When thinking about feasible experiments (also called probes) I also like the question I learned from David: Is it small enough to try and safe enough to fail?

Happy experimenting!

till next time
  Michael Mahlberg

The Product-Owner as an antipattern

Do you know a project with a real product owner?

The clue is in the name. It actually consist of two parts. ‘Product’ and ‘Owner’. Most POs (as product owners in my neck of the woods tend to be abbreviated) neither have a product nor do they own it.

Recently the PO topic came up in a discussion about The Rules of The Scrum Process. (FWIW: Scrum is not a process but a process framework and thus the ‘rules of the game’ apply to the meta-level and transcend only transitionally to the implementations)

Case in point: Does Scrum allow the PO to be present at the Daily Scrum? Notwithstanding the endless options to find the right answer (see sidebar),

e.g. due to the different possibilities to emphasize todays scrum guide’s “The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.” –one could either stress the internal meeting part or the others are present part, or the multitude of possible interpretations for the quote “Anyone who needs to know what’s going on with the project can come to the daily scrum and listen”[emphasis added] from Ken Schwabers original book, [p40].

the most important question for me was:
“Why is it so important to answer that question?”

It turned out that the developers in that team where afraid that the PO would be worried by what he would hear in the daily scrum, the scrum master was afraid that the developers would not speak as openly as necessary if the PO were to be present.

For me this situation contains an alarming amount of alarm signals with regard to the scrum values of openness, courage, and respect as well as for the scrum pillar of transparency.

If Product Owners are frightened by the things they hear in the daily scrum –and worse: take action based on the information they gather from the daily scrum- the Scrum Master has a lot of work on her –or his– hands to establish transparency and foster courage. (But please keep in mind that it’s not yet possible to install values.)

A tangent on this topic was that the Product Owner doesn’t understand the developers and thus should not hear them talk amongst themselves about challenges they face. To me, “The PO doesn't understand the developers” is a very good description for a (team-) culture that is quite dysfunctional for Scrum.

[So perhaps scrum isn’t the best choice for the situation at hand - how about trying FDD or DSDM? But I digress]

Of course the Product Owner doesn't have to know everything. Quite the opposite actually: they are even encouraged to delegate. According to the 2017 Scrum Guide: "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

Of course, if the Product Owner does delegate some of their work to the team, that would probably turn up on their task-list as well. And since “Ensuring the Development Team understands items in the Product Backlog to the level needed” is also part of the PO’s responsibilities, they would have to interact with the team even more. Probably even become part of the team. Which would nicely fit with the old eXtreme Programming value of the on-site customer.

So why did I call the Product Owner an anti-pattern?
Because most of the time they aren’t. They neither have the final say regarding the ordering of the items to implement, nor do they have a real chance to influence the economical outcome of the work. They simply don’t own the product.

So perhaps –whenever we see a Product Owner who isn’t– let’s take a step back from using the Scrum term of product owner and look around for things that are actually happening (Kanban people might call that: “start with what you do now”).

Perhaps even try to look out for some other agile process templates which maybe fit your reality more closely.

till next time
  Michael Mahlberg

What is a commitment point anyway?

In some way, commitment is part of almost all project work. The term used to be part of the planning ceremony/event in Scrum (actually it has been for quite a while since one could find the snippet ‘commit’ outside the ‘values’ section of the scrum guide. See the history of the Scrum Guide, section “Changes between 2010 and 2011” for Details) and the term ‘committed work’ comes up over and over again when talking about flow based systems. (Those flow-based development processes often come together with application of the Kanban Method)

Commitment in Scrum

Even though the notion of committing (and thus promising) to the result of the planning meeting has been thrown out of the window some years ago, the notion is still very much alive out there in the fields.
The general idea here is that the team commits to a Sprint Goal often backed by a bunch of backlog items, and the ‘commitment’ here is the (not always realistic) idea that the team will deliver and reach the sprint goal by the end of the sprint. Which is actually consistent with what Ken Schwaber wrote about Scrum in the early years – you might remember the ill-suited story of the chicken and the pigs that also vanished from the Scrum Guide between 2010 and 2011.

The main takeaway here is that with this kind of planning commitment relates to the result and says nothing about the way the work is performed.

Commitment-points in Kanban-Systems

In the World of Kanban the notion of commitment is different since Kanban is not a software development process but a set of principles and practices for process improvement and organizing work.

Many of the processes which teams create with Kanban tend to be flow based and thus ‘commitment’ most often refers to a point in the workflow where the ‘unit of work’ is committed into the system. From here on its flow is governed by the process policies (working agreements) and WIP-Limits.

A while ago I wrote about a problem with unbounded –or uncontrolled– columns for requirements and how it can be addressed by making only promises about things that are under voluntary control. This is actually the introduction of commitment points.

The change from red to green in the last picture of that article illustrates the commitment point for the development workflow. From here on the work is committed into the system.

Effective difference

Commitment in Kanban controlled flow processes is an attribute of the system, not something that Managers can hold against the team. It is not a promise for some point in the future (the System under development will be able to...) but it is the fact that this item is now in the system and will be worked on according to the explicit policies the team agreed upon.

And that is a promise that –most of the time– can be kept. Together with other attributes of Kanban-Enabled Systems this makes for much more reliable forecasts based on systemic behavior and measured data.

What is the ideal WIP?

Well - that depends.

Simulations like TeamFlow seem to indicate that a WIP-limit that is slightly below the number of people in the team is ‘optimal.’

On WIP-Limit size

But then again, there are so many constraints possible. If you want to encourage pairing in a software development project (teamsize/2) - 1 might be better. If you want to allow for some slack perhaps (teamsize/2) + 1 might get you there. And of course the handling of commitment points – the points, where work enters the controlled part of the system – also matters a lot. Do you start to limit your work in progress only after the analysis has been done? Or do you start at a the conception of an idea? Do you have different limits for different types of works? And how about policies when you the exceed those limits?

On finding right numbers

For me it is not so easy to answer the question about the right limits. That’s why I find it important not focus exclusively on WIP-Limits when it comes to implementing Kanban, but also to embrace the other principles. Especially “Agree to pursue improvement through evolutionary change” together with the practice to “Improve Collaboratively, Evolve Experimentally.”
This also means, that one should follow the scientific method formulate the hypothesis about the way you want to influence the system (or process), designe an experiment to verify or falsify that assumption, execute the experiment and only thereafter implement the change. Or design a new experiment if the hypothesis was falsified.

till next time
  Michael Mahlberg

“How can we balance agility and stability?”

... is a question I have been hearing since 2003, or so. As far as I can remember, I wrote my first piece with an ISBN in 2004 on that subject ("Agil, aber Stabil", GI Jahresband)

But I don't really get it.

What is there to balance?

I hear people arguing that agile would be harmful because the interfaces (be it APIs or human-machine-interfaces) could “change any time.” Or that requirements would change so quickly in agile, that it would not be possible to achieve bigger goals.

That’s actually not what was intended originally. The “Systems Metaphor” in XP (one of the first agile Methods) was meant to be extremely stable. And Scrums original 30 day iteration was meant to protect the team from ever changing requirements.

There even was a thing called “release planning” in Scrum – planning concerned with long term goals.

Most agile methods actually promote stability – the agility is about adapting to changing situations and especially adjusting the process.

So there is no need to balance agility and stability. Adopting agile practices –especially when enriched with some Kanban and Lean thinking– actually creates stability.

till next time
  Michael Mahlberg

The Trouble with Jira

The trouble with Jira isn't (only) the trouble with Jira. It’s rather the way it gets used.

Remember “Context is king” - Jira might well be an excellent bug-tracker. As an Agile and Kanban tool the opinions definitely differ. From my personal experience with many real life implementations I would say that Jira is one of the bigger issues preventing an agile mindset. People from the Lean and Agile communities tend to agree in private conversations (and some even say things along that line of reasoning on twitter).
But as soon as corporate reality strikes, those voices get less loud and the conversation shifts more towards “It can be made to work – millions of users can‘t be that wrong.”

Well, if we have to “make do with what procurement decided to buy”, here are some things I consider to be vital to make it at least not unbearable.

Something like Jira should be a tool. But it should be only one tool. Amongst others. Not the ”one tool to rule them all.”

As long as you have

• enough machines available to permanently display uncomfortable information (and a way to secure them from unwanted access) (Permanent: Without exchanging content every few seconds – yes, that might mean e.g. two different machines, or at least displays, for boards at portfolio level and at team level. In the same room. Gasp!)
• enough rights for the people who actually use the boards to edit boards on the fly (and the same for workflows, if they choose to do so) whenever the teams needs to
• enough knowledge in the teams to be independent from central administration
• the willingness, tools, and knowledge to generate additional information (mostly statistics) outside of Jira

you'll probably be fine. (-ish)

Otherwise – in my experience – you’ll soon hit a glass ceiling consisting of (amongst other things):

• change cycles (to Jira related things) that take longer than an iteration
• information buried in dashboards that are theoretically available but never looked at
• Reliance on Jira-provided graphs and numbers (not exactly tailored to your needs)
• An unwillingness of people at all levels to gradually modify their processes
• a general agile-tool-fatigue

Oh, and on an –not really- unrelated note: You can copy and modify a lot of things in Jira - even if you don't have the rights to change the original.

till next time
  Michael Mahlberg

P.S.: Of course one could blame Atlassian – the company behind Jira – for introducing all those access control mechanisms and thus promoting a command and control culture in the first place.
But that really wouldn't be fair. After all, the core of Jira is a ticketing system. Designed to control people by means of centrally designed workflows.

The whole part that Atlassian sells as “Agile” nowadays used to be a plugin, called “greenhopper.” And if customers demand "Tools to enforce Processes to control the Interactions of Individuals" then why should Atlassian remove those restriction. Oh, wait there was Individuals and interactions over processes and tools, ... well... Of course there also is ...and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact

What is agile coaching really?

Over the last couple of years, agile coaching has become “a thing” and a term that is used in recruiting, staffing, by managers, trainers, HR, and by many others. And even by many agile coaches themselves.

‘Recently’ (starting about five years ago) a new challenge emerged. From the world of life coaching comes the statement that “You all call yourself coaches, but none of you has a coaching education.”

And there may be a lot of truth in that sentiment.

But if we want to educate agile coaches in coaching, which kind of coaches are we actually referring to?

From memory, the prototype of the agile coach was the sports coach, not the life coach. Why? Well, the first mention of a coach in an agile context I came across is older than Agile. The XP-Coach was mentioned in eXtreme Programming explained (1st ed. in 1999, and the reference to the xp-coach on the original wiki is even older.
Later, long after the agile manifesto was written in 2001, the term “agile coach” appeared with all kinds of connotations.
Looking back at descriptions from the turn of the millennium it seems as if the agile coach in these times was more like a sports coach than a life coach.

Life coaches mostly work within the a set of assumptions that fosters the personal growth and development of the coachee. For some this might be represented in a list like:

• The solution lies within the client
• Coach and client are at an equal level (peers)
• The coach is not the one to find the solution
• The client is the expert for them self
• The coach offers a container without judgement
• Coach and client work with an open outcome

Now if we look at the (rather technical) description of the roles of the XP-Coach that somehow doesn’t fit.

To quote and paraphrase from eXtreme Programming explained:

“... the job duties are as follows:

• Be available as a development [programming] partner [...]
• [make refactoring happen]
• Help programmers with individual technical skills, like testing, formatting, and refactoring
• Explain the process to upper-level managers.”

or - on a later page: - “Sometimes, however, you must be direct, direct to the point of rudeness. [...] the only cure is plain speaking.” And also “[...]I am always in the position of teaching the skills [...] But once the skills are there my job is mostly reminding the team of the way they said they wanted to act in various situations. The role of the coach diminishes as the team matures.”(p 146)

As I learned from Dan Brown (the Kanban Dan Brown, not the fiction author) who also happens to be a children’s rugby coach the education of some sports coaches looks at six different attitudes of coaching:

• tell (intervene and/or give directives e.g. to avoid injury)
• show (let players see the effect of actions)
• teach (educate the players on physical and nonphysical aspects [of the game])
• train (increase the effectiveness or efficiency of an acquired skill or aspect)
• sell (convince the players to 'buy into’ the application of techniques)
• develop (work on the personal development of the players)

When I look at these lists, the sports coach seems to be much closer to the role of the coach that was outlined by XP.

And what’s more: it seems to be in much closer alignment with both the expectations of most clients as well as the expectations of most teams. For one thing only very few clients want to hire an “agile coach” with a completely open outcome. Due to the nature of agile approaches the specifics are of course not clear at the onset, but the general direction is clearly towards something that is aligned with the agile manifesto and probably includes a number of agile techniques.

So – even though I usually call myself neither an agile nor a Kanban coach, end even though I have clocked up a decent three digit number of education hours in life coaching over the past two decades or so – I mostly find myself in roles more akin to a sports coach than in that of a life coach. And that is true whether I'm working with teams or with upper management.

So perhaps we should keep this in mind if we use the term “coach” in conjunction with agile or Kanban.
What are agile coaches offering these days? Something akin to sports coaching or something akin to life coaching?

And what are customers looking for? What do they need, given where they are right now?

till next time
  Michael Mahlberg