Why when Agile Crossed the Chasm It Stopped Being Agile

December 16, 2017 — Posted by Al Shalloway

Before Agile crossed the chasm it was being adopted mostly by teams.  When it crossed the chasm it started being adopted by organizations.  Unfortunately, the early success has become a massive bog.  So many companies have had such bad experiences with Agile that it has become a bad word in some places.  What is so different about Agile as it started and Agile at scale?

Executive Summary

Our goal at an organizational level should be achieving quick realization of business value predictably, sustainable and with high quality. This also increases the ability to pivot as needed.  Agile at the team naturally works by creating an eco-system where people work together with few delays in workflow, feedback and between getting information and using it.  To accomplish this when multiple teams are involved requires a shift in management from focusing on their people to focusing on the flow of value across the organization.  “Who is managing this value” is often a question that is left unanswered in many organizations.

What we need to do

Building software, as in many product development efforts, one must:

  1. Understand what needs to be done       
  2. Decompose the work into small implementable pieces (this decomposition should be slices of functionality so that they can be built quickly for quick feedback and potential delivery)
  3. Focus on building the most important work to be done (based on value or feedback) and manage your work in process to build it efficiently
  4. Continuously get feedback from the business to make sure what is being built is of value to the organization and with the customer to ensure it meets their true needs
  5. Deliver as quickly as possible
  6. Continuously learn

A side effect of Agile methods is that there are fewer and quicker handoffs than before. The mere co-location of teams, focusing on one thing and using time-boxing achieves this.  This is the unacknowledged reason that Scrum can work so well.  It’s not so much the self-organization as it is setting up the eco-system within which the developers work.  Cross-functional teams naturally reduce delays in workflow, feedback and useful information exchanges.  These are three key ingredients for effective and efficient development.

Agile across the organization

Achieving these is a not tremendously difficult when you have a standalone team.  However, focusing on improving individual teams is often counter-productive to improving the multi-team development. Intra-team dynamics are quite different from inter-team dynamics.   At some point the challenges of working across the organization become more important to solve than the benefits Agile has achieved within the teams.  Using Agile to solve the bigger picture is often akin to using a hammer where a screwdriver would be better just because you have one.

But when many different teams are involved what you have to do in order to accomplish the above items changes.

1.Understand what needs to be done. This is now no longer merely understanding what feature needs to be built but rather what investment the organization should be making.

2.Decompose the work into small implementable pieces (this decomposition should be slices of functionality so that they can be built quickly for quick feedback and potential delivery). The size of these chunks are larger now, and are going to be given to multiple teams. The decomposition must be done so that multiple teams can implement them quickly with high collaboration.

3.Focus on building the most important work to be done (based on value or feedback) and manage your work in process to build it efficiently. It’s now not ‘most important’ for the team, but most important for the group of teams. This requires both a planning and coordination across the teams. This decision is usually beyond the teams’ purview and almost certainly beyond their authority. Business stakeholders are usually the appropriate navigators of the organization.

4.Continuously get feedback from the business to make sure what is being built is of value to the organization and with the customer to ensure it meets their true needs. This gets a lot harder when a team is working on multiple chunks of business value from different stakeholders because they have skills and/or knowledge that is limited in the organization. 

5.Deliver as quickly as possible. The delivery is no longer at the team level which likely has no value to the customer without the pieces from the other teams involved.  The focus needs to be delivery of value to the customer.

6.Continuously learn. While we must continue to have our teams improve we must also look to see how to improve our work across the teams.

And now there is a seventh one.  When multiple teams are involved we require other methods to reduce the number of handoffs required and remove delays in workflow and feedback.  While this naturally occurs at the team level, it does not at the organizational level.

Solving a Different Problem

Clearly, the challenges at one team are quite different than when multiple teams are present, especially if the multiple teams are inter-dependent upon each other and the business stakeholders are competing for their capacity.  Using a team focused software development method quickly devolves into a shadow of itself when attempted for where it was not designed.

Most organizations are organized by function, e.g., marketing, product management, development, support.  Even if not highly siloed this leads to a kind of top down management structure.  Managers have been trained to see if their peoples’ productivity, quality, and utilization.  Not only does this tend to create a command and control attitude, it ignores the fact that our work runs across the organization.  In other words, we should be managing the flow of work from start to realization.  But in most organizations, no one is managing this.  At best, it is a shared responsibility.  Watch the first four minutes of Hierarchy vs the Value Stream to see this visually.

What we can do

First, we must attend to the whole and that a systems-thinking approach is required.  We must also realize we are solving a different problem.  What we now want to achieve is business agility.  This is the quick realization of business value predictably, sustainably and with high quality.  This is a different focus.  It’s not that we don’t want Agile – we do.  But we should realize that the drivers of those in the executive suite are different from those in the development arena.  We all need to align and that should be on the mission of the organization and each group comes together to achieve it.

Additional Resources

Al Shalloway
CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.



        

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