Scale-down The Problem Before Scaling-up The Solution
People overcomplicate problems in a lot of different ways. Throwing unnecessary tools and technology at a problem and over engineering are typical, and so is creating multi-step multi-level processes that are cumbersome to work within and difficult to follow. Overcomplications frequently occur when rushing into solutions before the nature of problems are reasonably understood.
A common example of over complication in process is how the Scaled Agile Framework (aka SAFe) is often applied. The methodology, created by Dean Leffingwell, tries to be a solution for coordinating large-scale enterprise projects involving hundreds of people, dozens of teams, and an even higher number of deliverables.
Fundamentally, SAFe is not far-off from the values we see in other Agile methodologies. But these values, and their benefits, are lost in a thick fog of top-down processes when organizations attempt to apply SAFe at its largest scale.
In the blog article Is SAFe Safe?, Dave Farley sums-up this idea of lost Agile values in this way:
“I have said for years, since I first became aware of SAFe’s existence, that if I look at any small piece of it, while it looks too bureaucratic to me, it is mostly not wrong.”
Dig into the details of SAFe and you can find parts that are mostly right. But you’ll need to dig from the bottom-up. You would never know that SAFe has anything to do with Agile if you’re looking from the top-down.
SAFe was never intended as a one-size-fits-all solution. Leffingwell allowed the methodology to scale with “Configurations;” in the current version of SAFe (v6.0) these are Essential, Large Solution, Portfolio, and Full. (We can think of these Configurations as small, medium, large, and xtra-large.) It can be a serious and problematic overcomplication when larger SAFe Configurations are unnecessarily applied to a team, a group, or a department.
You wouldn’t rent an 18-wheeler to take a family of four on vacation, right?
The building blocks of SAFe are in the Essential configuration which describes the team, its leadership, delivery, and day-to-day processes (which SAFe calls Team Flow). Essential is where the best alignment with traditional Agile values and principles can be found. (In other words, the parts that are mostly right.) Attempting to apply any higher-level SAFe Configuration without teams being properly trained and effectively delivering at this lowest level first is synonymous with building a three story house on a foundation of matchsticks.
And in this alignment with Agile exist options to scale-down the problem. Since there are other lighter-weight choices of Agile methodologies why not start with one of them, such as Scrum, Extreme Programming, or Lean? If teams are delivering effectively, customers and stakeholders are happy, and organizational objectives are being met, perhaps you’ll find that’s all that’s needed.