The popular press makes Agile sound like nirvana. Practitioners speak of it in nearly religious terms. Yet we often find that IT teams are underwhelmed after going “Agile,” even after having expended considerable effort on making the change.
Why is this? Is there too much hype around Agile? Could it be that it doesn’t work? No, it’s because they’ve fought only half the battle: they got some of the practices, but not the behaviours.
When teams or departments decide to “go Agile” they’re typically moving away from what they’re doing now, as much as if not more than they’re moving toward what it is they want to be doing. That is, they’re trying to get away from regressive behaviours where the way work is done impedes responsiveness, or they’re trying to get away from chaotic behaviours, where people are pursuing responsiveness at the cost of consistency and quality.
Changing the way work is performed is no simple task. Making investments in how work is done is extra effort above and beyond what has to be done just to keep up with the day-to-day. And there’s stationary inertia in IT: a lot of practice and theory have roots dating to the Eisenhower and Churchill eras. Getting away from regressive or chaotic states takes a lot of effort, and that effort isn’t necessarily sustainable.
No surprise, then, that many IT teams lose their appetite for change once they’ve shed their bad practices in favour of minimally good ones. But good practices are not the same as good behaviours. And that’s what separates the “functionally Agile” teams from the truly responsive ones. Do developers have a Pavlovian reaction when the alert goes out that the build is broken or are they content to leave it to somebody else? Are people co-located and directly engaged with each other in the execution of team responsibilities, or do they simply sit near each other still working in silos and swim-lanes?
Agile is not a Boolean question. There is no single thing you can do, or tool you can adopt, that will make your team “Agile.” It is a collection of practices. The extent to which these practices are mature in a team determines how responsive the team can be. The more mature states of practice require aligned behaviours.
This isn’t academic. Working with several colleagues, we’ve constructed an assessment tool, called the Agile Maturity Model. We’ve looked at 10 dimensions including project management, requirements, development and configuration management, and identified consistent patterns of progression – or maturity – in the way people and teams move toward more agile practices. For example, a team that infrequently performs its build manually today will not be able to cope with a build that automatically fires with each code commit and fails if code quality levels are below a specified threshold. The same is true for collaboration: a team that communicates requirements or project status by presentation is not going to get much mileage from automated collaboration tools. Durable practice results from taking incremental steps. This is how we gain mastery.
A maturity model helps us understand what it is we are doing as well as what it is we are not doing. That it’s based in experience makes our path to responsiveness less a matter of opinion, and more a matter of fact. But the real value is that it gives us some insight into the cost and the returns of taking the next steps. For example, perhaps if our frequently executing build were a continuously executing gatekeeper of quality, we could eliminate hours of rework, lost productivity and late nights because of bad builds being released into an environment. Or perhaps we wouldn’t have missed a subtle shift in the business priority had we been working as a team to deliver small but complete business requirements instead of technical tasks. A maturity model helps us to clearly pinpoint our best opportunities for change.
Using the model, we can also index where we’re at. There’s merit in an index, in setting some quantitative value for our target, historic and current states. It helps us to be more
communicative about our strengths as well as our deficiencies. But the point of having an index isn’t to score or grade. The model isn’t our team, and the model doesn’t give results to our business partners. All it does is gives us an indicator of the extent to which we’re past the point of doing things that undermine responsiveness, and at a point where we’re behaviourally aligned for it. Or, that we’re not yet past that point. An index is an indicator that helps us frame our situation; it is not our sole purpose. Process is important, but we’re on the payroll to deliver solutions; we’re not on the payroll just to have really great processes.There’s nothing wrong with being “functionally Agile.” Breaking free of the restrictive practices or simply getting some control over chaos is a better situation for an IT team, and usually is the result of significant effort. But don’t mistake it for being organizationally responsive. Recognize there are degrees of practice and find the optimal combination for your team or department. Above all, hold your teams to the expectation that they will not just perform to a set of practices, but behave in such a way that they maintain the highest state of readiness for whatever comes. Achieve that, and your IT organization will be more resilient to threat and better able to capitalize on opportunity.