I have seen many Agile thought leaders assume something I don’t agree with – always get teams doing Agile before starting to scale. By scale, I don’t mean making projects larger, but rather having Agile extend across the entire project.

As Ron Jeffries once put 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 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.

Consider this. What if teams are overloaded with working on too many large items. Their challenges may be more based on this overwhelm than their skills. Also consider how much easier they can learn in a non-overwhelmed state. Many people who say we have to get teams to work first are really demonstrating a lack of trust with management to learn what Agile is and help the teams. That’s often a better place to start than the teams.

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.

Defending.
Old.
Glorified.
Methods in
Agile.

what other D.O.G.M.A. is out there?

Dogma – Persistently working towards a goal without ever questioning the methods being used.

Persistence – Dogmatically working towards a goal without ever being committed to which methods being used.

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

See Systems Thinking and How It Can Be Applied to Frameworks and Methods

---

This chapter was an excerpt from FLEX for the Disciplined Agilist: FLow for Enterprise Transformation (online book). It has been edited to fit into the Disciplined Agile Value Stream Consultant workshop. The Table of Contents for the book is here.