How to Break the Cycle of Unnecessary Work

Are you wasting time on unnecessary work? If your product or project is simple in terms of known requirements and known technology, then the answer might be “no.” If you, just as 99% of the product development teams, work in a complex setting where requirements and technology can change over time, then the answer might be “yes.”

This is not a groundbreaking discovery and actually doesn’t originate from the Agile Manifesto or the principles. It’s always been like this. In his 1970 paper, “Managing the development of large software systems,” Winston Royce described this phenomenon perfectly. In this paper, he presents five features that must be added to the basic approach of managing complex systems in order to eliminate development risks. 

He focuses on maximizing the amount of work not done by adding iterative and incremental behavior. Program design comes first, document the design, iterate, plan and monitor tests and finally involve the customer. This seems to have been lost in translation when other authors and process specialists adopted the methods. Winston Royce wanted to reduce the risk of developing the wrong solution by iterating, i.e. maximizing the amount of work not done. 

One of the key principles behind the Agile Manifesto and understanding Agile is the principle, “Simplicity—the art of maximizing the amount of work not done—is essential.” This principle is hard to read, understand, and perform in real life. Diving in, there are two elements:

• Simplicity is essential
• The art of maximizing the amount of work not done is essential

Simplicity is Essential

This goes without saying—do not overcomplicate things. None of us work based on an assumption that we need to overcomplicate, however, this is often seen in organizations adopting an Agile way of thinking and those yet to adopt Agile. A classic example is developing a piece of software that never is fully polished. You keep developing, developing, and developing until a point in which the feature might be redundant. Solution? Keep it simple. Build the smallest possible solution to prove that the feature is valuable and then incrementally add more work overtime.

The Art of Maximizing the Amount of Work Not Done is Essential

Reading the last paragraph, we’ve illustrated a case of reducing the work by building the smallest possible solution. But let’s broaden this. The more you think about a feature without developing and deploying it, the bigger risk you are undertaking. In other words, if you perform feature analysis for 5 months, the risk is that the outcome of the analysis is worthless due to market changes, making large parts of the analysis redundant. This is especially true if you are working with complex problems and customers where requirements and technology are unclear.

Traditional ways of working using an engineering approach, stage-gate models, plan-driven development, or waterfall methods, focus on the following:

• Scope the entire project and get the full scope approved
• Document and design the entire project with a stance in the approved scope and get it approved
• Develop the designed solution as approved and get the design approved
• Test the developed full solution and get approval of successful testing
• Deploy and implement the developed solution and monitor the usage to validate the initial business case

There are variations to this, but basically, this is how traditional product development is performed. None of the activities are wrong, but they all relate to full scope, entire project, and full solution. The big risk here is that you’re not focusing on simplicity nor trying to maximize the amount of work not done. 

Let’s say you have an approved scope and a documented design that doesn’t work when you start developing or doesn’t work in the user setting when testing. What do you do then? A project change request! Meaning—you go back to scratch. You then must add the newly observed changes to the design or requirements and start your approval loop again. This is maximizing the amount of work done and potentially wasting energy and time on things that will never be used by the customer.

By leaning into frameworks like Scrum, LeSS (less.works), Agile Playbook, and SAFe, you will see that work is done in smaller increments. This means adding smaller changes to the product, verifying that the change is valuable, and deploying it. What we want to achieve is basically this:

• Scope the feature
• Document and design the feature
• Develop feature
• Test feature
• Deploy and implement feature and validate business case
• Add, remove, or change future features based on customer input and market changes

The smaller the feature you can carve out, the less risk you are taking in terms of going in the wrong direction. Scrum theory says that each sprint should result in potentially shippable increments. SAFe theory says that each Program Increment should result in a set of features and enablers that can be built and delivered in one period. Depending on what framework and product environment you are working in, you should ideally be able to do all the mentioned steps in periods of 2-10 weeks. 

The shorter the cycle time, the more earnings you can take in and maximize the amount of work not done by developing the smallest possible solution to what the customer actually needs instead of a big solution to a problem you envision the customer having.

Rasmus Kaae is working world wide as an agile coach, mentor, presenter, facilitator and trainer. As a certified Scrum Master, Scrum Product Owner and Scrum Professional, Rasmus is dedicated to bring Scrum and agility into organisations by having a full stack end-to-end and top-to-bottom approach. He is a member of the national board of Round Table Denmark, and primary driver of an internal agile community in Danske Bank.

You can find more of his writing at https://agilerasmus.com/wordpress/