Why You Need to Begin Agile at the Program and Not The Team

January 21, 2017 — Posted by Al Shalloway

I talk to many people who have spent a lot of money and time on training their teams in Agile (typically Scrum) only after a year or so seeing little results.  They say that although their teams are following Agile practices but getting things out the door hasn’t improved dramatically.  This is not the fault of Scrum, but rather the fact that the bottom up approach for transition is flawed.

The classic Agile model of achieving Agile at scale is to train up your teams while attending to how they work together and then scaling via scrum-of-scrums.  There are two assumptions in this approach that are rarely questioned but are not valid.  These are:

  • Training teams individually while attending to how they work with other teams is an effective way to start
  • As you try to scale, the Impediments encountered can then be removed by management assisting the teams as needed
  • These assumptions are flawed, however.  Both evidence and logic bear this out.  The evidence is the number of companies that have tried this only to find the following challenges:
  • Collaboration across the teams is not necessarily improved when they are being driven by different stakeholders as each team needs to listen to their own stakeholder.  This causes a lack of alignment of the teams.
  • As teams become effective most of the work required for deployment can often be built quickly but very often small parts are missing that prevent delivery because the teams are not being driven by the bigger context of what is the entire backlog of development
  • Shared services, while being able to do a better job with Kanban, are driven by many people and aren’t clear what order to complete things in
  • The focus on the development teams often has non-software development teams (e.g., sales, support) be left out of key planning steps
  • It is often difficult to manage constraints outside of the development teams

The idea that optimizing the pieces (the teams) and then combining them ignores the reality that software development is an holistic approach.  On must consider the entire value network (that is, the flow of work from concept to realization). Ignoring how work gets selected and hits the teams also does nothing to influence the transition from a project based mindset (where new work comes in to different teams) to a product based mindset (where stable teams continue to build and support products or IT supporting software).

Teaching teams individually and then combining them is also a flawed teaching method.  Learning information, by itself, is not nearly as important as getting people to learn how to work together.  For example, knowing what Scrum is is considerably different from actually doing Scrum. Doing Scrum effectively as a team is quite different that doing Scrum in coordination with others. As they say in sports – practice as you play.  Teams at scale do not work in isolation, they work together.  Training them in isolation does not give them any experience in working together.  In order to do this, one must first create the context within which the teams will work.  In that way, as they are being trained, how they will work with each other can also be discussed. 

Attending to the bigger picture enables the organization to see impediments to the entire value network – not merely those affecting individual teams or how they work with each other.  The value network includes much more than the teams – it includes all of the steps prior to the work hitting the teams as well as how the software is deployed and supported.  Impediments that arise are often symptoms of deeper causes that are difficult to see in isolation.  Although management does need to support the teams, they are often the only ones who are able to see the bigger picture of the value network.

When starting an Agile transformation, we have found the following assumptions to be more effective:

  • It is better to transform an entire train (group of teams working together) so that the context in which they will be working is present when they are trained
  • Improvements should be driven by looking at impediments to the entire workflow of the train and seeing what the underlying impediments to value realization across the value network is.  Then address those relevant ones – often best seen by management who must attend to how the teams are working so they get input from them

The bottom line is, if you are attempting to transition to Agile methods, starting at the teams is not an efficient approach.  One must take an holistic view and consider the entire value network – training the teams within that context.  If you are considering a transformation to Agile methods and considering starting with Scrum training, I advise you to drop me a line (alshall@netobjectives.com) and let me discuss better options.

Al Shalloway

 

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