Three Agile Transformation Gotchas

Many companies run into issues when they undertake an agile transformation. A lot of those efforts fail for one of three reasons. And they end up with a perception that “agile sucks”. I want as many companies and groups avoid these common pitfalls, so here are some ideas to help make your agile transformation stick.

Gotcha #1: Small Changes To Existing Processes

A lot of companies I work with look at their agile transformation in terms of machinery. They think that the development process is a large, gear-driven contraption with a crank handle. You turn the crank, the gears move and twirl and gyrate, and – ta-da! – you get a product. And they believe that agile changes the handle on that crank from a cracked, well-worn old wooden one to a nice new mother-of-pearl one.

They hire a Scrum Master (or send someone to get certified – a danger I talk about here) and in a few months come back to see that it’s not what they expected at all! Instead of a nice new mother-of-pearl handle, there’s a whole different machine. With push buttons! Where are the gears? Where’s the crank?

Continental Army Revolutionaries
Continental Army Revolutionaries

Just adding a daily standup or doing work in short timeboxes is not adopting an agile mindset. And agile transformation requires much more substantial changes. Work doesn’t come from managers but from a customer (directly or via a Product Owner). Work isn’t assigned; the team decides who will work on what tasks. And teams meet regularly to plan their work rather than planning all at once and then executing all at once.

Understanding that an agile transformation results in – likely – a radically different model of operation (crank to push button) helps an organization be successful. If they just think it’s going to be a new handle on the crank, there are going to be some serious issues to resolve. It’s not so much evolutionary as revolutionary.

Gotcha #2: It’s Only About the Team

Another cause of failed agile transformation is just thinking that it changes how the team operates. Akin to the mother-of-pearl handle above, those in charge think that the team will make some adjustments. And that those changes are limited to the team. The problem, of course, is that when we adopt any flavor of agile methodology and follow the Agile Manifesto, we need to keep this principle in mind:

Business people and developers must work together daily throughout the project.

That means that we can’t just change how our team does its work. I’ve seen companies that use something like this process: the business generate a Business Requirements Document (BRD) that becomes a Product Requirements Document (PRD) that is turned by the IT organization into a Technical Requirements Document (TRD) and various Design Documents (DDs). In this scenario, you’re going to have to re-think how work is done beyond just the development team.

Creating a product backlog with prioritized/ranked features and stories is a key component of success in an agile transformation. Without that – or by continuing death by documents – your teams will continue to flounder. A successful transformation means expanding the agile mindset beyond the team.

Gotcha #3: Failure to Launch (or Deliver)

The last gotcha I see with failed agile transformation is a continued adherence to rigid and inflexible delivery windows. Teams that are focused on meeting specific deadlines tend to wind up in a fixed-date/fixed-scope kind of hell that agile tries to avoid. That’s why we allow the business two choices:

  • Fix the date and float the scope; or,
  • Fix the scope and float the date
Launch! (NASA's Apollo 17)
Launch! (NASA’s Apollo 17)

When our teams work in quarterly (or longer) delivery cycles, they tend to push off work that needs to be done – especially integration and verification activities – until the last minute. As a result, they spend a lot of time doing activities they should have been doing all along. Delivering potentially shippable product increments (PSPI) is a key factor in transformation success. Delaying those PSPIs until the end means we miss deadlines and fail to deliver value to our customers on time.

Regardless of when we release to our customers, the team should focus on completing work every sprint. That sprint’s work may be released immediately if the business sees value there. Or it may be held until other features are completed to enable a broader feature footprint. Getting the team to focus on delivering those PSPIs is critical to moving the product – and our teams – forward.

Closing Thoughts

Companies adopting agile are going to face some serious challenges. You need good coaching and consistent and persistent communication. Otherwise, your company may revert back to the “old ways” and believe that “agile sucks”. If we avoid – or at least minimize the impact from – these three gotchas, the chances of success with our agile transformation increases dramatically. Focus on the Agile Manifesto. Work with the methodology. Communicate clearly. And set expectations appropriately. By doing all of that and focusing on the journey, not the destination, you’re going to succeed.

Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)

Have questions?






Bill DeVoe