‘Yes’ is always wrong

Words don‘t mean the same thing to everyone. This holds even more so when doing intercultural projects. There have been extensive studies into that – yielding some surprising tools along the way.

Often I found that the simple word ‘Yes’ is a cornerstone of misunderstandings.

And for me that is true not only in intercultural contexts.

While a ‘yes’ to the question "Do you know Oliver Twist?" may mean “I‘ve heard of the novel” to some, it could mean “I've written my Ph.D. thesis on that subject” to others. And somebody else may know a person called Oliver Twist.

Because I've fallen prey to the ’yes-trap’ way too often I nowadays try to clarify my answers each time I catch myself answering ‘yes.’ And I try to avoid questions that can be answered by a simple ‘yes’. Asking “How do you know Oliver Twist?" makes both for a clearer answer as well as for a more interesting conversation.

till next time
  Michael Mahlberg

Remember: to backlog (verb) means ‘to pile up’…

And the noun means

“2. an accumulation of tasks unperformed []…“ – Merriam-Webster online dictionary

Translating the word to German makes it even worse: According to dict.cc amongst the German translations there are:

• Rückstand (lag, deficit, handicap)
• Nachhohbedarf (a need to catch up)

So clearly there are some negative connotation with regard to the term backlog. Still it has become a term with positive connotations in the software development community within less than two decades.

Yet –regardless of the positive connotations–, time and time again I see backlogs used in a way that seems counterproductive to me, Accumulating more and more “undone work” in the “backlog” - whether it is called backlog or feature-list or ticket-store or any other name.

In these cases, the items in that list really become a “Rückstand” as we would say in Germany - a lag with a need to catch up!

Of course there are several countermeasures to this – Backlog Grooming probably being the best known. But lean approaches also point to another idea on how to handle this: be very well aware of what your backlog really is and what you commit to!

Backlog vs. Ready-Column

Little’s law tells us that the average time an item spends in the system is determined by the work in progress divided by the time it takes to work on one item.

If we trust in this formula, basic mathematics tell us that if we put infinity in the numerator the result will also be infinite.

Thus, if we don’t put a limit on our backlog, we do not have a predictable time to completion.

Let‘s draw a picture of that:

Very often task-boards, scrum-boards, informal kanban-boards etc. are organized like this:

An unlimited input column (in Scrum for example it is the product-owner‘s job to keep the backlog prioritized the right way, resulting in an ample amount of preselected work for the next iteration), followed by some columns for the different stations in the process and finally an unlimited column for the finished work. While one might argue about the last one – which would make a good topic for a post on it‘s own – in general there is nothing wrong with this setup.

The problem arises when people forget that they can‘t make predictions about the whole board. Since the first column is endless (i.e. not limited) the average time any item spends in the system implicitly also goes towards infinity.

Now for the simple solution:

Only promise what you can control!

Without changing even one stroke on your board, just by communicating clearly that the predictability begins where the control begins, a significant change in expectation management might occur.

(Of course this was originally part of most agile approaches - it just happens that nowadays it seems to be forgotten from time to time…)

Shifting to an input queue

While we‘re at it: Why not change the wording to reflect the difference? While a _‘backlog’_ is a – potentially endless – list of things ‘not yet done‘ what we really want to talk about is a list of thing ‘to be done in a foreseeable, defined future‘. For me, one term that captures this concept nicely is the _‘input queue’_ – a term frequently in use in the lean community. And while I‘ve seen many (product-) backlogs without a limit, I have not yet come across an input-queue without a limit.

’till next time
  Michael Mahlberg

Yes you can (because I think so)

a.k.a. “works on my machine” or “works in my world”

The Situation

Developers declare function after function ‘ready’ and the customer still complains that “nothing ever gets ready” - unhappiness ensues.

Example

This little exchange really happened…

Consultant: “Has the issue #whatever been resolved?”

Tester (customer): “Oh yes, that was the one where we couldn't do #some_important_thing”

Developer (supplier): “That's been handled for ages - you can do #that_important_thing"

Product manager (customer): “No, I still can't do #that_important_thing”

Manager (supplier): “It is possible to do #that_important_thing"

Tester (customer): “I wanted to try it this morning and it is still not possible to do #that_important_thing“

Developer (supplier): “I am sure! I have implemented that. You definitely CAN DO #that_important_thing”(in an aggravated tone)

[one or two more circles like that, voices getting louder]

Consultant: “Ahem...”

Tester: “What?”

Developer: “What?”

Consultant: “Dear Tester: _In what way_ couldn't you do #that_important_thing?”

Tester: “I don't see any menu entry related to #that_important_thing in my main screen!”

Developer: “Oh - you're trying to do it with your own account! That won't work of course …"

Tester: “There is another account?!? What's the name? Where is it mentioned?”

Developer: “Oups … we might have to work this out a little more …”

And thus both the developer and the tester learned something new about the system and its interaction with the world.

The Problem

The parties clearly communicate on different levels of abstraction – while the developer was referring to the theoretical capabilities of the system the tester was taking about the things he actually was able to do with the system at that point in time.
Abstraction differences like this oftentimes can take days or weeks to become visible, especially if the parties involved communicate intermittently and use media like e-mail or a ticketing-system for their conversations.

A Solution

Go to the real enduser (or as close to the real enduser as possible) and watch her using the newly added system-capability.

Related lean/TPS concepts

Genchi Genbutsu / Gemba Walk

Related values from the Agile Manifesto

Customer collaboration over contract negotiation
Responding to change over following a plan

Related Scrum Values

Openness
Respect

Post-mortems are for dead projects - what to do with the living?

"He's dead, Jim" – the famous quote from "Bones" McCoy in the original Star Trek may be one of the shortest post-mortems one can think of, but it's not necessarily what you want in an Agile retrospective. What you might want instead is the attitude of Star Trek: the Next Generation's captain Picard - "Make it so".

From post-mortem to retrospective

But then again: the history of retrospectives is a history of misunderstandings...
One – plausible – version I have heard goes like this:
When the idea of project retrospectives came up in the context of early space missions, the idea was in fact to learn for the next iteration. But "the next iteration" would have been the next iteration of a rocket design, and the previous iteration would now have been reduced to a lump of metal shreds after it's successful test flight. Under these conditions it must have seemed quite fitting to borrow the term post-mortem – after all there wasn't much left moving at the "landing site". Developing safe ways of landing was not quite as high on the list of priorities as getting off the ground in the first place.
Gradually the scope of post-mortems expanded and soon the term was used to describe the process for all kinds of projects and was even adopted as a general term in commercial software development.
In 2001 Norman L. Kerth wrote a book titled Project Retrospectives: A Handbook for Team Reviews in which he made a strong case against the use of the, then accepted, term post-mortem. Before Esther Derby Diana Larsen's Book Agile Retrospectives came out, this was the definitive guide on retrospectives for me (now both books share that place) and I always tried to follow his emphasis of the fact that we don't do retrospectives for the past but for the future.

So let's use the term "Retrospective"?

At least there is a somewhat common understanding of the term.
When Tom and I laid out the structure for the Hands-on lean and Agile practices course we decided to go with the term "retrospective" – partially because that term is more widely recognized and people would have a clearer picture of what we talk about in that part, and partially because "retrospective" is the term commonly used in descriptions of the mechanics of such a review which makes it a good search candidate when looking for additional information.

How about "operations reviews"?

Nowadays I'm contemplating to suggest naming this section of the course "operations review" – a term used in the lean and Kanban literature. Although there are many very tight definitions of that term pointing out that an operations review is not at all comparable to a retrospective, these "clear" definitions are contradictory and some (a lot) actually suggest a certain similarity between operations review and (healthy) retrospectives.

Now what's it with this nitpicking with words?

Is it really important how we call this activity in our daily work? If we start with the intention in mind – looking forward, wanting to influence the future – won't the rest follow?
Well, modern brain science has it's own take on this.
As humans, our expectations and actions are influenced by the language used. In one very well known experiment people where told that they where tested on word-understanding while in reality their physical behavior was the subject of the experiment. One group had to work through a series of words with connotation of old age while the other group worked with words implying agility and youth. Sure enough the "old word" group was measurably slower on their way out from the testing facility. Even though this specific experiment on `priming´ has been disputed lately, the effects of priming also are one of the things the whole advertisement industry thrives upon. One last argument I would like to quote for this influence of words are the Implicit Association Tests from the harvard university. In these tests unconscious beliefs can be discovered by measuring the time it takes to identified words after the brain has been 'primed' with simple but powerful concepts like 'good' and 'bad'.
I don't know about you, but if I have the chance to 'prime' the whole team conducting the activity, I would rather like prime them with a concept that directs our attention to the future than setting them up for looking at a project that's still running with the mindset of a retro-spective, "looking back from a distance". Although much closer to "being in the present" than the mindset of a post-mortem, it still sets us apart from the things we want to influence. For my ears an "operations review" sounds much more like a thing I would undertake to influence what I'm doing right now.
I'm open for suggestions, but whenever possible I propose that we use words like "operations review" instead of "retrospective" or "post mortem" – at least until we find an even better way to put it.

The term conflict is vastly misunderstood

"We never have any conflict in our team"!

For me that is a really, really sad sentence. I really love to work with teams without quarreling and bickering – but I very much hope that there is conflict.

The meaning of conflict

What is `conflict´ after all? According to the english Wiktionary conflict is:

Noun conflict (plural conflicts)

1. A clash or disagreement, often violent, between two opposing groups or individuals.
   [...]
2. An incompatibility, as of two things that cannot be simultaneously fulfilled.
   [...]

And while almost everybody thinks about the first interpretation, the second one is equally valid and extremely valuable to recognize.

It's all about managing conflict - and that's a good thing

This is yet another thing that popped up when Tom and I prepared our hand on Agile and lean practices course - a lot of the techniques in lean and Agile are there just to handle conflicts in a reasonably civilized way:

• We prioritize work-items because they are competing for development time - there is a conflict for the time
• We queue deployments - there is a conflict for the deployment machine
• We use A3 reporting to point out conflicting interests.
• etc.

Recognizing conflict is an enabler

Without recognizing conflicting interests as such there is no way to resolve the conflict - take the original idea behind (non-automated) continuous integration: Software developers in the nineteen-nineties realized that they ended up with incongruent systems, when they all just committed their work to a central repository whenever they had a working result.
Apart from testing mechanisms and some other technical details, there was also a hidden conflict - the conflict for exclusive access to the system for modification. Recognizing this conflict enables people to find solutions. In the original example from Kent Beck, integration happened only on one machine, thus mediating the conflicting request for access to the system by queueing them. Denying this conflict on the other hand prevents solutions.
(Or this denial leads into misguided attempts on Jidoka like continuous integration servers which should really be called build servers and more often then not are just used as a fig-leave ... but that is another story – which will be up here shortly).

Conflict, there's just no way around it…

…but there are many ways to handle it wisely - by applying tools and techniques to resolve or manage it. As with change in the subtitle of the first eXtreme Programming (XP) book, fighting it only makes it worse. In XP they say "embrace change" - the same is true for conflict if handled responsibly "embrace conflict".

Note to self 13 - you can't assign responsibility, it has to be assumed

Michael, you might be able to say - or even order - that somebody is responsible for something but that doesn't really make them feel responsible for it. If he is assigned that responsibility without assuming  the responsibility he will most likely find ways to delegate this responsibility and to redefine the borders of the responsibility. 

An example for assumed responsibility would be this guy I know who develops his own software for a living - they lengths he goes to circumvent the glitches of the operating systems are impressive. For example even if the java installations on the client machine are completely effed his software will still try to figure out the best match for his needs and will 'just work' - Although he could just lay back and take a position of "Well, if the user can't correctly install java it's his problem" he doesn't. He feels not only responsible for implementing his software. He feels responsible for the users experience with his software. (And given the fact that he is able to make a living from a $30 software package his commitment seems to pay off)

It's unrealistic to expect this kind of behavior from people who are assigned responsibilities - especially if they don't believe in the goals or the underlying beliefs of the people who try to assign the responsibilities. 

Note to self 011 - Trust takes a lifetime to build - but can be lost at the blink of an eye

And - as Jerry Weinberg said - no one tells you when they have lost the trust in you!

Note to self 008 - It's not "You are " it is "I observe "

Dear Michael, [talking to myself as usual] I noticed that you complain about incompetent people. When I hear that I tend to put you in the category "egomaniac". What can we do about that?

Sounds much nicer than: "Michael, you are an egomaniac. I know that because you complain about incompetent people" doesn't it?

Even if you're convinced that the other Person (or team for that matter) is malicious, unhelpfull or in any other way "bad" remember that that's just the way you perceive it. Talk about yourself - that is something you can be sure about and that can't be argued away. [It is very hard to tell somebody "no, you do not feel that way" - although sometimes there are people who try.]

Note to self 007 - I still can't handle incompetent people

More a point I still have to work on than an actionable note to myself:

Don't get overconfident. It's not enough that somebody is incompetent - you've got to be able to convince people of this seemingly obvious fact. If you can't pinpoint it - just let it go for the moment. Especially if you can't put a number to the incompetence.

As a matter of fact this is something that I've never really gotten around to. 

[Explanation of the note for reader who are not myself] 

There is a certain kind of incompetent people (e.g. they just have no expertise in the very thing they are doing, they are literally incompetent in such a way that they lack the competences that they need to perform their job) that I still don't know how to handle - those that don't know the details of the job their doing but are yet well versed in easily graspable abstractions of the work they should be doing. 

The only way to handle these people - who sometimes have a real bad effect on the morale of whole teams - seems to be a very detailed breakdown of their shortcoming. But that on the other hand leaves me in the position of a nitpicker [erbsenzähler] who wastes everybodys time - including my own - by going through seemingly unimportant details.

Of course - applying the rule of three - that can't be the only solution - but although I've been trying for years I haven't  been able to find any other angles. At leas not up until now - still trying!

Notes to self 006 - Be aware of the focus of the reciepient

In an oversimplified view there are generalists (often sporting an NT of NF in MBTI speak) and there are "detailists" (often sporting an SP or SJ in MBTI speak).
You (I'm talking to myself here) are a NF generalist. If you want to convince an detailist you need to use arguments with lots of actionable detail - not the abstract mumbo jumbo you're used to.

(Wish I had thought about that two weeks ago)

Notes to self - 003, Write each email as if it will reach your worst enemy

=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----

Write each email as if it will reach your worst enemy because the chances are - it will!

Email might look like instant messaging or conventional mail - depending upon your background - but it isn't.

While it's not very common for IMs to get copied and pasted (although it happens) and conventional mails are only forwarded for a fee it is common practice to just press "forward" on an email. Considering that you might want to re-consider the idea to vent in an e-mail like "Hey Adam, I can't get Bob to do [whatever] - he's just to stupid and ignorant. Please do something about it".
Chances are that Adam just presses forward, adds "Bob, please do [whatever]!" and sends it directly to Bob.

If Bob wasn't your worst enemy before he probably won't be after - but I think the chances are high that your relationship with Bob won't exactly get better after this exchange.

As usual YMMV. I just had to remind myself about that yesterday. Again. (But at least I caught myself in time.)

=====8<---------- Start of note-to-self 003, Write each email as if it will reach your worst enemy ----