Want Agile? No two ways about it, there are only two ways to go: Native or Industrial. Go another way and, sure enough, your quest for “agility” will yield . . . anything but.
Of the two ways, the Native way is the best place to start. After all, it’s what Agile has been all about—until now.
Agile Native
When you go “Native,” your singular goal is to stay true to what Agile is at its very core: people-oriented rather than process-oriented.
In this day and age, it’s a no-brainer to be people-oriented. Executives say people are their company’s greatest asset, and they mean it.
But saying people are your greatest asset is the easy part. Recruiting good people and prioritizing them over process—that’s the hard part.
Putting people before process is so hard that, ironically, by way of semantic diffusion, companies have come to reduce “Agile” to be just process. How tragic!
And so, it’s always good to refocus on what Agile stands for to begin with: people first. And if the word “native” can serve as a useful qualifier in championing this cause, all the better.
To be clear, this Agile Native credo doesn’t forgo process. On the contrary, not only does it value process, it also empowers you to make it your own and elevate it to an art form.
It’s just a complete shift: a shift from the process comes first and the people fit in, to the people come first and it’s up to them to work out the process they should use.
To paraphrase Steve Jobs:
You don’t hire smart people so you can tell them how to work; you hire smart people so they can tell you how to work.”
So, basically, put people first and empower them to hone their own practices—not yours, mine, or anyone else’s.
People First, Honing Their Own Practices.
And this, in a nutshell, is the Agile Native way.
Agile at Scale
When you consider the fundamental difference between the two approaches—people-first versus process-first—you realize that Agile-scaling frameworks and traditional enterprise tools are, in fact, the exact opposite of what the Agile Manifesto was about.
Simply put, when you prescribe an exacting solution enterprise-wide instead of letting teams figure out what to do and how to do it, you go backward to a pre-Agile way of working when process and tools came first.
Sure, you may say process is the price you pay as your company grows: process to operate as one, in control, and with economies of scale. What’s the alternative, a descent into chaos?
Well, there is one alternative: Don’t scale Agile. Instead, practice Agile at scale.
Don’t scale Agile. Instead, practice Agile at scale.
Because it’s one thing to want Agile to scale, but it’s another to practice Agile at scale, from the very top of the organization.
Wanting Versus Practicing Agile
People may be unsure how to say the word “agile,” but aside from that, what’s not to like? Who doesn’t want more agility?
Another appealing element of Agile is Scrum. Not only does Scrum give you a simple way to get started, Scrum also doesn’t require you to change your overall management structure: with Scrum, agility is something teams can pursue, be it one or a thousand.
But therein lies the rub . . . if all you have is teams using Scrum (or Scrum on steroids), you only scratch the surface of what Agile is about.
Sure, you will end up with dozens or hundreds of teams doing work in small chunks and short sprints. But there will be so many dependencies between teams, chunks of work, and sprints—not to mention dependencies on non-Scrum teams and non-Scrum processes—that you will wonder how much agility you really got.
The answer: not much.
Worse still, with all those teams sprinting nonstop, you will see complexity increase and team members run out of steam.
What then?
Agile Industrial
True, in the traditional sense of the word, “industrialization” goes against the very essence of Agile.
Here, though, the “Agile Industrial” way is not about standardizing and mechanically scaling how people work, by means of some Scrum-type framework or prescriptive one-size-fits-all tool.
Instead, it’s about creating and refining a modern management practice on a large scale: an overarching Agile practice.
The next step is to organize this practice, focusing on specific areas.
More specifically, the Agile Industrial way puts emphasis on two key areas: (a) organizational structure, and (b) enabling tools.
But not just any kind of structure and tools, mind you: structure and tools that are elegant and powerful.
So elegant and powerful, in fact, that they enable agility rather than impede it.
Organizational Structure Using Containers
To approach organizational structure in an elegant and powerful way, think containers.
Back to Scrum for a second, Scrum thrives on small containers: small teams (people container), small backlog items (work container), and short sprints (time container).
Likewise, to practice Agile at scale, use nested container structures.
To practice Agile at scale, use nested container structures.
Starting with your management hierarchy, the goal is to minimize the number of levels and calibrate the size of your “containers” until you achieve something that works for you.
For example: 3–9 people make a team, 3–9 teams make an area, 3–9 areas make a product, and so on, all the way up to the top-level container that covers your entire company.
From there, you can use the same type of nested container structure to organize and align other dimensions, not just People but also Products, Projects, and Practices.
This way, you will see the big picture and keep finding ways to simplify and improve as you zoom in.
The following article delves into the details: Agile at Scale Using Containers.
Elegant and Powerful Management Tools
When it comes to management tools, Agile favors the most basic solutions. After all, what’s more elegant and powerful than a whiteboard and Post-it Notes?
Agile values the simplification (if not elimination) of management tools so they don’t become something that gets in the way and create waste.
That said, as the size of an organization increases, it starts to make sense to invest in elegant and powerful tools—the Agile Industrial way.
Let’s face it, the big companies that specialize in so-called agile tools are hard at work adding bells and whistles to tools that are already bloated—so you may be out of luck finding elegant solutions that fit your needs.
Look at it as a good thing: if you are serious about it, why not build and market your own modern solutions? Put your best people on the job and they will be force multipliers.
Just remember, the tool is not the thing: the tool should make people’s lives easier, not harder.
The tool should make people’s lives easier, not harder.
Final thoughts: Navigating Your Own Transformation
So there you have it:
The good old Agile Native way of letting people work out the process and tools they should use.
And a modern Agile Industrial way of refining organizational structures and management tools to make people’s lives easier.
As a big company, you can operate in different modes at the same time: the Native way (in “mini-companies” within the company), in parallel with the Industrial way (give yourself two years to transform your overall company), in addition to the traditional way (for parts of the company that are fine as is).
And whatever you do, don’t give in to the hype or the backlash associated with the “agile” label. Stay grounded and, by all means, use your own labels. Because it’s true: Agile thinking, Native or Industrial, boils down to nothing more than common sense and competency.
Deliberately create your own Agile practice and, with sustained leadership, you will be on your way to transform and optimize (as opposed to sub-optimize) your entire organization and sub-organizations within it.
