This is a guest post by Peter G. Walen.
Most of the time change is uncomfortable.
Sometimes it can be a little scary.
Then there is “Agile.”
Change is uncomfortable. It makes us do things differently than we are used to and often makes us think about things we likely would prefer not to think about. If we get it wrong it can look bad in the news. It might upset the CEO or Board at their breakfast. We mustn’t do that.
The result is people use a helpful euphemism: “Transformation”. People use that word because it sounds more impressive and has less baggage than “change.” Also, if there are problems along the way, folks can nod wisely and speak of the “challenges of transforming an organization like this one.”
Then there is Agile.
I was working in software development when lightweight and rapid development methodologies were first getting talked about. I remember reading about XP and finding the ideas encompassed in it interesting. I remember reading about the “Agile” Manifesto and Scrum and Kanban sometime later.
I’ve seen and worked at and with organizations that approached Agile a bit like people at the beach. A fair number will put their toes in the water a few times before wading in knee-deep or so. Some will wade in tentatively, get to a point and head back to shore or move deeper. Some go running headlong into the water.
Here are some of the things I’ve learned about how to have as smooth and painless a change to Agile as possible. They are gleaned from organizations where “Agile” went well and some from somewhere it went poorly.
Know why you’re doing it
Be clear about what you hope to achieve. Consider the impact on customers and teams. If the best reason you have is to “go faster” or “eliminate bugs,” this might not do it for you. You will discover things quickly.
Some of these will be uncomfortable. This will take a fair amount of introspection on the part of the leadership team around the discoveries. Without this and changing your outlook, behavior, and language, you will not see the benefits you hope to enjoy.
Ask questions about why you want to make the change to Agile. Be honest about the answers and the reasons for it. “Competitive Edge” is an often-cited reason, but what does that mean for you and your company? If your reasons seem a bit like a middle or high school kid wanting to be like the cool kids, I don’t think that will carry you through to success.
Either revisit that and think some more or don’t go any farther.
Use an experienced guide
There are many traps and pitfalls. Find someone you can work with to help you make your way through this journey. Be careful when looking for a guide. If they have a pre-packaged solution for you to use, be wary. There are many charlatans around selling something, just not something you want to buy.
Talk with their previous clients and ask them how things worked for them. You might want to ask about talking with their teams and their experience. There might be some different views on “how well” the change went.
One thing I learned, if the guide or coach only has stories about how well things went, be careful. Ask specifically about cases that went wrong.
Embrace the principles
Many people and organizations talk about the Agile Manifesto and look at the “X over Y” part. That is as far as they get. The core of the ideas is embodied in the “12 Principles of Agile.”
Internalize these and use them to guide your actions going forward. This includes planning the change to Agile itself. No single model will work in all organizations or teams. No set of motivational talks will convince people to do what you want them to do.
Instead, use the principles to guide how the leadership team works. To convince people you are serious about Agile, be serious about Agile.
Lead by example
Slogans and posters and pizza parties and t-shirts will not make a switch to Agile successful. Rolling out the typical “new way of doing things” slogans are telling people you are not serious and in six to twelve months things will be back to normal.
If you embrace the 12 Principles and adopt the ideas and practices you want your organization to follow, lead by doing it. Talk about what you have tried. What worked and what did not work for you. Then talk about how you’d like them to try it.
Then take the journey with them as an equal, not as a boss.
Choose your pathfinders with care
Most organizations have well functioning, high-performing teams as well as those that struggle. What I have found is that a team that is willing to try something new and go out on a limb also tends to be fairly high functioning. Morale tends to be fairly high. They do self-organized events even if it is simply everyone going to lunch. They get along well. They are a true team, not simply a group of people with the same manager.
That is the type of team I recommend be the “pilot” or “pathfinder” team.
Why? Setbacks won’t throw them in disarray. Most well functioning teams have learned how to adapt to changing situations and problems already. An “experiment” with an Agile methodology tends to be rife with challenges. A team used to work as a team will find ways to “make it work.” Then the next time around, they can make it work better. By the fourth cycle, they usually have become true believers and willingly tell everyone what they have learned and how they make it work.
Why not start with one of the struggling teams? Morale tends to be low. For a plethora of reasons they often don’t willingly engage in experiments, as Agile transformations tend to be. Most importantly, teams that are struggling tend to have a collection of problems already.
Switching to an Agile methodology will highlight those problems very quickly. Without taking steps to address and correct those problems before launching into an Agile transformation will only lower morale and effectiveness throughout the organization. It can ultimately doom the transformation to failure.
Sights along the trail
With any effort, remember, you are not the first to try this. There are warning signs to look for before and during the effort. These dots the landscape of Agile Change as wrecked and broken wagons of European settlers along the Oregon Trail in the US once did. Be mindful of them.
When launching into an effort, be mindful and watch the behavior of the teams.
If you have managers or leaders who use a heavy-handed approach, or “Management By Intimidation” it is a certainty their teams or groups will not succeed in an Agile model. Tayloristic command-and-control management is the exact opposite of what is needed.
Look out for team members who demonstrate toxic compliance, where they go through the motions and refuse to engage in the learning process while undermining those who try. That can doom the efforts of the people attempting to learn.
Finally
The hard part about any kind of change, Agile or otherwise, is identifying the reasons behind it. With Agile, it is not “doing daily standups.” It is not “increment planning” or “retrospectives” or any of the other labeled activities and rituals that organizations embrace by rebranding activities they already do.
The hard part is sitting down and doing the challenging work of looking at the organization as a whole. The hardest part is critically thinking on the very first of the hard questions: Why do you want to change?
Of course, the hard part about that is each person in the leadership team, and eventually, the organization needs to take a long, hard, honest look at themselves, their beliefs, work habits, intentions, goals, dreams, and desires. Then look at how those fit with their team and the broader organization.
For those who have never stared into the abyss of themselves, this can be a terrifying prospect. That may be why so many organizations back away and use a pre-packaged solution. That is why so many organizations fail in their Agile Transformations.
Peter G. Walen has over 25 years of experience in software development, testing, and agile practices. He works hard to help teams understand how their software works and interacts with other software and the people using it. He is a member of the Agile Alliance, the Scrum Alliance, and the American Society for Quality (ASQ) and an active participant in software meetups and frequent conference speaker.
