Sunday, March 24, 2019

Attention bias or Dunning-Kruger?

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

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

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

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

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

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

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

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

Cheers
  Michael Mahlberg

Sunday, March 03, 2019

What change initiatives can learn from steam engines

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


Structure > Culture > Strategy

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.

Sunday, February 17, 2019

Know thy commitment! (In Scrum or in Flow)

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

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

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

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

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

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

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

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

till next time
  Michael Mahlberg

Sunday, February 10, 2019

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

Sunday, January 20, 2019

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

Sunday, January 06, 2019

What's wrong with collective code ownership?

The Consultant’s answer of course would be “it depends.”

For now I just would like to focus on one important issues: In today's world ‘code’ is something quite different from what ‘code’ was in the nineties where we had things like a smalltalk image in which all the code of the project resides. Today we have things like infrastructure as code, configurations that are in some cases more complex that the software itself, pipeline-code, glue-code and many more things that affect the usability and usefulness of the system under discussion.

Therefore I propose to extend the concept. Let’s move on. Or –from my point of view– let’s get back to the original idea.

IMHO today what’s needed is an interpretation of collective ownership that engulfs the whole system. Collective ownership in this idea is not so much the idea that anyone is allowed fiddle with any item of the system.

To me today's idea of collective ownership means that anyone is expected to make all the changes that are necessary to keep the integrity of the system as a whole after some change or addition. This especially includes involving potentially affected parties and is much more about everyone’s responsibility for the whole system. And in today’s reality there are only very few people who can change all the kinds of code. Therefore, form my point of view, shared ownership also includes the responsibility to collaborate.

till next time
  Michael Mahlberg

Sunday, December 23, 2018

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

Sunday, December 09, 2018

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

Sunday, November 25, 2018

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.

Sunday, November 11, 2018

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

Sunday, October 28, 2018

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

Sunday, October 14, 2018

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

Sunday, September 30, 2018

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

Sunday, September 16, 2018

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.

Sunday, September 02, 2018

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