5 Fallacies of Enterprise Agile Transformation

I recently wrote a blog post addressing the fallacy that Project Managers are not needed in Enterprise Agile transformations. Reflecting on that post, it got me thinking about other misconceptions I’ve seen and am regularly asked about by my clients.  Here are the ones I hear the most, and my attempt to clear up some common misconceptions.

Fallacy #1: “We don’t need documentation, we’re Agile!”

This fallacy I hear all the time.  It stems from the Agile Manifesto value “Working Software over Comprehensive Documentation”.  Many people read that and believe that we just want to code and not provide documentation.  What this actually means that it is more valuable to see working, tested software instead of spending a lot of time documenting up front.  It DOES NOT mean no documentation.

In many organizations, long-lived documentation is important.  It lives beyond initiatives to provide value in the future.  This value can be in personas, meeting audit requirements, understanding design decisions or system requirements.  Documentation can also be embedded in code, in automation and test cases, or in visual specifications.  The important thing I coach is to focus on providing documentation that is barely sufficient.  The goal is enough documentation to provide a shared understanding and no more.  Anything beyond that tends to not be useful.  No one is going to read giant documents that sit on the shelf gathering dust!

Fallacy #2: “Agile means we will be faster from day 1!”

I hear this one often as transformations begin.  Clients will try to compare what they completed in a year pre-Agile to what they are delivering now.  This, of course, is trying to compare apples and oranges.

What Agile does a good job of is focusing on delivering the most valuable work first and driving risk down early (instead of waiting until the end of the project).  We don’t want to try to deliver everything we did last year.  We want to deliver the highest value items quickly and use feedback to course correct.

Over time, stable teams, automation, and process improvements will make teams faster.  But, you may actually feel like you’re slowing down in the beginning.  Focusing on value prioritization and high quality reduces rework and gets your product to market faster.

Fallacy #3: “It’s been 3 months…we’re done!”

Repeat after me, “My Agile Transformation will never be done!”  This is an important concept to understand. You will always be assessing.  You will always be improving.  It is a continuous cycle that never ends.

The world is advancing at an incredibly rapid pace.  If you stop to rest on your laurels, someone will pass you by – and you could be synonymous with “Blockbuster” or “Kodak”.  One of the key concepts we implement is sustainability of your transformation.  Many Agile transformations fail because they don’t have the internal support and mechanisms to progress forward beyond the initial stages.  This is the new way of life!

Fallacy #4: “We will never be able to deliver in 2 weeks!”

If you are traditional waterfall organization, going from 8-12 month release cycles to 2-weeks Sprints can seem daunting or downright impossible.  You can absolutely get there, but it won’t happen overnight.

Enterprise Agile transformations take time.  And you will need help.  Defining an end state vision, implementing a structure, governance, and metrics will set you on your path.  Form, train, and coach teams in agile practices will begin to change the way you deliver.  Use metrics to assess your system of delivery and make changes to reduce your batch sizes and optimize flow of value.  Begin automation and DevOps efforts and identify and decouple your dependencies.

As you implement change, you will see progress.  True transformation is a journey, but it can be done!

Fallacy #5: “We can still do what we’ve always done, just in an Agile way!”

Change is hard. It can be uncomfortable. When things get stressful, we want to revert to we are comfortable doing. But, if that worked, why are you transforming?

We’ve all heard the definition of insanity – “Doing the same thing over and over while expecting a different result.”  Real change is going to mean doing things differently. It doesn’t need to be many changes all at once. In fact, I like to make small changes, measure progress, and adapt to things that are not working.

At scale, we can’t be Agile by being structured the same way.  It is going to require change, organized around products or value, bringing people together on cross-functional teams, breaking down work into smaller increments.

Remember, we’re cultivating something special when we adopt Agile. Reverting back to your old ways of working will diminish your results and produce bad habits. Make sure you have a clear vision, defined end-state, and good communication as to why it is urgent to truly drive change. Focusing on the “Why” will help align the organization behind that change.