Iterative and Incremental at 3 Levels – #1 “the what”

THIS IS A DRAFT.  (Comments welcome.)

I will try to express two big thoughts.

Hopefully these are formed well enough that as I talk about them clearly, you can use them in your situation.

* Background

So, the two ideas are basically these questions:

1. How do we coordinate at the 3 levels on “the what”.  Sometimes called “the requirements” or “the needs” or “the stories” or the features and the related details.  Short answer: Iteratively and incrementally.
2. How do we coordinate at the 3 levels on “the pressure”.  Sometimes called “the date”, or the iron triangle (Scope, Date, Budget plus Quality).   Again: my short answer today is Iternatively and Incrementally.

Ok. What do we mean by 3 levels?  Mainly, 3 sets of people each at or on a different level.

For “the what”, the 3 levels are (simplistically): The customers, the Team/PO, and Management

For “the pressure”, the 3 levels are (simplistically): The Scrum Team, the PO, and Management

* Assumptions / Context

In my world, I assume that several things are true.  (I think at least where I am, I am mostly right.)

1. No one knows everything.  Many people know pieces and parts.
2. The customers feel their problems, but the ability to articulate the problem or problems is limited.  The customers are not experts (usually) in diagnosing root causes. Nor experts at prescribing solutions.  Often they say: “I’ll know it when I see it.”
3. The Scrum Team has limited ability to read the customers’ minds.  The Scrum Team is usually not expert at customer journeys and similar “process” analysis. And in general that approach to quickly divining “the what”….hmm, well, it can help but is by far NOT a panacea.
4. Understanding “the what” requires everyone on the Team to actively engage and attempt to understand and to ask clarifying questions.
5. The customers’ worlds are constantly changing.  The customers’ views on trade-off and inter-relationships between our product and other products is constantly changing.
6. It would be really good to have a crystal ball about the future, but no one has one.  Although, some people do bat at .300 in guessing at the future, while others only bat at .200 or so.  It does help to guess better.
7. Everyone can understand and discuss “the what” better if you make it more visual.  More concrete and less abstract.  Not a panacea, but it helps a lot.  But we cannot express all features or requirements in a visual way (or in a visual way that is very useful).
8. We are always in search of the “last piece of the puzzle”.

That last item deserves elaboration.

In sum, because of the items above, we (think the Scrum Team mainly now) are constantly learning.

The problem with learning is: we never know exactly what to build.

One common consequence is: we wait for perfection.  For perfect knowledge.  This causes delay.  Delay itself is very bad.

Another consequence: Whatever we build, we are going to have to change it, sooner or later.

Well, except that typically some of it will not need to change (at least for a long time).  But we are bad at guessing/knowing which part will be “unchanging” and which will change “soon”.

So, some notable fraction of the whole will be built and then changed rather quickly, at least if we want to hit the “sweet spot” with the customer.  If we want to hit the bullseye.

* Keeping the 3 Levels in Sync

As described before, we are continually learning and always trying to learn faster.

And the customers maybe are learning or consciously trying to learn.  In any event, the customers are changing.  So, first, how do we stay in sync or “sync-up” with them?

The current phrase is: We release a lot of small releases of software quickly.

This releasing may have some problems, but for now we will ignore them.

But to be really in sync, releasing frequently, as such, is only half of it.  We also must get feedback and figure how to use that feedback well, make decisions, make real changes, and thus improve the product.

(One could add a Lean UX cycle prior to release, as a way to learn. For now, I will leave that out.)

So, the idea is that, we releasing and changing frequently, we are (the product is) back “in sync” with what the customer currently wants.

Ine might say: The Customers and the Scrum Team are in sync.

But what, what about Management?

Let’s remind ourselves why management is important.

First, in Scrum the PO is responsible (the main person responsible) for the overall ROI on the product over the life cycle.

Management provides “oversight” on this ROI success.  Ex: Some people give up revenue early to get big revenue later.  But this timing “problem” is something that management (or the situation) may not be happy with.  Hence: a discussion on strategy between the PO and Management.

Further, typically management (one or a few managers) also help put this team’s product in the context of the suite of products that the company currently offers.  And with the future products.

Problem: Management has limited time.  So, typically the Scrum Team needs to understand “the what” at a fair level of detail.  For managers, most of the time they need to summarize and discuss the features at a higher level.   Usually the PO ends up being the translator between low level and high level, and makes sure that they are in sync.  And that Management understand what features (or partial features) we have built, and which features we expect to build (and release) soon.

Let’s put the next point in the context of risk.  So, every user story and every feature has risk.  Right now we mean mainly the risk that it is “what is wanted” and “that it won’t change”.  This risk is important for the PO and management in deciding what to do next.  (Risk is not the only factor, but a key factor.)

I am not biased. In basketball, there is a time for the jumpers from “downtown” and another time for the easy layup.

So, part of the PO’s job is to advise management about risk (and other matters too), and then, with management, get in sync on the key features to build for the next release.

So, now: (1) The Customers and the Scrum Team are in sync. This includes the PO.  (2) The PO (and the Scrum Team) and Management are in sync.

And this must be done iteratively and incrementally.

One good discussion is the rhythm (eg, every 2 weeks or every month, or ?).

 

 

« « Managers: How to have break-out, outstanding Teams. #1 || Webinar: What should an Agile Manager do? » »