I often find myself talking to people who are in the midst of a switch to agile and who find the change very difficult to get used to. They may be strong advocates, but their team just "doesn't get it". Through discussion, I find that many of them are attempting what I refer to as "Shock and Awe" agile. If you couldn't tell by the name, I consider this another agile coaching anti-pattern.
The Shock and Awe Agile Coach
The Shock and Awe Agile Coach recognizes that a team has a lot to learn in order to become an agile team. To be truly successful, the team needs to know all about stand ups, story composition, story sizing, iteration planning, test driven development, continuous integration, and retrospectives along with a plethora of other practices, both technical and non-technical. There is no time to waste.
So the coach shares photos (or videos) depicting what an agile team looks like. The coach does a two day workshop on agile values and principles along with introductions to many of the common agile practices. Maybe the workshop is longer - who's to say?
And then the cube walls come down, the furniture is rearranged, the agile board goes up, and we change how we determine, track, and execute our work. Basically, everything changes all at once. This is a comprehensive fake it until you make it approach to implementing agile.
So what's wrong with this approach?
Simply stated, change is hard. There are a number of good books out there on the difficulty of change, the neuroscience behind how we think, and why habits are hard to break. And massive change is massively hard.
This approach prioritizes the appearance of agility over the understanding of agility. Shock and Awe agile coaching introduces the (sometimes complex) mechanics of multiple practices all at once without teaching the fundamentals underlying the practices. Shock and Awe Agile Coaching is really just an extreme form of Prescriptive Agile Coaching.
The Shock and Awe agile coach technique creates the appearance of rapid agile adoption, often devoid of the understanding requisite for sustainability. This is a prescription for cargo cult agile; mimicking the behaviors, but not truly understanding the underlying ideas.
Teach them to think; not just to do
I don't want to get all hippie-dippy on you, but agile isn't a set of practices. It really isn't. It is a set of values and principles. Check it out. You can see the origins of some known practices, but not one practice is specifically mentioned. In fact, Individuals and Interactions are explicitly called out as more valuable than processes and tools. Yet so many agile coaches focus on process. As Venkatesh Rao stated in his address at Agile Lifecycle Chicago in 2014
It's a special kind of insane to say people over process and then talk about nothing but process. #almchicago @vgr
— Michael (Doc) Norton (@DocOnDev) May 1, 2014
It's easier to prescribe practices than it is to teach a team to adapt and learn on their own. It's easier to tell people they're doing it wrong than it is to understand why they do what they do; what pain it alleviates or what rituals are being honored. It's easier to replace behaviors than it is to figure out a way to evolve behaviors.
It may be easier to do all of these things, but that does not make them better things to do. While simple is often effective in a complex situation, the same cannot be said for easy.
A simple approach
Teams and their interactions are complex. Agile implementations are complex. often, the best way to address a complex situation is with a simple approach. Let's not confuse simple with easy. This stuff can be hard.
My recommended approach is to Observe, Identify, and Adjust (then repeat).
Observe
Inquire, listen, and observe. What is the current culture; how do things get done around here? This inquiry is open, non-directive, and truly about seeking to understand. What motivates these people to do what they do? What scares them? What beliefs do they hold and habits do they engage in that are no longer evidenced by the environment?
Identify
Identify an area of pain. What hurts? What hurts that most if not all of them agree on? This might not be the thing you expect or even something you consider important. Alleviating their pain will gain you trust and will provide them a positive experience.
Adjust
Facilitate a discussion wherein they decide what to adjust in order to alleviate the pain. Help them think through how they'd validate the change as beneficial. Help them decide when they should assess. Some changes are harder than others. We can change the visual on a chart and determine pretty quickly if it helped to better convey the message. We can change the way we manage our daily stand-up and need a few weeks to be sure it really is better.
And Repeat
Then repeat the steps. Not every change will be beneficial. As we identify areas of pain that are familiar to us, we may suggest adjustments that are also familiar. For example, if the team has one go-to person for all code of a certain nature, maybe you suggest pairing (or code reviews or lunch and learn) to help share that knowledge.
Don't take huge leaps unnecessarily and don't worry about "best" practices. Keep moving in a positive direction solving problems and alleviating pain. It is far less important that the team Pair Program using TDD than it is that the team have a shared understanding of the code, agree on a definition of quality code, and are able to adjust the code to meet an evolving understanding of the requirements with little risk.
Small steps lead to big change
I meet people who are worried that taking small steps will take too long. We'll never get there. We'll settle along the way for "good enough". We won't get to "best".
Settle along the way...? You mean like a product owner who had a grand vision that would have taken two years to implement but with incremental delivery, stopped the project at six months because it was "good enough"?
We won't get to "best"...? You mean like the team at Hunter Labs who meandered into Mob Programming instead of getting it "right" with pairing?
I was a competitive runner for years. Cross country was my sport. Training consisted of roughly 80 miles per week with some hill and speed work mixed in.
One year, I had a light summer of running and jumped into fall training camp having completed no more than 25 miles of easy running in a given week in the prior months. Jumping into 80 miles per week with hills and speed was definitely Shock and Awe distance training. My body never completely adjusted. It was overall a slow, tired, and pain-filled season.
One year, I started my winter mileage at 30 miles per week and increased the my mileage by 5-10% every week as Spring started. Over the course of a couple of months, I got up to 70 miles per week. I then added in hills and some track work. I continued to increase the mileage by adding in two runs per day on a few days. My miles topped out at 100 miles per week for a couple of weeks before entering training camp. I had the best racing season of my life, setting personal bests at every distance from 2 to 13.1 miles.
My point is, small incremental changes got me there. Massive changes created too much stress. I couldn't adapt. Was I the best runner I could be? Had I mastered all of the "best" practices? I don't know. But I can say that small steps lead to big change.