12 Key Reasons Companies are Adopting Agile

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 on adopting Agile. So here it is… the 12 Key Reason Companies are adopting 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.

Bonus Reason: 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?