Tell Her No

Yesterday I was teaching a class where many of the attendees were from the same company. They had one major issue: Almost every sprint, either the Product Owner or a Stakeholder would add one or more stories in the middle of the Sprint.

I find this is a common problem.

And indeed, the new stories are often very important. Still, that is not necessarily an excuse for adding them (Can't they wait until the next Sprint? Don't they want to know what the real velocity of the team is?).

This is a complex problem.

But sometimes it is as simple as...Tell Her No. This is a song by The Zombies. A little fun might make it easier to say No. See here. (And remember the ever-friendly quote: "What is it about No you don't understand?")

While we must be compassionate (do I always say No when I should?), still we must say No more. In a nice way. My Yes means very little if I can't say No. I recommend this book by a friend of mine. Bill Ury also co-wrote Getting To Yes.



Again, No isn't always the right answer. This is a more complex problem.

5 Whys: To get better, say "why?"

If you have a 2 year old, or remember them, you are familiar with the word "why". Repeatedly. Now, a more adult way to use that word.

Lean tells us we should ask "Why" all the time. In fact, the 5 Whys. To discover the root cause of a problem. So we fix it once and for all.

Here's how Taiichi Ohno explains it:

It is difficult to do even though it sounds easy. For example, suppose a machine
stopped functioning:

1. Why did the machine stop?
There was an overload and the fuse blew.

2. Why was there an overload?
The bearing was not sufficiently lubricated.

3. Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently.

4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.

5. Why was the shaft worn out?
There was no strainer attached and metal scrap got in.

Repeating why five times, like this, can help uncover the root problem and correct it. ...get the real cause...which is often hidden behind more obvious symptoms.

Do you ask the Five Whys every time you have a bug in your software?

To hear further explanation from Taiichi Ohno, see chapter 2 of his short book:



There are many other great ideas in this book.

The concept of "Ba"

Ba can be thought of as a shared space for emerging relationships.

This is a quote from Nonaka's paper called (surprise): The concept of "Ba".

Why is this important?

Takeuchi and Nonaka work at a famous business school in Japan, and have been working on New Product Development, and trying to understand how and why some firms have such market success with new products. One of their lines of thinking, after much research in the real world, is that new products are developed by the creation of new knowledge. This is related to the conversion of someone's tacit knowledge (eg, the tacit knowledge that a customer has of his or her own needs) into the explicit knowledge of a small team. And this small team is then able to convert that created knowledge into the creation of a new product.

Takeuchi and Nonaka (and their associates) have then said that Ba is the place (context) in which (a) the tacit knowledge is converted, and (b) the place (context) that invests the team with the ability to make creative discoveries of new products.

So, software development is about creativity.

I urge you to read about and understand "Ba", and to try to create multiple Ba's for your teams. It is a simple concept, like love, but also a most intricate one as well (not unlike real love). (Or, if you have "love your enemies" completely figured out, please write and explain it to me.)

Here are some places to look:

The Concept of "Ba" by Ikujiro Nonaka and Noboru Konno (an article from the California Management Review).

A good review on the web. In the context of knowledge management (which Takeuchi and Nonaka say should be more focused on knowledge creation).

Building Ba to Enhance Knowledge Creation and Innovation at Large Firms by Nonaka, Toyama and Scharmer.

Your must (in my opinion) also read Takeuchi and Nonaka's HBR paper called The New New Product Development Game. It is directly from this paper that Scrum was created, and it is because of the mention of Scrum in this paper that Scrum got its name. I think you can see the concept of Ba start to germinate in their minds in this paper.

Lastly, I show the picture of a book I think you must read (again, in my opinion of course). It has an ungainly title. The book is group of articles, a couple of which are directly about the concept of "Ba". You must read it because you want to create "Ba" (places) to help your teams to greater success for your firm, and for your customers.