Mindset: "The bad news doesn't get better with age"

What does this saying actually get at? Well, many things, but let's focus mainly on one now.

I'll put it this way:

• our work of creating new products is hard (for many reasons)
• the customer cannot be that clear about what they want (eg, what the solution should be). The customer commonly does not understand the problem well.
• in many ways, we have to start working with incomplete knowledge. In multiple dimensions. But certainly not a complete, thorough and detailed understanding of what the end-product will be, and what it will achieve. We have a guess, but not a firm understanding.
• thus, we must assume there is a lot of bad news (yet to be discovered) amongst all the knowledge we have, and all the "progress" we have made with the product so far [Imagine right now that we are working on Release X, and it will be released in a few more sprints.]
• so, the question is: how to identify and clean up the bad news ASAP.

Why

Several reasons for this.

• Quality: We (the builders) and the customer want high quality. That the product is fit for purpose. No bugs. (No bugs is certainly what the customer wants, but realistically "with far fewer bugs than our competition has ever had.")
• the sooner we identify a problem, the cheaper it is to fix
• the sooner we identify a problem and fix it, the less it will hurt our timelines (we can deliver sooner, other things equal)
• when we try to get feedback on the bad news (in our brains and in the product), that feedback will be better if we can make the situation simple and clear to those giving feedback. Example: If we have a lot of bugs (in area X) it is hard to see the next bug in that area, whereas, if we have zero [known] bugs in area X, we can see transparently the next bug. Or so we hope.

Two more "whys."

• Every member of the Team wants to see progress. And they know that working hard is no measure of progress.
• Each member of the Team will be more productive if they have more assurance that everything we have so far is solid. As solid as we can make it. And at least good representatives of the customers tell us that what already exists is what the customers will want. Then the Team worries less, and more quickly make forward progress.

Methods

In Scrum, to help identify the bad news, we have an increment at the end of the Sprint for each story. That is, the story is "done" and that includes that all (related, known) bugs are fixed, re-tested, all tests running green.

This enables better feedback.

This includes the psychology. The reviewers (e.g., the business stakeholders (BSHs) at the Sprint Review) know that the Team thinks it's done. And that this story is now fresh in their heads. So, we (BSHs) must tell them now if it stays or if it goes. If that story stays just as it is and later gets released, or, maybe equally likely, if it gets fixed to be more fit for purpose.

Notice again: We want the information on the bad news ASAP. That is, if we get the new knowledge while we still remember well the "old" related knowledge, then it will be easier, cheaper, faster to fix that bad news.

We should be using more things, including tests of various sorts, to try to prove or re-prove or disprove that our theories (piles and piles of them) are (still) true.

Reminder: what's really of interest is the satisfaction the customer will get from our product over the [two decades] of its use. Predicting over two decades is difficult.

Reminder: the whole world is constantly in flux. "Everything changes, nothing remains the same." (Buddha) So, the #1 need today might be totally unimportant in 3 months.

Again, we must be testing the hypothesis that the highest needs still remain the highest, and that they remain likely to stay so. But also testing many other things. From that very high-level theory, to all the theories that led us to build the product just as it is now. More kinds of detailed hypotheses.

And we must do this quickly, simply, and without losing our courage to continue to move forward quickly.

Summary

This is a key principle. And to state it very simply, it has three parts.

• we assume there is more bad news we need to identify
• we want to identify the bad news as quickly as possible
• we want to correct immediately any bad news we have identified. While it is relatively sheap to fix

Rinse and repeat.

We have explained some basics about how this works with Scrum, with the Sprint concept, the DOD, the increment/working product, and the Sprint Review.

Do two things:

• Get that basic Scrum approach to work more effectively
• Find other methods to identify other bad news sooner.

Hope you found this discussion useful. Please comment below.

If we might help, check out www.LeanAgileTraining.com or send us an email at [email protected]