The 4 Most Common Mistakes Made By "Agile" Teams

Executives, keen to keep their firms on the cutting edge, are calling for their companies to adopt an agile approach, extolling its benefits, while simultaneously lacking a clear understanding of what agility actually means. As a result, the word agile has been thrown about freely, without much agreement to its meaning, adopted by organizations, in software and otherwise, that aren’t actually agile at all.

Over and over again we’ve watched organizations become enamored with the ​idea​ of agility. We’ve seen teams enthusiastically break their project work into two week sprints, schedule a couple of regular scrum meetings and declare themselves agile. And then, invariably, we’ve seen these projects fall into turmoil.

Timelines and budgets fall apart, accountability is lost and both stakeholders and team members are at their wit’s end. At our shop, we hear sad stories every week from companies that have been working with ‘agile’ for years and spent hundreds of thousands of dollars but have nothing or very little to show for it. That goes against the very nature of agile!

The inexorable disintegration of these projects isn’t necessarily a result of Agile’s tools being usedincorrectly, rather, it’s an issue of​ doing A​gile rather than​ being​ Agile​. While Agile’s practices and processes are essential, the true backbone of the methodology is the Agile mindset. It’s this mindset that creates great teams that consistently deliver great products.

The Agile Manifesto was written in 2001 by seventeen software developers seeking to overhaul the software development processes that they felt was cumbersome, unresponsive and too focused on documentation requirements. It reads:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions​ over processes and tools
Working software​ over comprehensive documentation
Customer collaboration ​over contract negotiation
Responding to change​ over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

To really understand the Agile mindset it’s necessary to take a close look at this manifesto, line by line:

Individuals and interactions over processes and tools

One of the most common mistakes we’ve seen people make when adopting Agile practices is the Agile hybrid. Typically, this takes shape as “Wagile”, an attempt at combining Agile and Waterfall methodologies to varying degrees. The issue here arises in the fact that Waterfall is generally a highly bureaucratic, top down process that depends on many rigid practices that work in direct opposition to the Agile mindset.

Because these types of practices eliminate strategy and decision making for all but those in upper management, the big picture is often lost at the individual level, typically taking any feelings of investment with it. They also mean valuable time being lost to waiting- waiting for multiple approvals or sign off’s, or merely to speak to someone in management - processes that create clear impediments to actually delivering value to the customer.

Agile teams are, at their core, cross functional, self sustaining units, consisting of everyone and everything necessary to complete the project at hand. By definition, they simply cannot work within a bureaucratic system.

Within an Agile framework, strategy and decision making are relegated to the team as a whole. Individuals self organize during Sprint planning meetings with tools such as points poker, and create strategies to improve their processes during Retrospectives. The Agile mindset recognizes that the individuals understanding of the big picture, and where their work fits into it, is integral to its success.

Working Software over comprehensive documentation

The primary focus of an Agile team is to consistently deliver value to the customer, and Agile Sprints were created for precisely this reason - to continuously deliver functional pieces of a product to the customer from the get go. We’ve seen teams spend months writing product requirement documents that detail exactly what a product should do before they’ve even written a single line of code, and then go on to work in two weeks sprints and call themselves Agile.

When working within an Agile framework, resources and time should never be wasted on lengthy documentation. Instead, your focus should always be on delivering value in the form of working software and product demos to the client. While infrastructure is important, it should be lightweight and flexible. If you are working with a truly Agile mindset it’s very likely that your process and plans will change, making carefully crafted documentation an ineffective use of time.

Customer collaboration o​ver contract negotiation

It’s fairly common for teams using Agile processes to encounter clients with little understanding of how software and design actually work. Clients coming from more traditional industries often express a preference for a Waterfall approach, requesting fixed deadlines and budgets with requirements gathered up front, and little involvement with the development team.  Development teams commonly  give in to these requests for fear of losing the client.

Problems inevitably arise when, after considerable time has been put into the product, the market  changes or, as often happens, the client realizes they don’t actually know what they want (or don’t want) until they actually see it.  At this point project work must halt, the development teams efforts re-directed into the time consuming and often frustrating process of re-negotiating the budgets, deadlines and product requirements originally agreed upon. When dealing with an uninvolved client, this scenario may play out multiple times over the course of a single project.

Agile thrives on both client collaboration at every step of the project, and flexible project planning. By keeping the client involved in the prioritization of work before each sprint begins, and by delivering a fully functioning feature for client feedback at the end of every sprint, you ensure that the product being built is exactly what the client wants. And when changes to the product roadmap do become necessary, they can be done at minimal time and cost.

Rather than falling into the trap of attempting to use Agile processes on a Waterfall client, it’s important that the time, money and frustration saving benefits of running a fully Agile project are clearly communicated to the potential client.

Because it can be difficult for individuals working in more traditional industries to understand why collaboration and flexibility are so important for software development, it’s crucial that you explain the how’s and why’s of how Agile actually works in practice. Our two part article, “The Evolution of Agile” helps make sense of Agile for those in Executive positions.

Responding to change​ over following a plan

As mentioned above, we’ve run into many teams who, for one reason or another, fall into the Waterfall practice of planning complete projects, to the finest detail, at their outset. The product development team’s task then becomes executing the project in alignment with the project plan- a task that becomes difficult when areas for improvement or changes to the market become apparent.

Rather than spending time and resources on avoiding change, Agile embraces it as an opportunity to create a more valuable product. By creating and continuously revisiting a product roadmap with broad goals and flexible estimates, improvements to the product can be made with minimal extra effort and time. If your roadmap is flexible enough to handle iterations as they are needed, you won’t be stuck creating an obsolete product when, in the middle of development, a competitor launches a similar product.

We know that working with a truly Agile mindset can feel like a difficult endeavor at the outset - we’ve been there! But, with years of experience under our belts, we can say with conviction that being fully Agile creates a far more smooth and successful product development process than any other we’ve experienced.

If you've been struggling with getting your team on the path to Agility, take a look at our Introduction to Applied Agile and Product Roadmapping Guidebook!