Agile Strategies to Explain Doing Less Work


Agile Strategies to Explain Doing Less Work


feet no shoes on desk

It might seem counterintuitive to convince people to do less work, but reducing work is actually one of the most effective ways to deliver the most value to your customers as quickly as possible. In fact, the authors of “The Agile Manifesto” suggested minimizing work in their Twelve Principles of Agile Software which states, “Simplicity--the art of maximizing the amount of work not done--is essential.”

However, it can also be difficult to convince someone that they shouldn’t take on work that they see as necessary to provide a specific value. I previously wrote about how to convince people to de-prioritize work, but there is some work that just shouldn’t be done at all.

To help navigate this discussion, I’ve created a quick overview of common scenarios where pursuing work can often be a bad idea and how you can explain to someone that the work they suggest should not be pursued. The conversation can become uncomfortable at times, but remember that your organization stands to better itself by following your agile-minded leadership. The following are just a few examples of commonly requested work that should almost always be avoided. 

Work That Adds the Wrong Value

Sometimes, adding value isn’t a good thing. For example, it might not be sustainable if it costs a lot to maintain over time. It may also force your team to deviate from your core roadmap that delivers more value to your customers. There are many other reasons why work can’t be justified simply by “it adds value,” but a lot of people naturally see value as a good thing by default.

For example, someone might suggest that Toyota should be selling Prius models that include a turbocharger. After all, Prius drivers might want to go faster considering the acceleration and speed limitations of their car.

However, the smart folks at Toyota probably realized that the parts, labor and maintenance costs would far outweigh any fuel efficiency gains or eco-friendly image – all of which are driving reasons behind why people buy a Prius. In this case, the added value of the turbocharger isn’t worth the cost and isn’t really anything the target customer asked for or wants.

In cases like this, ask the person requesting the work what the costs are related to the work, and collaborate with them to identify the ongoing costs needed to maintain that work. Also determine if the work is suitable to your target user base and if it makes sense in the context of your overall product roadmap. 

Work That Solves Problems That Don’t Exist for the User

When people request work that solves a problem that doesn’t exist for the user, they usually aren’t thinking of the problem as nonexistent. Unfortunately, this is more common than anyone would like to admit, since people often act based on their own personal situation or their past experiences rather than user research.

For example, a team member in an early-stage startup that manufactures bicycles might suggest that the bicycle should be able to allow the rider to go up stairs in offices and other buildings in an automated way in order to be compliant with disability laws.

While improving accessibility for all individuals is a noble endeavor and should be at least considered in any product, it might not be economically feasible for the startup to pursue disability law compliance during its early stages, and it likely isn’t even required of bicycle manufacturers.

In this case, there is no legal requirement in place and the typical user of the bicycle is understood to have some level of expectation around whether it can automatically climb stairs. This is a problem that may not exist for users of this product, since there are other products that can help disabled individuals ascend stairs in a more efficient and effective way.

In addition, it may be more economical for a third-party manufacturer to create custom enhancements or focus specifically on Adaptive Cycling users, rather than each bicycle manufacturer taking on the problem independently. Adaptive bicycles could also make up a future product line as the startup matures. 

In cases like this, ask your colleague for documentation that the problem exists, which in this scenario might be legal compliance requirements or regulations. Solving problems that do not exist can be very costly both in terms of the work done and the work that could have been done instead. 

Work That Creates Duplicate Efforts

Duplicate efforts can become a significant waste in workflow if not properly identified and avoided. This applies to all areas of creating, supporting and selling the product, not only the product development process.

For example, you may have a backend interface that allows your internal team members to generate reports, as well as a separate customer-facing reporting interface that allows customers to generate reports. In that case, you would have two completely separate reporting engines that have overlap in the data they’re trying to access and the reports they’re trying to generate. 

Instead, you may want to reduce duplicate efforts by moving all reporting to the customer-facing interface, but restricting access to internal-only reports for your team members exclusively. This way, you can enjoy the benefits of focusing all of your reporting-related time and effort on building and optimizing one reporting feature rather than two separate ones. 

In cases where people request duplicative work, they often don’t realize there is duplication involved and they may not see the whole picture of your product, internal tools or other aspects. To help them understand, explain where the duplication exists and how eliminating duplication will produce significant advantages. Be sure to rationalize your plan by explaining the cost involved and how the benefit will outweigh that cost, assuming it does. 

The Possibilities are Endless, but Your Resources Aren’t

In many cases, team members can stop at the initial stages of analysis where they see that a specific task will accomplish a specific outcome. However, there are several possible detractors that are often not identified, such as the cost to complete the task, alternative work that could be more valuable or potential problems with scaling such as ongoing cost and upkeep.

Your agile team is a limited resource with limited manpower and limited time (assuming that building a time machine is still far off on your product backlog). Before agreeing to send work to them, consider the areas mentioned above and any other reasons why simplifying the workload per agile best practices will help ensure the most value is delivered to the customers or users as quickly as possible.

These are just some of the common examples that may come up from time to time, so feel free to share any that you regularly encounter in the comments section below.



 

Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.

Learn More
comments powered by Disqus