The blindingly obvious is starting to hit agile proponents. Very few companies actually ‘do’ pure agile – it’s usually a customised approach which reflects internal processes or specific customer needs. There’s nothing wrong with this – I think it would be a colossal mistake to insist on ‘the one true way’ of doing every single project.
But I think people get confused as to where it’s appropriate to use agile approaches. For me, agile is a great developer tool. You give the developers a long list of requirements and a design, and they’ll use the best approach that fits the team.
At the other end of the project, you have a top-level directive: “Build me a website” – a single requirement with a large (hopefully) and specific budget. At this point, you can’t use agile – there’s no wiggle-room when you only have a single deliverable.
As the project moves along and its requirements become clear, you’ll start to have more people involved, separate streams of work and more opportunity to be flexible in the deliverables and the delivery approach.
In my experience, the executive & management-level activities do not lend themselves well to agile. These people need to know exactly what they’ll be getting for their money.
These (non-agile) activities include:
- Business case
- Business rules
- High-level requirements
- High-level solution
- Detailed requirements
- Detailed solution
From these, you’ll get different options with various costs and range of features. I’d also like to point out that the detailed requirements and solution need to reflect the level of uncertainty in the project – it the solution isn’t well known, then the requirements and solution can’t be too specific.
One of the possible options can be selected, and then passed onto the developers and designers, who can use agile approaches to deliver as best they can.
These agile-friendly activities include:
- Design / user interface
- Development of features
Along the way, particular requirements may not be feasible. These requirements need to be checked against their impact on business rules and if everyone agrees, they can be dropped. Conversely, other options may be discovered and introduced – again if they meet the business rules and don’t increase the scope, then go for it (time and money allowing, of course).
An absolutely important part of this is to communicate any changes back to the people who’ll be signing off on the finished product, and to make sure that the requirements and solution are updated to reflect features that get dropped or added. The worst thing is to have the original requirements compared against a project that has changed dramatically, and no one told the project sponsor.