I was sent a request to gather my idea on what Agile Maturity looked like from a column writer. Here’s her request:
Here's my thinking: In 2015, I heard many software pro's talk about "Agile maturity." But you had to listen hard to hear the phrase. Nobody shouted it from the rooftops; it’s not a buzzword, or even a new idea. It was more of a whisper, an aside that came up in the context of other topics: continuous delivery, better business alignment, mobile testing—to name a few. Yet it seems to me that this whisper is crucially important – that a mature Agile practice is the key underpinning for successful software development.
But what exactly does "Agile maturity" mean? It appears to run that gamut from advanced beginner teams flush with their first solid success to those are that doing continuous delivery, with high levels of test automation that entails.
What is your definition? Is your Agile mature? What are you working toward?
I remember it was approximately 2008-2009 when I read a blog post, then article/paper about this idea. At the time Jeff Sutherland mentioned it, but the leading voice behind the idea was Scott Downey who worked at MySpace at the time.
Part of the reason I was intrigued was that agile coaches were really struggling to find their hand or balance when it came to “spinning up” Scrum teams at this time. Quite often the approaches were really soft and non-prescriptive. The coaches often hinted at a combination of practices, perhaps giving the team a link to a basic reference (the Scrum Guide), and then the teams were left to fend for themselves.
Often the results were horrible. The teams picked the practices they were comfortable with and left behind the rest. Often they picked such a trivial combination, that the results were hardly agile and hardly effective. This was also the time when Ken Schwaber coined the term Scrum Butt and the Nokia Test was being used as a litmus test to see if you were really doing Scrum or not.
In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.