How to capture knowledge

Very simple: Don't!

In my Opinion you shouldn't capture knowledge – you should set it free!

Why are so many people keen on capturing knowledge? I spend most of my time trying to set knowledge free. That’s what my clients pay me to do.

To take an example (once again) from software development: what's the use in writing a local guide to unit testing, when there are literally thousands of well-crafted pages on that topic out there?

This is somewhat related to the question of whether you try to control circumstances or build capabilities – having a few specialists make the organization as a whole more fragile. And documentation doesn't create value when it is written – documentation creates value when it is read and understood.

There is this dialogue I witness every now an then which illustrates one of the bigger problems with the idea that information has to be captured - it goes something like this:

"Spreading knowledge" 1985

• A: Why didn't you use the new approach?
• B: There is a new approach? I didn't know!
• A: But there's an article on it in the newest loose leaf update to the SOP (standard operating procedures)!
• B: *rolls eyes*

"Spreading knowledge" 2016

• A: Why didn't you use the new approach?
• B: There is a new approach? I didn't know!
• A: But I wrote an article about it on the wiki!
• B: *rolls eyes*

Back in the days putting three ring binders with standard operation procedures in all offices and sending out monthly updates didn't do the trick of disseminating information.

And while I really love what Ward did for the empowerment of the people trying to collaborate on making information accessible, having a wiki alone doesn't help in the distribution of information either.

Does documenting really help? Especially documenting the result of a lengthy thought process? Do we understand the nature of relativity, just because we “know” that E = mc² ?

Sometimes I see people pondering over the creation of some documentation for hours. If it takes hours for people to create the documentation, then how much time should one allocate for people who read this documentation to understand it’s authors intents? About the same time it took to write it down? Half the time? A quarter of it?
Or maybe it takes twice the time of writing the documentation, because really understanding it requires at least a modicum of application.

So here’s my suggestion:

Each time something important is published in your project (e.g. on the Wiki) consider the time it would take people to understand it and – gasp – hold a session of that time and explain it to them. Keep the article. Keep it as a reference and make sure it is accurate, but don't expect people to know something just because it has been written.

In my mind I hear you argue: “But we can't afford that much time!” – Well, if you can't afford that much time, then how can you expect people to have taken it?

till next time
  Michael Mahlberg

If you want motivated people in your organization, they have to be able to screw up the business

... at least temporarily.

There has been a lot written about the possible ways to get people to buy into the overarching goals, visions and target of their organization. More and more I get the impression that one important part is missing.

Of course it is important that everyone “knows the whole picture” and that ”vision is made clear to everyone” and so on.

The important thing that’s missing –at least in my opinion– is this litte thing called “making a difference.” People in an organization have to have the feeling that their actions actually do make a difference. When the effective difference of ones work being done well or not at all is effectively zilch –e.g. because after completing the work it still takes half a year before it has any effect on the outside world due to company procedure– the person delivering the work probably doesn’t experience much effectiveness.
In the long term this can lead to low self-efficacy which in turn increases the probability of disconnecting from daily life. In more pronounced cases this even can be a way to burnout and depression or inner resignation.

One of the biggest differences between environments where motivation is high and those where it isn't, in my experience, is how much effect peoples’ actions have on the outside world.

The Manifesto for Agile Software Development very clearly states

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

While the Essential Kanban Condensed says

Encourage acts of leadership at every level

and

Manage the work; let people self-organize around it.

To get this in one of those “agile transformations” I suggest that it is a key element to make sure that each individual contributors contribution actually does contribute. In a tangible way. After all: if my actions don’t have any real effect, why should I perform them at all?

On a related note: I think “agile transformations” is a misnomer. What you actually want to do is to make your business more flexible and move it away from the Tayloristic approach which doesn't fit the reality of today’s knowledge work and towards modern models like networked organizations, the leader-leader model or similar concepts.

till next time
  Michael Mahlberg

A very simple risk-mitigation approach to tackle the truck-factor

If you have heard of the Truck-Factor you might assume that it is a good idea to have everyone on the team capable to do everything equally well. There are just a couple of issues with this idea. For one thing, you can't have the world’s best goal keeper in such a team. And –especially when the goal is to build something that hasn’t been built before– training and educating all people in all areas of expertise equally well takes a lot of time.
Furthermore, since it’s desirable to run a lot of safe to fail experiments some of the options we explore will be discarded and thus spreading the (in depth) knowledge about them through the whole team could be considered waste.

I personally like the approach of the three ”bricks” as a rule of thumb for the distribution of knowledge about “special” areas of expertise:

    /------\          \
    |      |           | 
    |  1   |           |
    |      |           |
    \______/            \  Capacity between
/------\/------\        /  0,5 and 2 "expert equivalents"
|      ||      |       |
| 0,5  ||  0,5 |       |
|      ||      |       |
\------/\------/      /

\______  ______/
       \/
 Risk-mitigation
    3 people

Where the numbers in the ‘bricks’ indicate a subjective competence that has to be negotiated on a per case basis.

This is by no means all you need to do a full capacity planning or full fledged risk management, but the “three bricks approach” is a very handy way think about managing expertise on new technologies, tools or techniques.

till next time
  Michael Mahlberg

P.S.: If you want to do in depth capacity planning you might want to look at Troy Magennis’ Excel sheet for portfolio planning for that and when it comes to risk management the classic Waltzing With Bears provides a great introduction.

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 much ‘empowerment’ is there in Agile?

Does Agile imply that people only do what they like to do?
Does Agile imply that there is no more direction?
Does Agile imply that the team decides what they want to do by consensus?

Well... today Agile means a lot of things to many people.

So yes, perhaps it means some or even all of these things to some people nowadays.

But that’s not what the agile approach was about. Around the turn of the millennium, when the term Agile was coined it was a collection of values and practices some people followed to successfully deliver software where the majority of projects was over-promising and under-delivering.

Previously, I tried to debunk the myth that pull means work on whatever you like, so for today let's have a look at self-organization once more. Doesn’t “The best architectures, requirements, and designs emerge from self-organizing teams” (the 11th principle of the agile manifesto state that teams should decide what they do, and how they do it, based on consensus? Not really. There is a lot to be said about different approaches for reaching a decision and consensus is but one of them.
The important thing at the time when the agile manifesto was written was that the decisions where no longer made by managers, procurement departments, or architects three degrees distant from the team, but instead by people within the team. But even that doesn't mean that the team sets its own direction. It used to be quite the other way around. Like when you go on a city tour. The team (tour) members choose wether they want to get on the “romantic old town tour”, the “modern city sites tour”, or the “historic monuments tour” – but once they’re on the bus the self-organization might be about who brews the coffee, who hands the cookies and perhaps even who hands out blankets when it starts getting cold on the upper deck. But not whether you should rebuild the bus to become a biplane or whether it wouldn’t be a better idea to tour the romantic old town if you’re on the “historic monuments tour.”

From my point of view, there is a lot of empowerment in agile. But perhaps not quite as much as some people would like it to be. After all, we’re still making our living because customers buy our product or service – and customers only buy what they need (or think they need).

Or, to put it another way: without direction self-organization leads nowhere.

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

Yesterday’s weather – it’s only an approximation!

Very recently (yesterday to be precise) I published one of my shortest blogposts ever.

What happened? I used an estimation technique from the days of eXtreme Programming called “yesterdays weather.”

The basic idea is that it is rather probable – though not certain – that the future will resemble the past. I started writing regularly for this blog in 2013 and published a post every two weeks except for a time last year when I explicitly decided to let it rest for a while.
So it was a sound expectation that I would continue to publish every two weeks. On Sunday afternoons (European time).
Or so I thought. To add insult to injury I did not only violate agile principles (adjust the plan when the circumstances change), I also violated lean principles.
How so? Well, Of course I don't write all my pieces on Sunday afternoons, but instead on the days in between Sundays and set the the publishing date to Sunday afternoon. And fiddling with the publishing date in blogger (my blogging platform of choice - for now) is quite tedious. So I decided to increase the batch-size and create some inventory of already scheduled blogposts that I would ’only‘ have fill with the contents from my local drive.

Except that it didn't work out like that. I did not create the content in time, and all of the sudden the inventory became a liability. Since I didn't respond to the changed situation and the plan got carried out by bloggers scheduler, this actually went out to the market. Luckily it was only a “lorem ipsum” type of blogpost and not a vital product feature marked “to be defined before production” that went live...

Well, this blogpost from yesterday definitely reminded me, that the lean avoidance of overproduction (one of the seven wastes in Muda#Over-production)) really is a virtue... and that even though past experience is a strong indicator for tomorrows events, we still need to check the current circumstances on a regular basis.

till next time
  Michael Mahlberg

P.S.: To quote George Bernhard Shaw:
“The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me. The rest go on with their old measurements and expect me to fit them.”

Unfinished Blogpost for June 17th

not yet written...

How technical is lean and agile?

A huge amount of discussions around lean and agile today is about management methods, personal interaction, coaching approaches, team interactions and so on.

And while I completely agree with the notion that “soft skills are the really hard skills” and are absolutely necessary, I still think that some technical excellence is crucial (remember the second page of the agile manifesto, principle 9?).

Many of the things that are present in successful agile teams and that people nowadays try to ‘inject’ into not-yet-quite-as-agile teams could be either cause or effect.

Let’s take the value of trust for example – perhaps people in highly skilled teams trust each other more because each of the team members brings some technical excellence to the table. Or perhaps people show their degree of excellence (including it's boundaries) because of the high level of trust. It could be either way around. Neither of that might be the case if the team is not self selected but made up out of “those who currently don’t have any other project”. Or let's look at sustainable pace – perhaps people in highly skilled teams are able to work with a sustainable pace because the know there limits and know that if the work beyond those limits the quality of their work suffers. And so on.

But back to the question of the technical aspect. Nowadays I often see teams where refactoring is looked upon as a separate activity (In XP-Times it was Red-Green-Refactor every couple of minutes), where people are neither free to choose their own IDE (e.g. because of company standards) nor willing (e.g. because they don't know any other IDEs) and where the command line is considered dangerous.

That’s not how the game was played when the term agile was coined - If you want to be able to quickly react to changes you need technical expertise. And technical excellence. Invest in it. Without technical excellence all the agile management practices might bring some improvement, but in the end those improved situation will be brittle unless serious attention is paid to technical excellence.

Just my two cents for today...

till next time
  Michael Mahlberg

Kanban metrics made easy - the other kind of pirate metrics.

You may have heard of pirate-metrics in the realm of startups and customer behavior because Acquisition, Activation, Retention, Revenue and Referral gives us the acronym AARRR! which to some sounds somewhat piratey.

But that is not the kind of pirate metrics we’re talking about here. This is about a simple, quick and easy way to gather flow-data by just ‘carving a mark in the tally for every prize won [or in this case: For every day spent].’

The basic idea – as presented for example by Benjamin Mitchell in his Talk at the LKCE 2012, see slide 31 – is to just mark cards with a “tag” for each day that it spends in a certain column. For extremely narrow cadences this timeframe might be even smaller (e.g. half days). Basically it just means you

1. assign “signs” to the columns (e.g. R = Ready, A = Acceptance test definition, S = Story Preparation, I = Implementation, P = Post processing) (remember to put the 'signs' on the board as well so that everybody can look up the meaning of the tags immediately) and

2. at defined intervals have somebody go over the board and 'tag' all cards according to their current column.

3. Use the information gathered by this in Kaizen events, retrospectives and the standup meeting.

Sample pirate tags

Sample of pirate tags created in half-day intervals on a (hypothetical and hopefully unrealistic) story card, that spent half a day in ready, one day (two half days) in the definition of acceptance criteria, half a day in story preparation, half a day in implementation and two-and-a-half days in post-processing.

Just a thought: Perhaps you don't need fancy software after all,to start getting quantitative feedback on your work...

till next time
  Michael Mahlberg

Out of the busy-trap: Don’t call your options backlog

When Scrum was young, one of the objectives was to make sure that the development team was able to work on a fixed set of things for 30 days in a row. (At least that what Ken Schwaber and Mike Beedle wrote in one of the original Scrum Books.) And yes, back then it was 30 days.

A little history

Having 30 days without changing requirements seemed like a very long time for the context in which Scrum –todays most widespread approach to agile– was born. Therefore, a couple of elements were introduced to sustain especially that aspect. The sprint and the notion of the backlog as an artifact are two things that play vital roles in making sure that the objectives for the 30 days really stay fixed.

The sprint has a few attributes that make negotiation between business and development much easier - like a duration, a goal and the whole notion of the fixed subset from the product backlog.

The backlog - especially the product backlog, which used to be quite different from the sprint backlog - contains an ordered list of things that the business (which actually is paying for the music) would like to have. But unless it is in the sprint it is not fixed or committed.

Enter: semantic diffusion

Nowadays many people seem to interpret the backlog as a list of all the things that must be done. And I think must should almost always be questioned. Even the word backlog gives the wrong impression about the requirements – if everything turns out right, the 'backlog-items' are not a burden for the dev team but instead they are options to generate value for the whole organization.

The value stream starts way before the sprint-planning(s)

If we look at the whole value chain from idea-conception to delivery, invoicing and payment, it becomes difficult to extend the concept of a sprint to the ever enlarging group of people. Which is fine, because the sprint was never meant for big groups.
Looking at larger groups of people creating value together, it becomes much more feasible to synchronize those groups via independent cadences and optimize the flow through the whole chain. And once we start looking at the artifact formerly known as ‘backlog’ it sometimes shows that, up to a certain point in time, those backlog-items are merely options – so let's treat them like that (as I wrote a couple of weeks ago.

Naming is essential

And since words have effects, why don't we start calling these things by their names? “We have to decide which options we select” set a different tone from “let’s look at how much of our backlog we can master.”

Make your life easier – treat options as options and only committed items as ‘backlog.’ And perhaps after a while you might be able to drop the term backlog altogether.

till next time
  Michael Mahlberg

P.S.: I find it very helpful to keep in mind that even though the Scrum terminology is almost ubiquitous today, there are only very few teams or projects really implementing Scrum. Product teams who have to deal with support issues, project teams who don't have control over the Product, product owners who only have 2 hours per sprint for their team, scrum masters who serve 5 teams at a time – the list goes on and on.
Given these constraints it pays off to review what we want to achieve if we use lean and agile practices and employ those which actually fit the situation.

The official way to define a sprint goal...

... doesn’t exist of course.

But please:

“We'll do stories 5712, 3211, 7621 and 3123” has never been a sensible commitment. That’s not why we have sprint goals.

The Scrum Guide states “The Sprint Goal gives the Development Team some flexibility [...]” and “The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.”

So, if you ask me

“At the end of this iteration department Y will be able to sell product X via channel C” sounds much more like a useful sprint goal. And much more in alignment with the original ideas of Scrum.

IMHO, one of the most important things about the sprint goal is that little word ‘coherence’ - a clear sprint goal helps in setting priorities, aligning team efforts, and communicating with stakeholders.

Therefore, I suggest to use more than a collection of stories to define the sprint goal.

till next time
  Michael Mahlberg

P.S.: Using numbers to drive a business is considered harmful by many people – to quote W. Edwards Deming Quotes

People with targets and jobs dependent upon meeting them will probably meet the targets - even if they have to destroy the enterprise to do it.

Perhaps sprint goals made up of (story) numbers are also a bad idea.

Do I really have to? On Options and Commitments

Aside from the whole sprint-commitment thing, there is another commitment-issue I tend to have.

People often misunderstand options for commitments

And it can be very liberating to get rid of that confusion.

“I can’t go to that lecture, I already have a ticket for the cinema.” Is the cinema ticket an option or a commitment?

“I can’t go to that conference I’ve already booked flights for those dates.” Are those plane tickets options or commitments?

In their excellent book “Commitment“ Chris Matts and Olav Maassen look into this question in depth, but for now let’s just look at one very important take away from pondering the above questions.

#1: If something is an option or an obligation (a commitment) depends on whether you're buying or selling. The tickets in both cases are options for the person who bought them but commitments for the sellers. The cinema is obliged to show the movie, but I as a buyer have merely bought an option. I can exercise it or i can choose to let it expire. I am not obliged to go to the cinema, I have only bought an option to go there.

#2: Options have a value (and a price) (Almost straight from the book) Different options have different prices. Depending on my perceived value of the option I might be willing to pay the price or not. The option to fly somewhere might be more expensive that option for the movie, but still the question is what I am willing to pay. I am not obliged to take the plane. Thinking about it in that manner means that I did not pay for the flight (if I did I probably would pay when I enter or leave the plane, like with a bus ticket) I paid for the option to take that plane.

To me this way of thinking is quite liberating. Just make sure you know on which side of an option you are. People tend to loose a lot of faith if they were sold options and the other side doesn’t keep their commitment.

till next time
  Michael Mahlberg

P.S.: You can find a draft version of my take on real options on this blog including pointers to the whole background in Chris Matts’ and Olav Maassens’ excellent book and some online resources.

What is a commitment anyway?

Or: The difference between “having committed to something” and “being committed to something.”

This is not about the old story of the chicken and the pig who want to open a restaurant. Even though Ken Schwaber used this adage to illustrate the difference between commitment and involvement in the early days of Scrum, it is no longer part of the canon.

The version history of the scrum guide makes that quite explicit:

“Development Teams do not commit to completing the work planned during a Sprint Planning Meeting. The Development Team creates a forecast of work it believes will be done, but that forecast will change as more becomes known throughout the Sprint.”

Still I see the term “commitment of the team” quite often. In publications and in ‘real life.’

I have to confess, I am even guilty of using it myself from time to time.

Like with many things in the world, the question is how we use them. In this case it is the question of how we use the term – and the concept – commitment?

There is a fine line, but a very important distinction in who does the committing. A while back I heard some General in a movie say that he “committed 20 troops” to some task. In yet another movie a team member explained the success of his team with the fact that “the whole team was committed to the cause.” So does that mean that the 20 people the General committed to the task will feel commitment to the task and thus succeed? Probably not.

And yet the statement “The team is committed to the sprint goal” is syntactically the same wether the team has committed to the sprint goal (e.g. each team member bought into it) or has been committed to the sprint goal (e.g. some higher authority spoke on behalf of the team without their consent).

till next time
  Michael Mahlberg

P.S.: But then again you might want to consider exchanging iteration based approaches with a flow-based concept and cadences and then you might consider “Department Y will be able to sell product X via channel C” as an idea for a MMF (Minimum Marketable Feature(set))

This is not an Epic

This is a rant...

In a “recent” post Mike Cohn outlines some of the misunderstandings around the the terms «epic», «user story» and «theme».

This article is actually only “kind of” brand new - it is from 2011.

But thanks to the prevalence of Tools and Process over Individuals and Interactions that has been brought to us by tools like Jira for more than ten years now, it seems to me that it is a good idea to look at a few key points again.

For example Mike says:

There's no magic threshold at which we call a particular story an epic. It just means "big user story."

So, sorry folks: an epic does not group a bunch of requirements that do not deliver value on their own together. According to Mike’s old post an epic simply is a story that “[one] didn't get the chance to break […] down into stories that are […] small enough […].”

That’s why it is such a good idea (at least IMHO) to do whatever you like with that “Epic” thingy in Jira – use it to mark other stories, use it as a theme (see Mike’s post for a short explanation of that) use it to signal states if you don’t have a Jira admin in your team etc.

But whatever you choose to do, don’t do functional decomposition by making your epic an enumeration of sub-functions that only deliver value if they are all implemented together.

...end of rant.

till next time
  Michael Mahlberg

What happens left of the Scrum-board?

In the early days of Agile, Agile was very much about customer collaboration and concepts like the on-site customer were at the core of Agile. Nowadays, most on-site customers (actually a term from eXtreme Programming) are some derivative of Scrum’s Product Owners and most instances I have seen are far from the role Ken Schwaber and Mike Beedle described in their seminal work on Scrum in 2002.

Things have changed over the years, and nowadays a product owner (PO) in many places, especially at enterprise scale, is someone who devotes ‘a couple of hours’ each week to support ‘some team’. And even though this is definitely an anti-pattern from my point of view, it still is a reality we have to deal with.

The Agile Manifesto states quite clearly that “Business people and developers must work together daily throughout the project.” (4th principle) and one the biggest benefits of agile approaches in my experience is that they enable projects to start developing (and delivering!) before “all” the requirements are discovered. A huge part of this approach has to do with the fact that the whole team works on requirement discovery and the honing of the product vision.

But those teams are rare.

And while process-frameworks like Scrum – and the secondary literature around it – provide a lot of helpful guidance on how to deliver the solution there is very little said about the process of requirements discovery.

So I would like to challenge you to a little experiment.

• Have a board “left of the board”
  • Instead of just having a backlog and backlog refinement meetings where requirements magically appear try to build a board for this part of your process as well!
    
  • Have just a few columns like “idea”, “described”, “accepted”, and “ready for planning” – whatever fits the real way of work at your place.
    
  • And here is another idea: Unlike on the Scrum board, perhaps here it is not necessary for all items to reach the stage - perhaps it is good if some ‘die’ on their way to the iteration planning.
  • And then observe... What happens on this board?
    • Do items ‘starve’ in some states?
    • Are there items with different speeds?
    • how many items ’make it’ to the next stage?

Who knows - you might learn a thing or two...

till next time
  Michael Mahlberg

P.S.: Inspired by Discovery Kanban of course... ;-)

Why I hate "Inspect and Adapt"

Because more often than not, people don’t.

They way I grew up with agile, one of the basic tenets of all agile approaches was the notion that there is no prescribed ‘right’ process, but you have to do what it right at this point in time. There even was a lengthy discussion whether the approach should be called ‘agile’ or ‘adaptive’ when the agile manifesto was created.

Now I see people ‘doing agile’ all around in manners I sometimes fail to understand. And I hear complaints that the agile stuff doesn’t really work. And more often than not, the explanation I get is along the lines of “But agile says ‘inspect and adapt’ and we adapted.”

IMHO one of the best answers to that was written by Ron Jeffries and is called We tried baseball and it Didn’t work.

And what I see quite often when I hear that teams ‘adapted’ the approach they try to use, is exactly that – they adapt without doing the inspection of the real thing first. Go ahead - read it! :)

So if you want to use the inspect and adapt approach, please make sure that you have something to inspect before you adapt it.

till next time
  Michael Mahlberg

How to single-handedly run a change initiative

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

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

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

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

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

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

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

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

till next time
  Michael Mahlberg

Getting to higher performing teams – controlling circumstances or training people?

Do you make jobs easier to do, or do you help people to become more capable?

Effectiveness and efficiency often come in conflict when a goal has to be reached and deciders start to feel pressure. But as Peter Drucker famously said:

“It is fundamentally the confusion between effectiveness and efficiency that stands between doing the right things and doing things right. There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

But even if we are able to look at obstacles through this lens, and focus on the effective things, there is still the question of how to best do the really necessary things.
In today’s fast paced VUCA-World (Volatile, Uncertain, Complex, Ambiguous) most of the things we try to accomplish imply some kind of “gaining knowledge”. And that is where we can see a huge difference between players who are in the game for the long run, and those who are more focused on quick gains.

Let’s assume we have a new complex piece of equipment - be it software, hardware or something else. Learning to work with this new asset requires learning and education. And this is where we come back to the original question - “Do you make jobs easier to do, or do you help people to become more capable?”

The more efficient approach – and probably even the more effective approach – would be to train a few people to operate the equipment, and let them create procedures for the rest of the staff on how to use it. (Think e.g. “creating build scripts for others” in a software engineering context)

But here comes the kicker: as Jerry Weinberg once said “The more adapted we are, the less adaptable we are.” Being less adaptable means being less capable of responding to change.

So having these highly optimized processes makes the jobs of the other people easier (sometimes much easier) – but it takes away from the capability of the organization as a whole. A different approach would be to teach all the people affected how to operate the new equipment, and just have the specialist handle the initial (and perhaps subsequently necessary) research and education. The latter approach would result in a much more capable organization. Of course, after the organization has learned how to best use the new equipment it can still be – and often is – a smart decision to have specialists who know the equipment even better than the rest.

‘till next time
  Michael Mahlberg

P.S.: To give credit where credit is due: David Anderson mentioned the concept of “controlling circumstances vs training people” while we were working on the KMM (Kanban Maturity Model) – I just picked it up and tried to translate it to my own working environment