A coworker recently pointed me to an image from a SolutionsIQ blog post The Third Wave of Agile which I’ve included below. The article calls out three areas in Agile thinking - Agile Teams, Agile at Scale, and Business Agility - with key events that either fostered the growth of opinions or reeled them in towards consensus. It’s a good read, one to add to your list after this post. <wink wink>
I got something out of this graph that goes a bit beyond the original article - ideas around what people are asking for versus what they feel or fear they need even if they aren’t ready to admit it yet. I believe Agile Teams and Agile at Scale focus on products; Business Agility treats products as a liability and organizational health as an asset.
Each wave is basically a problem statement. It’s saying “How do I/We do <insert wave> well?” The higher the crest, the more pundits you see crawling out from cracks in the walls, descending from the skies, arriving by the boatload to state their opinion.
The problems people are really bringing forward are rarely phrased that way. Instead I more often hear:
“I want to build this awesome product. How can I get my team to do it without taking 18 months?” Agile Teams
“I want to build this awesome product and have money to throw out the window, so I hired 70 people out of the gate so I can get this done in 4 months. How can I get them to build the product without taking 3 years?” Agile Teams, Agile at Scale
“I have all these great teams, and my product is a mess. How do I get it back on track?” Agile at Scale
“I have all these great teams, but no idea what to task them with. I’d really like to pay them to work on something more valuable than setting a Guinness World Record for stacking K-Cups or looking for a job elsewhere.” Business Agility
I listed a transition example in there. Some groups want to scale up right away, primarily because they’ve got all the people and resources lined up to do so. This is one of the best recipes for failure I’ve seen. To do something well at scale, large scale that is, means that it can be done well at the smallest level first. Start with problems, scale up problems.
We’ve got the Agile Teams ideas down pat. Communication patterns, making work visible, cross-functional teams - all that stuff is well known at the team level. That doesn’t necessarily mean that everyone is already doing it well. If they were, we wouldn’t still be teaching Scrum, Kanban, and team dynamics sessions to hundreds of clients a year. With the team working well together, they can get back to focusing on the product. That’s part of the problem we see with Agility at Scale right now; it’s assumed at the smallest level things are working just fine.
There is still a lot of noise with Agile at Scale because lots of people struggle with it. They start too quick or grow unsustainably on process, not principle, following their success. The right way to approach the problem of Agile at Scale often differs depending on a number of factors - size/structure of the organization, what the product is, interactions with customers, etc. This added complexity drags product development down with it.
Thankfully, a lot of people are experimenting with Agile at Scale. We’re learning a lot on the backs of many who are living it day in and day out. Thanks to the stories they share the prevailing ideas are updated and we get a little closer to consensus.
This brings us to Business Agility, a rather amorphous term that is still being invented even as we live it. The ideas have just started coming out in compiled form within the last five (okay, six) years. The Lean Startup. Management 3.0. The Leader’s Guide to Radical Management. Culture Eats Strategy for Lunch. Work Rules! The Advantage. Start With Why. I believe all of these books and the movements they created have a common message running through them. The SolutionsIQ article I link to teeters on the edge of it, yet the word choice could potentially lead one astray. That common message is:
Organizational health is the biggest factor of success, the only strategic advantage of importance.
Think about that for a minute.
There is something implied here, especially when looking at Agile Teams and Agile at Scale. Business Agility has nothing to do with products. Business Agility has everything to do with a healthy team, bound together around a purpose they agree upon. Products that people love, people who are aligned with that purpose, fall out of the equation. When you look at the speed of change in nearly any market, the immense potential to disrupt well-seated titans of an industry, this is the only thing that makes sense. Products are temporary, and thus so are the successes from them. Alignment, health, and adaptability of the company are what will allow the company to pivot towards success rather than fail.
Even if you’ve never heard the term Business Agility before, or have no idea what organizational health looks like, I have a feeling it’s moving around at the back of your subconscious. It’s standing there, saying, “Hey, this is good! You want to be happy at work. You want you team to be happy too, and you know you can do great things for your community together.” At the same time, your conscious mind is jumping at what’s pressing right now. Perhaps it’s trying to figure out how to get all these agile teams working in harmony on the product. Perhaps it’s speaking words of caution and fear about what the future might hold for your job or division if the organization were to change its structure to support a more healthy way of operating. A way of operating based on principles and vision, not products, that will ultimately help the organization succeed.
I know how that feels. It can be better, and there are so many wonderful people out here who want to help. Take that step towards Business Agility and learn what it feels like to truly experience success at work.