Whenever I get asked if Agile is changing, I ponder on how to answer.
To me, the obvious answer is NO. And then I look back into 1999 and the early 2000s, when I was an XP developer… and I say YES.
So… Is Agile changing?
Fundamentally, Agile is not changing. It is about how to think and please your customers in the face of constant change. That has never changed since the idea started.
Now, in its expression, the techniques, the tools, names, frameworks… there, yes, Agile is evolving.
How so?
If we look at this picture, one of my favorites to explain what Agile is, what do you see?
You’ll notice on the far right all the names that you hear people saying: Scrum, pair programming, TDD. Those techniques arrived from the experimentation those early software development teams used. They are still pretty powerful today, but they are not what Agile is. You can pick and chose techniques, and even invent one of your own, why not? Those were once invented as well.
Agile itself, is a mindset, on the far left. A mindset is not something mysterious, it is basically a way of thinking that sits on top of principles, which in turn are derived from values. Consider that how we think governs how we act. Hence the practices and the techniques we adopt are what somewhat give the flavor of what Agile is recognized by.
In other words, people tend to think Agile is Scrum (as an example). When in fact Agile is favoring people and interactions (one of the values). To make matters more complicated, some bold folks decided to experiment with the Agile approach to non-software products. And got great success. And the evolution kept going, based on the feedback from successful and not-so-successful cases.
The agile manifesto came out in 2001, as a culmination of thoughts that were already happening in the mid 1990s. You see, you have a good 25 years in there of ideas and experimentation. So yes, evolution is expected and natural.
Behold the innovation curve
Let us take yet another few steps back. Here is the Innovation curve, which is not new! It was proposed by Everett Rogers in 1962. And it looks like this.
Whenever an idea, a technology starts, there are always the people who invented it, or those who are searching for new ways. They are called The innovators. This is a tiny group of people and they start the next curve or wave of knowledge.
Then you have the famous Early Adopters, which is also not a big group, and those are enthusiasts and people who usually are keen on experimenting and discovering new things even if they were not necessarily looking for any new solution. They are just excited about new stuff and like to try things. At some point, when ideas are great, they get established. That’s when we have Majorities coming into play. This is massive adoption.
Then, at some point, most people have adopted it, except for the Laggards, the last group of people, like the name says. Usually, they are resistors or people that now have no choice but to accept the technology or the idea because it’s just everywhere. It might have become the new normal and it is maybe even imposed on them. Do you recognize a company or two in here?
Why the dissonance today
We went from a time when enthusiasts were trying Agile and Lean in software companies to a now where everybody wants to be Agile. Before people would say: “It doesn’t work, it’s a fad” for literally decades. Now even the most bureaucratic and slow to learn companies, those that are full of hierarchy and rigid processes, are attempting to adopt Agile.
But given the time and the learning collected in these past 20+ years, Agility itself is emerging in an agile way. We don’t contradict the original values and principles; they just got more sophisticated in their expression and went beyond what the first tools proposed. Pair Programming became simply Pairing. Pairing became several ways of collaboration, including Swarming. Just like we came a long way from rolling rocks, to chariots, and now cars. Evolution.
With this evolution, Agility now talks about outcome-first. It talks about how to enable people to do their best work, build trust, motivation, and purpose, customer-centricity. From “let’s pair up to review and code in one shot and reduce bugs” the lesson became “let’s collaborate to get the best most creative solutions out there”. See the evolution?
We’re past the stage of having to advocate for testing as a forethought, of cross-functional teams. These things are a given now as we push forward towards a new curve, maybe Agile 2.0.
And herein lies a dissonance. Think about the adoption curve. The laggards, the companies that waited until the very last minute and now have that FOMO (fear of missing out), are just now adopting what could be considered the rudiments of Agile. They are still debating and trying to understand why they should not separate test and development. They continue to insist in mini-waterfalls, a gate-phase approach to developing whatever. They don’t necessarily trust their people or operate in an environment that understands and accepts ambiguity, allows for partnership, and believes in abundance. They are still discovering the very first frameworks and applying their old ways of thinking to new ways of doing. And then they hear outcome-first and safe spaces, and they feel confused about where to go.
What can you do?
The role of the Agile Leader today is harder. If you are helping your teams and even an entire organization transition into Agile you will have to help them absorb 20+ years of knowledge.
I will not sugar-coat or offer recipes. Not because I am mean or protective of my “professional secrets”. The reality is that… it is just not easy and there are no recipes. But there are some strategies to take Agile where it is now and try and jump straight into this new curve. Here are my thoughts.
1 – Say no “Agile Transformations”
Yep, I said it. For starters, you can move away from what is rudimentary and help your company to NOT go through an Agile Transformation. Say no to big top-down Flashy Restructure. Old ways of changing into a new way of thinking. Incongruent. It will break at some point, and there are many weak points in this approach. Expect another post coming on this topic!
So you, instead of coming in as this framework specialist and deploying tools, go the experiment route. Be personal, be tailored to the reality of that company. And work with smaller groups. Think networks, not hierarchy. Literally working with the people and their pain points by affinity, more so than within the “change management plan for implementing Agile”.
Say no to deploying frameworks and ways of doing that are uniform across companies. You don’t need to all do the same things. You need all to go in the same direction. And that leads me to the next two points.
2 – Make the why explicit
The why for any change _big or small_ needs to be compelling because people will not work themselves out of a job or vouch for companies cost-cutting and planet-destroying measures. People really seek purpose in their lives and in their jobs. Help your team and the company’s management to understand and position this deep why for things.
So the job of the Agile Leader is to help people craft that why. Or make it very transparent if it exists but is somehow buried in bureaucracy.
Maybe that team just wants to be able to learn and improve at a faster pace. That’s a great starting point.
If this is an enterprise-wide change… the work is messier because the why needs to be clear and compelling. There has to be something that moves everybody, and it is more than just making shareholders richer. Let them be richer as a by-product of the sheer success of employees in delighting customers!
So, work with your teams and departments to craft that why. Why Agile? What are people looking for?
3 – Help them establish mechanisms for outcomes
Nice and dandy to know the why. Congratulations! That shakes people to their core.
But where are we going? That’s the natural segue. It’s time to have conversations with people on what are their real, inspirational-yet-tangible outcomes. Paint that future type of thing. It can be for a team or for the full company. But outcomes help us understand that if we are going “there” we know how to “course-correct” in our path, while still allowing freedom to experiment. Measuring success and measuring progress.
The outcome is not Pair Programming. It is not even collaboration! It is probably something along the lines of faster deployment times so that the customer is always up-to-date on their taxes (any CPAS here?). Maybe one release a month? One release a week?
Now the bigger the scope, the bigger the challenge. A team might be interested in releasing a new major version of the product every 3 months. A company might be interested in becoming a leader in their industry. That’s tangible, that’s bold and it’s helpful.
4 – Leave the how to the workers – and help them!
Hopefully and finally, now you are then able to have the workers, employees, and consultants, doing for the company what needs to be done considering the why and the outcomes. They can do it themselves, especially if they have the help of a coach and guardrails to stretch their wings without fear.
Just think of it. When someone asks you to do something and tells you exactly what to do and how to do it in YOUR day-to-day, how do you feel? I’d say it’s the opposite of empowered. But you do hear suggestions and it’s nice to have guidance on what we want to do, especially when we have no clue of what is possible.
What is really effective is to be very clear on purpose and give people support so that they can have autonomy in the ways of doing.
Final words
I hope I made a point that we don’t throw out everything we know from Agile of 20 years ago. The techniques and framework can help, and knowledge of how to implement them is necessary when the people chose to go down that route. And that the Agile Leader needs to know Agile in principle and in techniques.
Especially because in a way, companies and individuals that want to succeed with Agile will need to take a bigger leap than the early adopters did, and go for Agile is now. Otherwise, they have decades to catch up.
That means clear mechanisms for dealing with outcome first, the why behind things, learning from experimentation and accepting failures gracefully, really focusing on their customers and what’s important for them, and being prepared to let people be autonomous and figure out the how, which can be with a help of a coach, but not just imposed on a specific framework by the next consulting team.
That was a mouthful!
I hope some of it was useful.
What do you think?
