Agile software development has become fairly commonplace, 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 come 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
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 give 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 wants 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, but 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 challenges 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.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
