This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Three Agile Styles
Guest post by Allan Kelly, founder of Software Strategy in the UK
From time to time I feel sorry for those coming new to agile. I feel sorry because some of them expect to find agile provides a solution to their problem. For better or worse, agile doesn’t provide a solution but many solutions. The agile toolkit contains many tools which solve many problems in many contexts. But, like showing a customer software, the problems and context only become visible when solutions are seen.
For the last few years, I have found it useful to differentiate three different styles of agile. These styles are independent of any particular method: Scrum, Kanban, Lean, XP, etc. can be used in any of the three styles. Each style addresses similar – but not identical – problems within different contexts. The result is that the solutions, while similar, differ.
The developers and testers are doing lots of good agile stuff: daily standup meetings, fortnightly iterations with planning meetings and retrospectives, small vertical stories and so on. Hopefully they are doing some of the technical practices: Test Driven Development, Acceptance Test Driven Development, Behavior Driven Development, Continuous Integration and, perhaps, Pair Programming.
As a result, the teams are better.
But the team’s work is still driven by a big requirements document. Someone has set down in advance all of the features and functionality which the team is expected to deliver. The job of the team’s product owner (often a business analyst) is to salami-slice this document into small, vertical stories for the team to build each iteration.
The fact that the team can show a working product every two weeks is irrelevant outside the development team. The business and customers want all or nothing. They have little or no time to look at demonstration – indeed being expected to attend a demo may be seen as an inconvenience.
In Iterative Agile, requirements are turned into code via a series of iterations which are confined to the development team. The wider organization does not want to change. You hear people say things like, “Agile is a delivery mechanism.” They expect agile to deliver more efficient teams, fewer cost overruns, better predictability and meeting deadlines.
Project success – and it is still seen as a project – is defined by how much of the original document is delivered in the time allowed for the money budgeted. Project managers continue to fear “scope creep” and resist attempts to move away from the original requirements document.
At first glance, this style looks a lot like Iterative. There is a big requirements document, there is a business analyst with a bacon slicer, the development team does iterations, and within the iterations is a lot of good agile stuff.
But in this model, business representatives, customers, users and more engage with the team. At the very least, review the software that is produced every two weeks in a demonstration. Feedback is accepted, some of the originally planned work changes, more work is added, but some is also removed. Hopefully the most valuable work is getting done first and the lowest-value work is falling off the end.
Better still, an incremental team may be delivering their product to live, and real users are using fresh software every few weeks. Hence, the business benefits early and value increases incrementally.
This also opens the door for the business analyst to perform post-delivery evaluation on what is built. This in turn allows the salami-slicing process to be better informed and calibrated to deliver more benefit.
However, there is still a requirements document and the team may still be judged on delivering everything by a predetermined date for a predetermined budget. Incremental agile potentially brings the team into conflict with project governance and thus creates tension in the organization.
Over time, the organization may start to adapt to the team. Success can be additive and others may start to change their working ways to fit with the team better – or even copy them.
Alternatively, the organization might kill the team! In fact, I believe in many corporate environments this is a more likely outcome. Incremental teams can be seen as problematic; they don’t stick to the script and they ruffle feathers. Unless they have a protector with sufficient authority and political weight, the team is at risk.
I have come to believe that in a large corporation, Incremental Agile teams are as good as it gets. It is hard to prove or disprove this belief and there will always be a minority who does better, but in a traditional corporate environment.
Evolutionary Agile can best be summarized as, “Don’t give me no requirements document!”
The development team is still doing all the good stuff. They are releasing to live at least every two weeks. The product owner will be more focused on reacting to change and delivering business benefit than delivering a document.
The wider business judges the team’s success not on how much software they have delivered against plan, but on the benefit they have delivered and movement toward some overarching goal.
There will still be a backlog of work to do, but it will start small and grow over time as the product grows. Much, perhaps most, of the backlog will never be implemented simply because the stories with the greatest benefit will squeeze out those with less benefit.
Indeed, in an Evolutionary Agile environment, this is how it should be…
Evolutionary Agile is most naturally at home in startup environments which need to react – pivot! – to survive. Inside the corporate world, the iterative style rules. Few corporations are ready to give up their faith in the big requirements document and forward planning.
In setting out these styles, I am describing what I find – not what should be. Few teams sit down and consciously decide to pursue one style rather than another. Each is a solution to a specific version of the problem: “How do we organize our software development?” within a particular context. And each context is loaded with history.
Having said that any of the three styles can be implemented with any of the agile methods, I do believe that Scrum tends toward the Iterative and Incremental styles while Kanban tends toward Evolutionary. My own Xanpan hybrid, with its planned and unplanned work model, tends toward Incremental.
Which is the “best” style? Well, I try to remain neutral. Each is a rational response to a context. Rather than say one style is “better” than another, I prefer to look at what the organization is trying to achieve and how it got to this point. Then I work to improve within the existing style – or perhaps, nudge the team toward a more appropriate style.
The Incremental style is probably the most common agile style of all. It might be seen as a step from one world to another; the best of both extremes; or perhaps the worst of both.
Yet, I find it hard to disguise my belief that Evolutionary Agile is in some sense superior, better, purer and truer to the original ideas of agile. I must temper my belief with a recognition that in some environments Iterative or Incremental approaches are more appropriate.
Indeed, one can imagine a spectrum with pure Evolutionary Agile at one end, and at the other end is traditional Waterfall development. Iterative Agile and Incremental Agile are just points alone the spectrum.
While I may want teams and organizations to aspire to Evolutionary Agile, it doesn’t really matter what I want. The challenge for teams is to position themselves at the most appropriate point on the spectrum and work effectively given the context of the wider organization within which they exist.
For many teams, simply moving from a poorly performing Waterfall model to Iterative Agile will be an improvement. One may hope they continue their journey along the spectrum, but if the wider organization is not ready to live in an Evolutionary world then the context is not right. And to do so would create more problems than it solves.
I find that these styles and the idea of a spectrum help me understand the world, as they provide the language to discuss it. I hope you also find them as useful.