Challenging the Assumption That One Must Get Teams to Work First

March 15, 2014 — Posted by Al Shalloway

I wrote this entry as the start of a discussion on the Scale Agile Framework linked in group by the same name.  You can see that thread here.

Here's the post, that I realize makes a good blog:

As some of you may have seen, Ron Jeffries put forth a blog on SAFeTM that assumes something I don't agree with: Always get teams doing Agile before starting to scale.

As Ron puts it "most of your teams may not really be Agile at all. Until all your individual teams can really do what Agile teams do, using all those XP practices that SAFe does wisely recommend, it’s not time to start directing them with a large process. It’s time to get them trained and experienced in doing software right. After they can do it, you’ll find that most of them don’t need all that top down large process after all. The large process is trying to compensate for the problem rather than fix it."

While I think there is merit to this thinking, I do not agree the best way to achieve scale is always by getting the teams working well. As with most things, an approach depends upon the situation you are in. If the types of projects you are working on don't require teams of more than 30-50 folks, I'd probably take Ron's approach, because SAFe is likely too big for them. But many projects are too big or complex to unwind. In this case, looking at the big picture and getting teams to deliver in 2-week cycles may be the right approach.

The bottom line for me is that 1) I agree you want to solve a problem and not merely work around it, 2) look to see what the best way to solve the problem is. If it's there is no appreciation for agile, perhaps getting the teams to work in Agile methods is better. But if the root cause is how to get multiple skills in a siloed organization to work together, taking on an entire train may be best.

Part of Agile thinking requires us to avoid getting trapped in familiar/common solutions. I am reminded of Bucky Fuller's quote:

"I am enthusiastic over humanity's extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. "

In the same way we shouldn't assume SAFe will solve our problems, we should also not assume getting teams to work will solve our problems. I am a great believer in systems thinking. This means that most of our problems are due to the system we are working in. In large systems, local solutions are unlikely to get at the root cause. In those cases, SAFe may very well be the correct solution.

Here's a related blog: The Implications of Systems Thinking and Complex Systems  

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 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


I think what makes this topic so confusing is that the people arguing for each approach (bottom up, top down, or both) are all right in the particular circumstances.

The truth is that you need to have all of these approaches in your toolbox because, ultimately, what we are really dealing with is human psychology. We are trying to change the way people think and act and, in particular, what motivates them for or against change. From my perspective, this means that the real answer to the question of "which is the right approach" depends on who and where your project/program's passionate champions are.

If there are no passionate champions then you might as well walk away and tell them not to bother (you'll have to wait for a crisis to motivate them).

If there is any "secret sauce", it is the passionate champions. They have to be part of the team already and either respected by the team (earned respect) or in the management chain that controls the teams' fate. This is the essential ingredient that can catalyze successful change.

So I say when choosing what approach to take -- top down, bottom up, or both simultaneously -- start with where the passionate champions are and you will maximize your chances of succeeding.

thanks for your insights.  For folks who don't know Curt, he's done a lot of large scale transformations as an internal coach/consultant and knows that of which he speaks.

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