Limit What You Start to Go Faster: Priorities and Simplicity

Speed happens when you are lighter and more focused.

This is the second post in a series on limiting what you start to go faster.

The first post introduced us to how we can achieve optimal productivity and many other benefits, including happiness, by performing one task to completion before starting a new task.

In this post, we introduce our first Agile pattern to limit what we start—prioritization and simplicity.

---

The Anti-Pattern: It is All a Priority

“We have to do it all. I see no need to prioritize the work.”

We have all heard this statement. Many times this statement is made due to invalidated bias or bravado that the solution ideas are the right ideas. Sometimes a promise has been made to someone in authority to do all the work. Perhaps the highest-paid person in the room feels strongly about an idea. We can easily fall victim to these fallacies.

Even worse, traditional software development predictive techniques condition us to set the scope early and deliver it all according to plan. Minimal validation of value occurs along the way.

Naturally, without any priority and without short, frequent validation loops, it is easy for a team to fall prey to starting everything at once or in any order regardless of the relative potential impact of each.

---

The Agile Pattern of Prioritization and Simplicity

The best thing a leader can do is collaborate with his or her teams to prioritize what the teams should focus on first, second, third, etc. This will allow them to limit what they start and complete it effectively.

Context

There are some key Agile values and principles from the Agile Manifesto¹ that form the foundation of this pattern and avoid the anti-pattern of It is All a Priority.

Agile Value 3: Customer collaboration over contract negotiation

Agile Value 4: Responding to change over following a plan

Agile Principle 1: Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

Agile Principle 10: Simplicity—the art of maximizing the amount of work not done—is essential.

These values and principles allow us to avoid implementing every idea. They enable us to collaborate and experiment directly with our users. Ultimately, through this engagement, we will discover a minimized set of simplified ideas that deliver value.

The goal of this pattern is to reduce the noise and allow the team to focus on the work with the highest value. As outlined below, a solid prioritization framework grounded in business benefits and user needs coupled with a learning engine to maximize simplicity will allow us to reach this goal.

Using Vision, Benefits, and User Empathy to Add Focus and Priority

Value realization occurs by having a positive user outcome which leads to a positive business impact. The first step in limiting what we start is to think about the business impact we are targeting along with the target user needs.

Vision

Step one is to outline the vision of your product initiative. Having a vision is the first filter on the universe of ideas. Ensuring that ideas are in alignment with the vision will provide focus and will help eliminate irrelevant ideas. The vision should succinctly share the who, what, and why behind your effort:

• Who will use it and why they need it
• What you will provide that is not available today
• Why your business will benefit from fulfilling this need and why your business cares

Benefits

The second step is to define a prioritized list of business benefits realized by achieving the vision. Using a technique such as SMART (Specific, Measurable, Actionable, Relevant, and Timely) will define a well-constructed benefit. Each benefit should then be force-ranked in a prioritized list based on relative business impact.

A natural action is to start brainstorming user needs and solution ideas for addressing each benefit. However, this is where the power of prioritization kicks in. Since the benefits are all prioritized, only the top one or two should move into solution mode. This starts to filter out the noise and allows us to focus on solutions that have the highest potential impact.

User Empathy

For the top one or two benefits, define a set of user personas that you believe are crucial to achieving these benefits and your overall vision. User empathy maps, as illustrated in Figure A, provide a nice technique for outlining user persona.

You can utilize the user empathy map before engaging with your user to document your perception of user needs, but the empathy map provides more utility when used over time based on many direct interactions with your user. It is critical to engage frequently with those using your product to fully understand their needs and develop a deep understanding of their workflow.

Once you have developed empathy for your user types and their needs, you have a solid prioritization framework for generating and filtering ideas for realizing your top two benefits. If an idea is not relevant to addressing a user need, it should go into a backlog for later consideration. If it is relevant to solving a user’s need, the idea is then prioritized based on its estimated ability to solve the need.

Maximizing Simplicity Through Learning

Essentially, we are after the 20% of the ideas that will realize 80% of the value. There should be a big pile of ideas we do not build and a small pile of ideas we do build.

Using Agile For Early Learning

As illustrated in Figure B, traditional, serialized development techniques, such as Waterfall, result in late learning. In this method, we place a high degree of faith in the ability to predict up front everything that must be built, how it should be built, and when it will be delivered. The learning comes late in the development life-cycle after significant cost accumulates and the remaining time is scarce. When the learning arrives, it is often too late.

In contrast, Agile is an early learning strategy as illustrated in Figure B. The goal of Agile is to identify the riskiest or most uncertain elements early and run small experiments to find the right product to build, the right way to build it, and how long it will take to build it.

As such, learning in Agile is a key element of maximizing simplicity. We should only build what we need now and nothing more. Rather than delivering what we want, we have to engage with our users to learn what they need.

Finding the Good Ideas

We all have ideas, and most are bad. The Standish Group publishes its Chaos Report² once per year. Fairly consistently, it reports that between 65% and 75% of all software features delivered are rarely or never used. This is a staggering number. There is tremendous potential to limit what we start by finding a method to improve on this track record.

Finding the right thing to build amidst uncertainty is best achieved through learning. Figure C illustrates the essence of this concept.

Through small experiments in a rapid feedback loop, we have our best chance to find the right ideas to build.

Maximize Simplicity

How do we avoid overbuilding or building the wrong product? Small, rapid, low-investment experiments, tested with our users, are key to arriving at the right product that has a positive user outcome and the desired business impact. We have a hypothesis, but not a sure bet. Amid uncertainty, experimentation beats predictive scoping and planning every time.

When we need to learn something, we have to avoid overbuilding. This is the art of maximizing the amount of work not done. Not every idea will work, so we must avoid building too robustly until we have removed uncertainty.

Figure D shows how we can limit the robustness or fidelity of what we build based on our level of confidence in the value of the idea. This allows us to avoid overproduction by first inexpensively testing an idea based on our level of uncertainty. Uncertainty is gauged on whether the idea will address a user need, address our intended business benefit, and realize our vision. Certainty should not be assessed by intuition as bias can creep in. Rather, it should be driven by evidence.

In Agile, the most robust and expensive thing we can deliver to realize an idea is full-release, scalable, enterprise-level working software. Delivering this high level of fidelity when our confidence is low in the ability of the idea to solve a user’s need is likely wasteful and not smart.

If we are highly uncertain if an idea will work, the least expensive and fastest experiment is to interview and possibly observe the users to understand the workflow and needs. Our confidence will increase as we engage with a user and test out our ideas with a series of lower-fidelity experiments. However, if we have high confidence in an idea, there is also no need to perform low-fidelity experiments as this can waste time.

Figure D illustrates experiments at varying degrees of fidelity to increase our confidence before building the full-release, scalable, enterprise-level working software. If we can spend less money and time to find out an idea is wrong, we win. If we can run a small, low-fidelity experiment to simplify what we are building to only what is needed now and no more, we win. A rapid series of iterative build, measure, and learn loops with lower fidelity experiments in the midst of uncertainty are critical to helping us focus and not start things unnecessarily.

---

Conclusion

Prioritizing your target business impact, understanding desired user outcomes, and maximizing simplicity will limit what you start, provide your teams with focus, and eliminate wasteful development of features your users do not need.

Check back for more posts on Agile patterns for starting less and finishing more.

---

 Other Posts in the Series

• Limiting What You Start to Go Faster – An Introduction
• Limit What You Start to Go Faster: Swarming and Interrupt Handling

References

1. The Manifesto For Agile Software Development, www.agilemanifesto.org, 2001, Ward Cunningham et al.
2. The Standish Group Chaos Report, Standish Group