I have worked for a couple of clients who, for legitimate reasons, have wanted to validate whether a project, team, or organization is agile or not. In one case, the divisional leader was concerned that some teams were only claiming to be agile and that sometimes their failures were being “blamed” on agile. This leader didn’t want agile to get a bad rap, so he hired us to assess whether they were truly agile.

Some in the organization had a desire to do this more cost effectively, though, so a questionnaire was defined for teams to answer about typical agile practices, like:

• Do you do a daily stand-up? (y/n)
• Do you manage your work in iterations? (y/n)
• Do you have planning meetings for each iteration? (y/n)

The answers were expected to deliver a final verdict about the teams, reduced to a binary determination: waterfall or agile.

Another large company I know planned to add a flag to their project management office system with the option for a designation of agile. When this box was checked, the tool would allow the user to not specify fields that are required for non-agile projects (like “Architecture Review Complete on: <mm/dd/yy>”). There was no plan to remove those fields from the screen for agile projects; the tool simply wouldn’t complain if data weren’t entered. There was no appetite for reimagining what an agile project management system might look like.

Agile Is a Continuum

Most agilists agree that rather than a binary designation, agile is more of a continuum.

You might represent this continuum as a slider, stopping not just at integer values, but anywhere on the scale:

Most environments are at least a little agile, so none of them would be all the way at zero. Similarly, none are “perfectly” agile—whatever that means—so you would have no fours. But any team, set of teams, or organization can fall anywhere in the middle.

There are usually environmental factors that provide tension against moving the slider more toward the agile right. Mitigating the impact of these factors—loosening the springs, if you will—can help, but only if you identify and work on them.

There are many examples of constraints that can inhibit agility:

• Legacy system dependencies
• Vendor dependencies
• Disparate technologies requiring different skill sets, resulting in divided teams—e.g., mainframe versus Java, mobile versus web
• Geographical separation of talent (different time zones, or even just different floors)
• Coordination among software, firmware, and hardware teams
• Lack of automated tests

Mitigation strategies are highly dependent on the context and may take a long time to effect.

There Are Multiple Continuums

Even this agility continuum, however, is a simplification. Agility can vary across different dimensions of software development.

Requirements: What to build

Take, for example, a team whose agility in requirements is immature. Observations might include:

• Predominance of backlog items resemble tasks instead of user stories
• Large quantity of fully formed user stories that won’t be done for months (perhaps ever)
• Lack of clarity on which items to peel off into a new iteration
• User stories look more like requirements documents than index cards
• Missing acceptance criteria

Even this is an oversimplification, but it’s a step toward more clarity about where weaknesses and opportunities lie.

Engineering: How to build

Perhaps in this same team or organization, the engineering practices are mature. You might see some of the following:

• Test-driven development as a standard practice
• High collaboration between developers and testers
• Low defect rates
• Poly-skilled talent

Linkage between dimensions is important. For example, poor requirements may simply make an efficient delivery team deliver the wrong features more quickly. On the other hand, independent, valuable, small user stories without automated tests will impart a regression test burden on the delivery team, which will reduce efficiency and time to market as the product grows. 

Once you determine your dimensions of interest, you can represent them on a spider chart for a more visual depiction of where your organization or team stands:

In order to understand the gap between where you are and where you’d like to be, plot a target value for each dimension:

You might also consider plotting a third perspective when going through a transformation to reflect your current positions compared to the start and target.

Are these the right dimensions to consider? Likely not. A mobile startup, for instance, would want to examine different factors than a large bank would. Similarly, an assessment of an individual agile team should differ from an assessment of a large company.

I have a vendor T-shirt that reads, “Are you agile?” A better one would read, “How agile are you?” If you really want to spark conversation, though, have it read, “How are you using agile to drive business value?”

Assessing where you stand and where your business needs for you to be is a start to increasing your ability to drive business value.