Transformation is More Than Just Having an Agile Checklist

As a consultant, I get to see a lot of different organizations and work with a variety of teams. By now, virtually everyone has at least heard of agile and read the manifesto.  We also seem to have, in technology adoption terms, crossed the chasm, and so adoption by more traditional, sometimes slower moving, global scale organizations is well under way.  Agile has finally been vetted by the early adopters and is now becoming mainstream.

I, like others, talk about the difference between “doing Agile” and “being agile”—differing the big “A” agile and the little “a” agile is intentional[BC1] .  From an intellectual perspective, the notion of agile being a mindset and a different way of seeing and acting in the world rather than a methodology or a process usually resonates. Still though, I see a tendency to want an “agile checklist”; a tendency toward agile for the sake of being able to say “we’re agile” rather than genuinely zeroing in on value and excellence. I cannot tell you how many times I’ve heard “It’s not `agile` if you aren’t doing <insert practice here>”.

Not All Checklists are Created Equal

Back when I used to fly, I religiously used checklists even when I had the checklist memorized. Making sure you have covered every detail is particularly important when life and limb are on the line. Maybe it was superstition, but knowing that I had done the checklist freed up my mind to concentrate on the flying without any lingering doubts. I used the checklist to get the helicopter started and running smoothly before taking off. Once flying though, I would focus my attention on my destination; as far ahead out the windshield as I could see.  The checklist had its place, but checking off that list is a starting rather than end point. I’m telling you this story just to emphasize that I am a big fan of checklists…for specific situations.

When I get invited into a new organization, I have some things I look for in a team that is on an agile journey. I look for how they collaborate, both as a team and with their customers. I look for how they design for optionality. How do they articulate their stories? How do they address dependencies and impediments? How do they validate everything they build is working and hasn’t broken anything else? I look at how they design in adaptability, both socially and technologically. And especially, how do they hone their craft and have fun? It’s not really a checklist as much as a set of markers that I’ve seen with high performing teams and a vibe I get when I get to know them. As critical as I think they are, I don’t see mood, orientation and mindset as checklist items.

Agile Checklists Miss the Point of the Manifesto

The agile manifesto is a set of values and principles. I wasn’t there when they wrote it, but I’ve talked to several of the folks who were there, and I believe practices were left out of the manifesto intentionally. I don’t think they wanted to create yet another static methodology. Nothing against scrum and SAFe and other methodologies because they serve a purpose, but they came later as a subset rather than as a re-definition of agile.

Scrum ≠ agile

The tendency to have a checklist of practices limits our ability to see the bigger picture. It limits our ability to become adaptable and create adaptable solutions for the business. Still, we have to crawl before we walk, walk before we run, and so, having a predictable sequence as we get started makes sense. I think that is how scrum found a niche in the agile world. For those starting an agile journey, it provides a sequence and framework for getting things done in a predictable way. That, in and of itself is valuable for many organizations. Still, it is a starting point to a long journey, not the ultimate goal.

What About Metrics?

Metrics give us a baseline to start from and a way to focus on our ability to execute and deliver value to the business. As we progress, the data should show trajectory and help us design in course corrections that will help us collaborate on what we want to target as things to do and learn next. Assessments also give us a baseline, but with a different purpose. Metrics look at what we deliver and how we execute relative to what we committed to. Assessments look at what we are learning and how likely we will be able to continue to progress on our agile journey. Both assessments and metrics should be used as thinking tools rather than as a bludgeon to force behaviors. If they are used to force behaviors, I have repeatedly seen unintended consequences and gaming of the system rather than the intended behavior change.

Both metrics and assessments are a form of feedback loop and an integral part of the course corrections we want to be able to make. Continuously having an up to date list of skills we are learning as a team makes sense, but just being focused on checking off the boxes does not because the checkboxes are just the start of the journey. Teams need to persistently be looking at the goals and outcomes they are striving for; clarity around what is valued, how we are producing that value, how we validate it and what are we learning.

The Journey is Never Done

The learning journey is never done. Whenever I get the opportunity to appreciate art, I discover something new. Whether it is a different perspective on a statue, a painting, or a creative approach to a technical conundrum, I learn something new. I can listen to a song or piece of music I love and enjoy it repeatedly, not because it is different, but rather, because I am different with each listening. Agile is really all about learning, and like everything we learn, there is always more nuance, more depth to uncover.

Happy journeying.