Skip to main content

12 Key Reasons Companies are Adopting Agile

Mike Cottmeyer Chief Executive Officer
Reading: 12 Key Reasons Companies are Adopting Agile
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?

Whitepaper
Lead a Structured and Disciplined Agile Transformation
Download Now
Next Very Cool James Cameron Quote

Comments (9)

  1. Thiago Ramos
    Reply

    Hi Mike Cottmeyer!
    My name is Thiago Ramos, i’m from Brazil and I have to ask you just one question?
    What i need to do when the team doesn’t evolve? I mean, i got a team of six developers and they are all good people and excelent workers. Not all of them are “seniors” but they are good in technical mean.
    What happen is that i feel that they are not commitment with the project, they do their stories with a poor code and they don’t care about refactoring and makethe test in a good manner do you know?
    The problem is that i don’t know what to do. I’m one of them and i allways talk to them about that, explain everything i can, teach them something they don’t know, but i think they don’t care at all.
    My big question is: I should I do?

    Sorry for my english! Thanks!

    Reply
    • Mike Cottmeyer
      Reply

      Thiago… no worries with your English, thanks for the comment.

      Off hand, I don’t know that I have great advice. Maybe just questions. I’d look at the environment they work in first. Are they matrixed across multiple teams? What are their incentives like? What is their management like? Are they empowered to make decisions? Do they have an engaged business stakeholder? Do they have the tools they need to be successful? Do they have have all the people in place they need to be successful? Do they have the skills to do the work? Are they rewarded for team behavior? Are they punished for things that aren’t their fault. I wouldn’t start with the team, I’d start with the environment. My bet is that you have environmental problems that are resulting in this behavior. You seem to have been able to transcend this… maybe the others haven’t. Don’t know if this helps or not, but that’s where I’d start.

      Reply
  2. Jim Magers
    Reply

    Mike,

    Spot on as always, my friend. You capture some of this by pointing out culture and alignment, but I think that part of the sheer magic of a well implemented agile process is how it can heal a broken product management/product development relationship. Adversaries morph to become partners and advocates. I’ve seen it happen time and time again, and personally find it one of the highly rewarding aspects of bringing this process into a dysfunctional organization.

    I brought Agile into an organization recently where product management was complaining non-stop about development timelines and schedule. Six months later, I sat in a meeting with the CMO and one of her product managers that previously had been the most vocal complainer, and smiled to myself as I heard this PM go to bat and defend the release timeline to the CMO. He was no longer a frustrated customer of the development team, but rather a full participant and partner in setting the agenda.

    Magic!

    Reply
  3. Fareed Quraishi
    Reply

    Thank you for sharing.
    I came across your article because I wanted to strengthen my persuasive ability to convince executives and teams to adopt agile approach. As an agile coach of sorts, I found your knowledge of agile to be valid and vast. I hope you have had many positive experience applying agile principle to organizations. I’ve taken some take away notes as well, because of few things you worded in a way that were spot on. Again, thank you for sharing.

    Reply
  4. Seth
    Reply

    That is so true; more and more companies are choosing agile nowadays. It feels unbelievably good for entrepreneurs to be able to use the same methods as some of the biggest companies in the world, like Toyota or IBM.
    I recently read that agile is also perfect for software development companies. We all know that they take a great share of the IT market.
    Agile seems to be of great help for those teams. (Mentioned article: http://kanbantool.com/kanban-library/case-studies-devops/lean-software-management-bbc-worldwide-case-study)

    Reply
  5. Paul Nilsen
    Reply

    Hi Mike.
    Nice article. I think that predictability is among the top reasons. People got really impressed and satisfied when they actually see that future work can be predicted. This actually helps teams to increase customers’ satisfaction, because they know their average cycle times.
    However, I think that one of the main reasons is transparency (here is a good discussion about transparency https://goo.gl/ccWhH2). I recently read a couple of research papers, which state that teams who use Kanban realize they can see everything that is happening in their workflow which makes their work much easier.

    Reply
  6. Ahsan Naqvi
    Reply

    Hello Mike,

    As a Agile user my self. Your article is spot on. You have highlighted some of the most important reasons why Agile methodology should be implemented in every organization. Looking forward to many more articles.

    Thanks

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *