It’s been my experience that planning, prioritisation and activity transparency get the lion’s share of attention when teams are taking the Agile adoption journey. There may even be many who say that list covers all there is to Agile.
Of course focus on these aspects is essential, but should other valuable features be eclipsed? For example, is the adoption of pair-programming or peer-reviewing followed with the same diligence as the daily stand-up? Is the practice of ‘test first’ techniques as mature as the implementing of a Story-Wall or Kanban for instance?
Time for a metaphor!
The American muscle car versus the European sports car. The former is all about power, whereas the latter is often a balance of power and cornering. Let’s say a greenfield project is the long straight road that the muscle car is made for. Now let’s liken the winding track over the Alps to the route of the product already in production that is constantly being enhanced and refactored. Fast pace forward is useful but you’ll need to be able to adjust course without losing control.
Perhaps it’s no big surprise that the more project management side of Agile gets more focus. It’s often managers that get to set the agenda for Agile adoption and frequently they’ll focus on the classical project management aspects of software change delivery. Additionally or possibly symptomatically, Scrum is most often the framework latched onto as the Agile adoption solution. We’ll be great at moving forward at quicker a more predictable pace when we implement this aspect of Agile. We’ll be behind the wheel of a powerful machine ready to drag race with the project teams who are yet to adopt it. Yes Scrum is powerful; but it was intentionally designed as complementary to Agile practices found in other frameworks like Extreme Programming.
In many organisations the project management aspects of Agile are a massive challenge for adoption. We should continue to push for the transformation required to make that happen. But in the meantime are we missing a trick? Are we missing out on the value of adopting the rest of Agile, most of which does not require such organisation-wide transformations. Things like TDD or BDD and pair-programming are mostly in the control of the development team. There may be some resistance at first but this can be countered with some good selling: clear measurable comparisons of effort spent before and after.
The ‘test first’ approach and continuous-integration build in the ability to adapt to frequent changes in requirements. It creates courage to refactor and nibb
le away at technical debt. And pair-programming can get us headed in the right direction for achieving technical excellence and mitigating key-man risk. Thinking back to our metaphor, we swap our straight line project muscle car power for the European sports car that’s performant and adaptive; one that makes us confident to take those mountain hairpin corners.
Changing from how things have always been is never easy, even when the desire is present. At the very least however, why not make sure the agenda is properly balanced in your Agile discussions and adoption planning?
