"Agile" vs. "Agility"

September 22, 2016 — Posted by Marc Danziger

When I talk to executives at our clients, one point I always make is that as an industry (software development) we're doing many things wrong. Going Agile has been seen as a fix for many of these - but in fact that's a mistake.

No one cares that your development teams are Agile. They can plan and estimate and retro their hearts out, and it doesn't matter.

The only thing that matters is Agility - the ability of the organization as a whole to tightly connect strategic decisions to delivery to customers ("tightly" means rapidly and accurately).

Yes, team agility may well be a part of it - but often it's not even the biggest or most significant part. A client of mine complained that it took ten months to deliver new features, and asked me to work with the development teams to shorten the cycle. But when we built timelines, it turned out the development teams only had the feature for maybe three of the ten months. Seven months were spent in management decisionmaking and product definition churn.

Leadership wanted to focus on improving the Agile practices at the team level (and yes, they needed improvement), but I pushed back. It's easier, when running a factory, to demand that the workers on the production line work harder. The question is whether it matters.

If development is 40% of cycle time, and we can - with some effort - improve development by 20%, we've just improved the cycle time by a whopping 8%. Is that the easy win? It's politically easy, because in most organizations developers (unlike managers) have little organizational power. And developers' work is more visible and easier to measure. But are there bigger improvements to make for the investment of money and energy?

But as we're implementing Agile in development shops and time and again we're not seeing the overall organizational benefits we expected. Part of this, I think is that we've come to understand Agile as a collection of practices which will ideally lead to the collaborative, high performance teams that are our goal. And we measure our success in implementing all too often by measuring our developers' adherence to these practices.

Maybe, just maybe, we ought to consider looking in other places.

To do that, we have to have a systems view - a holistic view - of the process that delivers value to our customers, and we have to work to optimize the entire process, not just the shop floor.

Can that optimization be based on high-trust cross-functional teams, incremental delivery, empirical measurement, and all the other structures we love about Agile? Of course it can.

But it just hasn't worked all that well when we limit it to the development side of the house.

Go look at the Agile transformation planning at any medium- or large-scale organization and you'll see a traditional management structure with a layer of agility grafted on. Can we lower the friction within development by doing this? Sure. Make development a better place to work? Sure. But will we transform the organization's ability to compete or satisfy it's customers? No, we won't.

To do that, we have to do a lot more.
 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Marc Danziger

Marc Danziger is a proven leader and team-builder, technology visionary and problem solver. He has successfully led programs & developed products in a wide range of technologies for clients ranging from new startups to Fortune 100 companies. His core experience is in three areas:

  • Envisioning new products or systems;
  • Delivering technology, often by turning around troubled projects;
  • Improving organizations by designing and implementing improved processes.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban