1. Requirements and Artifacts

Often reducing is batch size is all it takes to bring a process into control. Eli Goldratt.

There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucker

Agile, Flow, Lean, and Theory of Constraints all focus on the quick delivery of high value items. As obvious as it is, it’s worth pointing out that smaller items are easier to get quicker. And smaller can provide feedback faster as well. This has been partially manifested with the concept of small stories that add incrementally to the value being built. But what must also be considered is that the ultimate focus must be on value realized by the customer. We therefore need to consider two sides to requirements. First, what is the smallest releasable (realizable) value we have and how do we build it in small, end-to-end (in order to get feedback) slices.

The common artifacts of Agile – epics, features and stories – do not provide what is needed. Epics contain much more than what is releasable. Features and stories are usually not of value to the customer on their own.

Of course, some things we build are big. We must attend to how can we release something sooner and how can we build that in stages if we need to. We should first note that there are several different types of work. These include:

Creating a new product or service
Extending or enhancing an existing one
Maintaining existing systems

The time of creating and delivering value for the first two can vary considerably. In the first case we’re more in a discovery mode of what the product should look like and if is viable. This is often best done with minimum viable products (MVPs) and very short development – feedback cycles.

The second one is more of an investment in an existing product. In this case we’re more likely to know what’s needed and it’s like that more supporting documentation and marketing is required. Here we want to deliver value quickly as well. We call this the minimum business increment.

While both will be built with small end-to-end cycles the context in which they are in is different. It’s worth keeping them separate as each will require different actions.

The main distinction between an MVP and an MBI is that an MVP is an investment in discovering if a product has value while an MBI is an investment in creating value. In all but very small companies there are other differences. MVPs are often able to be built by a small team. MBIs often need the coordination of several teams to create it. Hence, MBIs also include information about who is needed to create it. This enables coordination of the teams required and enables multiple team alignment.

MBIs can create a focus for Agile teams by making it clear that these are the items that are to be released. Most teams amass stories and features to be released but it’s better to focus on the actual value intended to deliver. This also enables culling out parts of a feature that aren’t needed for an MBI. The deferred analysis enables the team to release the MBI faster.

The capabilities for this section are:

Work on small, releasable items
Attend to the customer journey while creating requirements
Build in small, vertical, slices
Agree on classes of service and their corresponding service level agreements
Have definitions of read (DoR) and definitions of done (DoD)

1.1 Objective: Work on small, releasable items

Let’s first consider the type of knowledge work being done, as that has a large impact on making these decisions. When:

doing new product development, MVPs should be used. This is also an indication to use flow as well.
enhancing an existing product, we should use minimum business increments (MBIs).
doing mostly maintenance work is done requirements are often minimal already and an equivalent to stories is good enough. This is an indicator for using flow unless there is a large backlog to choose from.

Why this is important

Working on small items enhance delivery of value quicker. Working on large items is correlated with waste will slow feedback and delay the delivery of value.

High value items can be used to align work to business value. If this is not present people will not coordinate what they are working on to get value out the door quickly.

Focusing on releasable items creates a bigger picture than just completing the story in front of a developer and facilitates cooperation.

How to implement with either timeboxing or flow

This is one of the key factors in deciding whether to use timeboxing or flow. If the product being built is not well-known continuous demonstration, validation and pivoting may be necessary. If we’re creating a new product with MVPs, then it is likely flow should be used. When speed of feedback needs to be high, recognize that planning an entire timebox will likely be a waste because we will change what we want to work on as we get feedback.

When using timeboxing work as closely with the customer as possible to get quick feedback. This will eliminate waste and improve product quality.

Organize the development intake around minimum viable products (MVPs) and minimum business increments (MBIs).

Make stories be small.

Note: There is a significant amount of ScrumBut and ScrumAnd here. While having iterations encourages small items (items must fit into the iteration), it is important to take steps to explicitly do this. Using the combination of MVPs and MBIs is almost universal to enable management of small items.

Anti-patterns

Larger than necessary items cause delays, poor feedback and too much work in process. When this happens, quality goes down and waste goes up.

1.2 Objective: Attend to the customer journey while creating requirements.

The customer journey is the path the customer takes using the system being created. When developing a product or service, what the customer journey will look like can be an important way to visualize what the product / service needs to be. A poor customer journey will not be appreciated by the customer. It is possible to go one step further, however. Imagine what the customer’s operational value stream could look like that would be an improvement over their current operational value stream. While this can’t be imposed on the customer, very often attending to the customer journey can lead to better operational value streams.

Why this is important

Attending to the customer journey and the operational value stream within which it exists is a kind of UX architecture. When done well, customers will enjoy using the product / service more.

How to implement this whether using timeboxing or flow

Quick feedback is necessary. So, if timeboxing is used, the team needs to set up frequent feedback sessions with the customers involved.

We should look to see how the way define the customer journey can positively impact the customer’s operational value stream.

This brings up the following questions on which to base our actions:

What would an improvement be for the customer’s operational value stream?
What customer journey would facilitate that?
How can our development value stream attend to this?

Anti-patterns

When the customer journey is not addressed, the requirements will often not be of high quality from the customers’ perspective. Using the system will likely appear to be awkward and will not encourage improved operational value streams.

1.3 Objective: Build in small, vertical (end-to-end), slices.

Regardless of how big the item you’re working on you want to build it in small slices of functionality. This is so we can get feedback quickly both about whether we’re building the function that is desired and that the quality is high.

Why this is important

Much of the work we do is fixing problems due to a delay between making an error and detecting it. By having small stories / slices, we start and finish quickly.

How to implement when using either timeboxing or flow

Sometimes writing small stories can be difficult. One way to write them is to think of a single scenario and function relating to it. Then write the story to implement that. In some complex situations you need to use Behavior Driven Development so you can use the construct Given-When-Then, but most of the time writing small stories is not that difficult.

Anti-patterns

When large batches of work are planned or being worked on feedback slows down, people tend to work no more things at one time causing both multi-tasking and delays. All of this causes even more work to be done – all of which represents wasted effort.

1.4 Objective: Agree on classes of service and their corresponding service level agreements

Different types of work require different agreements on how long it takes to build them. Each of these types of work is called a “class of service.” Each class of service should have a service level agreement – that is, how will this class of service be handled.

Why this is important

It’s possible, actually that it isn’t. In which case you can have one class of service for everything. But then at least you’ve agreed to that. In many cases, however, maintenance items are dealt with separately. Sometimes we need to understand what we’ll do when a severity one error comes in (e.g., the system is down).

How to implement when using either timeboxing or flow

Essentially all that’s needed is an agreement on what is expected for each class service. This just has us understand how product owners and development teams work together

Antipatterns

Without these agreements, expectations may not be set properly. This can cause both confusion, distrust and waste.

1.5 Objective: Have definitions of ready (DoR) and definitions of done (DoD)

Create clarity on what is of highest value requires including DoD.

DoRs and DoDs make explicit the agreements between people providing work to developers and developers saying the work is done. In the past a DoR was sometimes used as a stage gate so expect to hear some people say they are not a good idea. But in Amplio Development we only mean them to be an explicit statement of the agreement between parties as to what it means for a work item to be ready. The DoR could be something as simple as “it’s ready whenever the product owner thinks it’s ready.” Most often, however, there are some other things the teams will want to see prior to working on it. This could be it has a DoD, it’s been seen by marketing, a PO has seen it, whatever.

A DoR is needed when handoffs are done so each party understands their agreements with others.

A DoD is also an agreement between parties stating what it means for a work item to be considered to be completed. This may require certain actions to take place while it is being worked on besides just what function the item is supposed to have.

Why This is important

Handoffs often cause loss of information or people not being properly prepared to do the work being handed off to them. A DoR creates an agreement as to what it takes to get something started. A DoD states what it takes for something to get done. DoD’s should include both the functionality required as well as any involvement required by other groups (e.g., marketing). As Dean Leffingwell once said “don’t let something into the sprint without knowing how to get it out of the sprint.”

How to implement this whether using timeboxing or flow

There is not a set way to do DoRs or DoDs. What’s important is to have a conversation with everyone who gives or gets things from the team and decide on the agreements between all of the parties.