Agile Failures: Just in Case
A huge form of waste (leading to Agile failures) many people don’t talk about are those features we build “just in case” we might need them some day.
I think that those involved with building a product often forget that everything we build costs something. Nothing is free. Who’s paying for it? The customer.
Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.
There are certain phrases that I listen for such as, “it would be cool if…”, “someday we might want to…”, “what if a client requests …” etc. Some Product Owners want to build to accommodate edge cases that are often so ridiculous that they would never happen.
What gets really tricky is when there is only one SME in the product group, and no one else really knows that domain. In those cases, that SME acts as the Product Owner and has the power to create work that may actually be of little value and may lead to the snowplow trap.
The only way to get around this is to fearlessly and relentlessly ask “why?”. In these situations, there is typically a touch of fear that compels the team to simply accept directives rather than asking probing questions.
A good way to think of this is to envision a funnel. Only so many widgets can fit into the funnel at a time. If you need for a specific item to go through the funnel, something else is not going to get to pass. This is very much like building a Product.
Only so many pieces of functionality can be built. Eventually the project ends or funding is eliminated and you are left with features that did not get built, while ‘never to be used’ functionality was completed. Some of the functionality that was not built may have had business value and\or high ROI. This is waste and is often perceived as an Agile Failure when in-fact it is a Product Owner prioritization issue..
There are some ScrumMasters (and Project Managers) that typically stay out of those kinds of details. Yes, the team is self-organizing. Yes, the team has to learn by making mistakes. However, the ScrumMaster has to be involved enough to not allow the “just in case” methodology take hold. If it’s allowed to happen, you will find that what you have delivered in the end is not of the highest value.Talk to Us Today