The 12 Key Reasons Companies Adopt Agile 

Written by Mike Cottmeyer 

So… I’m starting to see a pattern here… 

Snowmageddon in Atlanta and I go on a ‘flurry’ of writing… get back into the groove of working, and I 

can’t seem to manage a post or two. I’m going to have to figure out how to muster some serious self‐

discipline if this book is every going to get written. Dennis and I got together the week before last and 

created an outline for Section‐Two. That content will show up as another series of lists over the next few 

weeks. For today, I want to go back a bit and talk through something I think we might have left out… 

why people want to do agile in the first place. 

A few of my clients recently have me noodling on the reasons that organizations and teams decide to go 

down this path in the first place. I’ve mentioned several times that no one really cares about agile… all 

they really care about is better business results. That said, I think the idea of ‘better business results’ can 

be broken down a little bit. That got me thinking about creating a list of the main reasons I hear from my 

clients they decided to go agile. So here it is… the 12 Key Reason Companies Adopt Agile. 

1. Faster time to market – Lots of folks that decide to go agile are pretty fed up with 18 month delivery 

cycles that quite often deliver the wrong products to market… one’s that our customers just aren’t 

interested in buying. The idea of two week delivery cycles and quarterly release cadences is pretty 

appealing. Our markets and our competition are just moving too fast… we’ve got to get better at getting 

working product out the door faster. 

2. Early ROI – The other day I was onsite with a team that was struggling to see the value in thin slicing 

their user stories. After missing a few sprints, the team decided to give thin slicing the old college try. 

They didn’t nail the sprint, but were successful delivering an increment of working software that was of 

value to the business. Here is a paraphrase of their Product Owner’s reaction: 

“Even though you may have thought it was less efficient to splitting stories, it makes a real difference to 

the business. I can show the output of this sprint to an external customer and sell business based on 

this.” <<< Very cool! 

3. Feedback from real customers – One of my customers told me that over 50% of the features they’ve 

built have not ever been used by their customers. That’s pretty consistent with other industry stats I’ve 

seen recently. Just imagine if we could take all that time we use to spend building stuff our customers 

didn’t want, and focus it on building stuff they’ll actually use. I hear arguments all the time that sprint 

planning or writing tests slows the team down… does anyone ever consider how much building the 

wrong product slows the team down? 

4. Build the right products – This may end up just collapsing this with #3, but for now it feels slightly 

different to me. Even if we are building the exact features that our customers are asking for, incremental 

delivery helps us build them the way our customers will actually use them. When we deliver in smaller 

increments, we have the opportunity to let our customers see the emerging product, respond to it, and 

tweak it as they go. Agile helps the customer and the team converge on the best possible outcome. 

5. Early risk reduction – Agile doesn’t treat risk as a separate area to be managed… agile is risk 

management. By delivering early and getting feedback, we reduce the risk of building the wrong 

product. By focusing on architectural risk in the early sprints, we reduce the risk that we won’t have a 

solution that can be build in time… at least we’ll know it early. By continuously integrating and building 

defect free software, we reduce the risk that our stuff wasn’t built right just before we need to bring it 

to market. Wasn’t it Tom DeMarco that said “Risk Management is Project Management for grown‐ups”? 

6. Better quality – Developers are generally tired of building crap and our customers are universally 

tired of getting crap. When businesses fix time, cost, and scope… the only thing developers have left to 

manage is quality. Agile fixes time, cost, and quality… and gives us the tools to vary the business and 

technical scope of the solution. You might not get everything you hoped for, but you can trust what was 

delivered. 

7. Culture and morale – Some folks want to adopt agile because the culture in their organization just 

sucks. Agile is a pretty hot topic, and most developers get pretty excited about giving it a try. Agile holds 

the promise of creating teams of empowered individuals… teams full of people working on the highest 

priorities of the business with a shared sense of purpose. When agile is done well, it creates really fun 

places to work… there is nothing quite like being part of a team of people working hard toward shared 

goals. 

8. Efficiency – I almost titled this one “reducing waste”… but that’s not how the folks I work with usually 

communicate it, so I chose to call this efficiency. People know that the big up front plans usually turn out 

useless in the long run. People know that the people in their functional silos aren’t working very well 

together. They know that the ‘throw it over the wall’ handoffs result in churn and back and forth 

behavior. Agile holds the promise of helping us eliminate the stuff we don’t need and get down to the 

business of building working software. 

9. Customer satisfaction – Building products our customers can use makes them happy. Being able to 

frequent add new features based on their feedback makes them happy too. As a software customer, I’m 

not sure there is anything worse than investing in a product that doesn’t work, doesn’t do what we need 

it to do, and not being unable to see any path forward for making it better. I’m willing to buy a first 

iteration product if I know it is going to do nothing but get better over time. As a matter of fact, it can be 

fun seeing the product emerge as the development team gets more feedback. Agile helps us build this 

kind of partnership with our customers, one where we are working together to get problems solved. 

10. Alignment – I want to explain this one a bit becuae I don’t think it’s immediately obvious. When we 

are organized in functional silos, when our teams are not organized around either products or other 

business objects, when our technology infrastructure is owned in more than one place… that’s being out 

of alignment. Agile suggests that we have cross‐functional teams that support products. This is really a 

simple expression of alignment and folks get it… they want it. In practice, sometimes though, the ‘one 

team‐one product’ relationship isn’t possible. The trick is to determine how to align the organization 

when the simple pattern breaks down. People don’t usually ask for ‘alignment’, but they want 

connection between effort and real business results. 

11. Emergent outcomes – Some folks aren’t trying to deliver against a fixed time, fixed cost, fixed scope 

plan… some folks don’t know what they want to build or how to build it. Some people are building 

products for markets that don’t exist yet using technologies that are brand new and cutting edge. Agile 

is a great way of building software when you have to explicitly account for the fact that you’ll have to 

learn as you go. Build a little product, learn something from your customer, adapt your vision, build a 

little more software, and ultimately create something that is better than you could have ever planned in 

a vacuum. 

12. Predictability – Most development shops are pretty bad giving the business any idea of when they 

are going to be done, and what they are going to get for their money. The business has gotten to the 

point where they almost don’t care how fast you build something… they just need you to get predictable 

doing it. It’s become a mantra of mine lately… I tell teams all the time that I need them get good at 

making and meeting commitments and stabilizing their velocity over time. In the absence of 

predictability, I don’t care about speed. In the absence of predictability, I have no idea what to tell my 

customer. In the absence of predictability, I have no idea how to coordinate and align the other parts of 

the business. At some level I have to be able to make and meet a commitment. 

13. Because someone told me to – This is a last minute addition… I guess we have a baker’s dozen of 

sorts.  I initially left this out because I don’t think it’s a real reason. At the end of the day, the person in 

power has some sort of reason, most likely driven by one of our previous 12.  The challenge though is 

that sometimes you get teams where this is the only reason they care.   If you are faced with a team that 

doesn’t buy it, and are only going through the motions because someone told them to, it will definitely 

influence your adoption and transformation strategy. 

Okay… so those are my top 12 (13)… I’d love to hear what you guys have to say. What have I left out? 

Why else do people decide to adopt agile practices and transform their organizations?