Agile Q&A: Why do Organizations Adopt Agile?

Agile Q&A: Why do Organizations Adopt Agile?

Agile Q&A: Why do Organizations Adopt Agile?
via Agile Alliance by Kent McDonald

Agile software development has become fairly common place, some people may even say that it is now mainstream.

The success of those moves to Agile have met with varying levels of success, and I suspect that has something to do with why those organizations chose to adopt Agile in the first place.

Here are some of the main reasons organizations adopt Agile and a look at why the reason your organization chose to adopt Agile may impact how successful your Agile adoption is.

 

Everyone Else is Doing It

Some organizations adopt Agile because they are concerned that they will be at a disadvantage if they do not.

This is basically the “everyone else is doing it, so we probably should to” and is usually not a recipe for success.

Organizations that adopt Agile to keep up with everyone else fall into the trap of adopting some of the practices and using some of the terms, but not really understanding why they should do certain practices and changing their behavior in the appropriate way.

These organizations rarely see many of the advantages that comes with adopting an Agile approach and can often make their software development situation worse because they lose some of the structure they had before and do not replace it with the appropriate level of self-discipline required for using Agile approaches effectively.

Better Faster Cheaper

Agile Q&A: Why do Organizations Adopt Agile?Some organizations adopt Agile because they want to  increase speed to market, meet customer demand, or increase team productivity.

In other words, these organizations seek efficiency. They want to develop software better, faster, and cheaper.

These organizations are potentially setting themselves up for disappointment.

These organizations may experience increased speed and lower costs because they cut out processes that don’t add value. They may also deliver increments of their product sooner than they would have before.

If organizations follow technical practices included in Extreme Programming, they may develop better software.

But merely adopting Agile does not ensure that these organizations will truly develop software better, faster, and cheaper. Teams need to be willing to stop working on a product when they’ve solved the problem they set out to solve, even if there are still things in their backlog.

Organizations need to be willing to make the hard decision about what they’re not going to work on. Teams  need to be willing to take a different approach to solving the problem than what they originally thought.

Neither of these are necessarily “Agile” ideas, but they are essential prioritization concepts for experiencing benefits when using Agile approaches.

A Means to an End

Some organizations want to improve their software development, IT, or other knowledge work activities and see that Agile, along with other ideas, can help them accomplish that.

These organizations do not view Agile as the goal, rather they want more effective software development or have a specific problem to solve. They find Agile approaches helpful because it gives their teams a way to approach continuous improvement and adopt more effective software development practices.

These organizations are also less likely to even proclaim that they are “doing Agile” or even “being Agile”. Rather, they’ve identified some approaches and practices that seem to help them accomplish what they set out to do.

Why did your organization adopt Agile?

It’s very helpful to reflect on the reason why your organization chose to adopt Agile in the first place.

Was your Agile transformation started in the interest of keeping up with other organizations in your market? Is most of the conversation about specific frameworks or specific practices? If that’s the case you may suggest a pause to evaluate why your organization sought to adopt Agile. Identify the problem your organization wanted to solve and come up with some objective ways to know when you’ve solved that problem. Here’s a hint: the problem is not that you weren’t using Agile.

Was your Agile transformation started in the interest of being more efficient? Are people in your organization focused on increasing velocity and getting things delivered faster? If that’s the case, suggest that the focus should not be on producing things faster, rather trying to focus on producing the right things. Encourage your organization to explore how prioritization decisions are made and to approach work on your products from the perspective of solving problems with the least amount of work as possible rather than trying to always complete all the items on the backlog.

Did your organization begin adopting Agile where it made sense to help you address some challenge you were facing? Make sure that you continue to evaluate whether you are addressing those challenges and finding techniques or practices that help you move forward, whether those techniques are considered “Agile” or not.

Why did your organization start adopting Agile? Are you experiencing the outcomes you thought you would?  Share your experiences in the comments.

 

About the Author

Kent is a writer and product manager who helps product people deliver powerful internal products. He has IT and product development experience in a variety of industries including financial services, health insurance, nonprofit, and automotive. Kent practices his craft as Content Curator at Agile Alliance and shares his ideas and experiences at KBP.media. When not writing or product managing, Kent is his family’s #ubersherpa, listens to jazz and podcasts (but not necessarily podcasts about jazz), and collects national parks.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.

Continue Reading