Yoga and agility

My wife dragged me off to do yoga this morning and I’m glad she did. The instructor really got me thinking with some of her instruction. She had a theme today around how yoga is not the poses or the positions or even the movements, but rather a state of mind.

She repeatedly pressed us to get in a yoga mindset. The mindset of balance, and centering and relentlessly seeking effectiveness with our bodies in such a way that it propels us not just through the yoga session, but through the rest of our lives. Pretty existential stuff really, but it was resonating with me for some reason this morning. Maybe it was because it was early and I just had an open mind, but while she talked, I kept thinking about how what she was saying related to business agility.

I’m an agile transformation consultant, and so this conversation around what constitutes “agile” comes up repeatedly.  I can’t tell you how many times I’ve heard someone say “If you aren’t doing <practice>, then you’re really not Agile”, and I grimace a little, remembering that exact thinking in myself a while back. In 2002, when I first started learning about agile, I eagerly fired off a message to Ron Jeffries. Ron is an original signer of the agile manifesto, and I asked for a short list of the “required” agile practices. His response was unexpected. He said I was focusing on the wrong stuff and to reorient my thinking.  “It is not about agile” he said, “it is about excellence”.

I’d like to say that I “got it” immediately, but I didn’t. I’ve been working with organizations around agile transformations in one form or another for what seems like ages, and I’m still catching myself being a bit dogmatic at times; maybe we all do. I think it is human nature to want to get to some solid answers even when there is no single “right” answer. I guess it goes to show we are all learning all the time.  

Websters defines agile as “able to move quickly and easily”. It does not mention process(es) or practice(s) but rather alludes to skill, or ability; a way of being. Being in the learning, the discovery, the unfolding of how to become excellent is very different from learning the steps to a new process, new templates, or new tools. Learning, whether it is learning to drive a manual transmission, or learning a new approach to solution delivery, requires us to be open to the ongoing discovery of the domain.

This is an important distinction for me because it points to a different manner of adoption. As the saying goes, we have to learn to crawl and to walk before we can run, but that doesn’t seem to stop us from trying to get ahead of ourselves. I’ve witnessed teams where a light has gone off and they become thoroughly committed to Test Driven Development (TDD). The approach is proven to help teams “be” agile rather than just go through the motions. There are real, measurable competitive advantages.

That being said, I’m not big on “Best Practices” without context. Test Driving is a very good practice depending on what you are out to do with it. There is a significant initial learning curve, but it has repeatedly been a way for teams to increase both velocity and agility. It helps them automate in a multitude of ways and be responsive when new requirements emerge or changes are needed.  

It is not however, a panacea to be blindly adopted across the board. I’ve seen teams misinterpret enthusiasm for TDD on new development projects and embark on wholesale efforts to retrofit all of their current codebases with automated test suites. Legacy rescue, is not an effort to be take lightly and trying to do so, in my experience, can end up being both an expensive and a wasted effort.  This is true particularly if it is on a codebase that is going to be sunsetted in the not too distant future. The effort to retrofit automated test suites always seems to be harder and take much longer than expected. I have helped a team do it successfully, though it took years of continuous effort. Your mileage may vary.

Rather than zero in on rituals like standups and retro’s or jumping straight into test driving, I recommend three fundamental changes in thinking:

1. Impediments and dependencies can bring delivery to a crawl. Clear the runway for teams to go fast.
• A well groomed and prioritized backlog is one of the most effective ways to help teams focus on the work at hand and quickly get the work done.  
• This also is an area that scales organizationally. That is because the way we bring work to the teams starts with the Business Portfolio, is vetted, designed & planned primarily by the business, and if done well, has the majority of issues & dependencies addressed or accounted for BEFORE the teams start to work on it. 
• Well groomed backlogs sounds straightforward, but in my experience, truly addressing dependencies and impediments prior to taking it to the teams is one of the most challenging parts of “being” agile.
2.  Set teams up for success
• Teams need a full compliment of skills; this includes architects and DevOps.  They need all of the roles required for delivery, and, if there is any possible way for it to be done, they need to sit together. 
• Teams need an ability to get work done without impediments, and not having everyone that is needed for execution on the team is a barrier to successful delivery and that means no matrixing. For many organizations, this is a significant challenge, but it is essential to building trust.
• Teams need to stay together. To gain synergy and increased velocity, projects can come and go, but the team needs to stay together through tough times and good. Teams need trust and the reliable iron will of trust is built, not when things are going great, but rather, through adversity met and conquered...as a team. 
3. Be clear about the ultimate situation(s) we are out to produce. Get feedback from customers.
• Working tested software can mean very different things for different organizations. Teams need to know what success looks like. From the satisfaction of the customer, to the satisfaction of the shareholders, teams need to know where the bar is set.
• Delivery of a project is only the beginning. Teams stay together because customer satisfaction is a much longer game than the last release. Teams need to maintain ownership of having built a solution that will accommodate changing needs and changing markets for the long haul. Solutions need to be built for agility.

Agility is not just flexibility in how to do things, but in what we choose to do. If that were not the case, it would be called “static” rather than “agile”. So, the next time you hear yourself, or someone else, saying “you have to do <blah>, to be agile...question, with all sincerity, whether that particular practice really produces agility.
Websters is helpful. By saying agility is the ability to move quickly and easily, it helps us orient around skill rather than practices or rituals. That yoga instructor was helpful too though. She helped me see that adopting an agile mindset means that we can focus on a few fundamental things while still maintaining the latitude to do them in a multitude of ways.

The yoga instructor was articulating it very well this morning. It is not about the practices we are doing that everyone sees, but rather, our own story, on the inside, of why we are doing them, and our relentless pursuit of excellence. The ability to move quickly and easily is a learned behavior. The world keeps changing and we keep learning, and as such, our answers around what constitutes business agility will likely keep changing too.