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?

And it got me to thinking about critical aspects of agile maturity. I want to share a few critical characteristics that come to mind.

Feedback & Open Dialogue

There’s a game that’s been going on for at least as long as I’ve been developing software.

Leaders ask for a product with fixed scope and fixed dates. Teams respond with realistic plans and then leaders apply pressure because the estimates are out of line with their expectations. Usually the actual delivery aligns with the original dates, but the pressure creates an unhealthy ecosystem of distrust, pressure, micro-management, and low quality deliverables.

Instead of this game, mature agile teams move towards open dialogue, effective listening, respect, trust, and effective feedback. Trying to force delivery commitments doesn’t work, so the move is to create shared vision and shared capacity assumptions so that decision-making is realistic and effective.

And the notion of delivering “slices” of potentially shippable product increments keeps everyone apprised of progress towards their goals AND allows for feedback-based adjustments.

Focus on Results

There are an incredible number of agile teams today that are simply sprinting. They grab a set of stories each sprint, usually an hour or two before the sprint, and begin to deliver them. Often there is limited attendance at the sprint review, but that doesn’t really matter. The team has delivered their stories and they’re moving onto the next sprint.

I often call this “sprint at a time” thinking and the focus is solely on execution and delivery. But I often ask, where are the results and the value?

More mature teams focus not only on quantity, but also towards quality and value of what they deliver. They continually ask themselves: are they solving the customers’ challenges and are their clients being delighted in what they receive?

A big part of this strategy is experimentation. The willingness to try new things, take risks, occasionally failing, but all the while learning.

Relentless Continuous Improvement

A hallmark of continuous improvement is effective use of retrospectives to mine the team and the organization for the truth. This is where the team explores what are they doing well, where do they need to improve, and how.

One of the greatest tools you can use is a formal assessment, best by an “outsider” of your agile teams. There are a number of assessment frameworks on the market today. I happen to prefer the Agile Journey Index, by Bill Krebs. But the frameworks matter less than having a seasoned coach come in, using a framework, and assessing your current state of affairs. In a word, getting a second opinion.

A key here is open-mindedness to change and facing the “elephants in the room” as far as true improvement goes. I find so many teams go through the motions in their retrospectives and pick the easy things for improvement. Basically they’re avoiding the hard or uncomfortable challenges. Mature agile teams face whatever is standing between themselves and improvement – then they eradicate it.

Team First

We’ve been following the commands of our leaders seemingly forever. The model is – they do the thinking and we do the execution. The implication is that the teams are simply workers.

The agile approaches are trying to turn this command-and-control approach upside down. Sure leaders still matter, but they realize that the best results are driven by self-directed teams, where the team is the prime owner. And in this case, the team always comes first in accountability, in empowerment, in ownership, and in decision-making.

A solid indication of maturity here is the team focusing on being T-shaped in their roles and responsibilities within the team. I often see team “swarming” around the work – collaborating around getting stories completed as soon as possible. It’s this whole-team view that is a hallmark of maturity, but also of getting more done.

A Broad Focus on Quality

It never fails. At least once a week someone reaches out to me about their agile testing, complaining that its not working and the primary reason they’re struggling fully adopting agile. Frequently “automation” is a strong part of the discussion.

So the entire focus is on automation and testing as being the critical challenge for them achieving agility.

I wish testing wasn’t even a part of the quality discussion in agile teams. If we didn’t create bugs, then there would be no need for testing. So testing isn’t the point. Defect prevention is. And the view to defects should be broad �� including code, design, requirement, and virtually ALL areas in our development efforts.

In mature teams they have left behind the notion that testing is their only quality practice. Sure they automate and they test. But it’s more of a “safety net” for their other efforts. They focus more on getting the requirements “right” up front via conversation and pairing / inspecting the stories as they unfold.

And did I say that it was a WHOLE TEAM effort?

Wrapping Up

I tried to limit my characteristics to five. Not sure if they should be viewed as a “Top 5” or not? But I do feel them somewhat crucial indicators of agile maturity.

But if I were to boil things down to a single maturity factor it would be:

Mature agile organizations, leaders, and teams are strongly aligned with the agile principles and core practices, they apply common sense and context-base thinking as they go, and they trust they’re “thinking people” to deliver the goods.

Stay agile my friends,

Bob.

 

Learn more about Velocity Partners offshore software development company