Agile Failures

Beware of Snake Oil: The Agile Tool Salesperson

There are some great Agile tools on the market to manage backlogs, track metrics, create visibility, and measure capacity & velocity.  These tools range anywhere from free to several thousands of dollars.  We have nothing against these tools, as a matter of fact One80 even partners with several of these tool vendors.

That said, we have seen an alarming trend in the project management world of using expensive Agile tools to drive process.  This trend doesn’t apply to just companies using Agile but it seems to be accelerating, and it goes directly against the Agile Manifesto.

People and Interactions of Processes and Tools

This new trend follows into two categories:

1Molding Agile, Scrum, or Kanban (you pick the mythology) to fit a software tool.

We see many companies pick a tool and then force Agile to adapt to the tool.  Now to be clear, I am not against software tools.  There are some great tools on the market that can help manage backlogs, track metrics, create visibility, and  measure capacity & velocity.  Each tool approaches Agile in a slightly different manner.  The DANGER comes when a company chooses the tool first allowing the tool to drive the Agile implementation.

We recommend that when starting an Agile journey, always start low-tech: Post-it notes, whiteboards, flip-chart, or excel.  There is no need to get fancy.  Allow your team to focus on what is important – The Agile Manifesto and continuous improvement.  Over time the team(s) will create an Agile approach that works for them.  The Enterprise will begin to learn how to scale agile and develop effective Metrics that actually drive value.  Once a stable Agile solution is established, then and only then, can a company begin its evaluation of tools.  This is exactly the process the One80 follows in our Agile Kickstart program.

2Using expensive Agile tools or frameworks to solve team dynamic problems.

Every implementation of Agile and every team has their own unique challenges. These challenges range from Team Dynamics, Communication, Cross-team Coordination, Scaling, Vendor Management, Change Management (the list can go on and on).

We have found more times than not the solution to almost all of these situations is staring you in the face. Just ask the team, listen to them, trust them, and they will solve 90% of the problems. Yes, they may need a good facilitator to guide them, but let the team self-organize, let the team build some information radiators , let the team us their retrospective skills.  After all, isn’t that what agile is all about?  Inspect and Adapt.


Talk to Us Today

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.

blog image 2There 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.

Agile Failure funnel effectA 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