People have asked the “what methodology should I use” question for a long time... More recently the question has changed to should I use an agile method (which flavor is irrelevant, but sometimes the question is “should I use SCRUM?”). With every means of inquiry, a non biased question is best, should I use agile implies that there is some preference for or against it… However, as the question is cropping up more and more, it might be best to answer it directly and with as little bias as possible…
You should run a project using an agile method if the project characteristics are such that allow it and that the environment facilitates it.
The key point to take from the statement above is that a project might be ideal for an agile methodology but the context might not be right to use it… Let’s first look at the project characteristics…
There are many ways for assessing projects characteristics, some of which are summarized by Mike Griffins in his article Agile Suitability Filters. Which one you select is up to preference and the particular problem domain. For this discussion, is not important. Essentially, different aspects of a project are measured on an ordinal scale; the level on that scale determines the suitability of agile methods for that project; for example the picture below shows the Boehm and Turner Radar chart.
For much more see the book Balancing agility and Discipline: A guide for the Perplexed, or read the paper that stimulated the idea Observations on Balancing Discipline and Agility.
The outcome of this assessment indicates whether or not agile is suitable. An extremely important thing to take from these assessments is that every project is different. You should assess each project on its own merits and not decide to use agile methods for all projects you run.
However, there are other factors which influence the methodology choice, outside of the context of a project, for want of a better term, the environment. From experience, these factors have more of an influence on the successful use of agile methods on projects. Mike Griffins also highlights this as Non-Project factors, where he coins the phrase “methodology bias” to indicate individual’s pre-conceptions or personal preference. By far the most critical component of a successful project is the level and quality of customer involvement. To understand why, let’s put it in context by looking at the problem and how different methodologies involve the customer.
The success of a software project is down to how well the developers understand what to build, or better said:
“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”
- F P Brooks, The Mythical Man Month (page 199)
The impact is highlighted in the Standish Group Software Project Survey (see Project Management for Information Systems 3rd edition by Cadle & Yates, 2001) 16% of projects were considered a success, 53% challenged (i.e. overran or missing functionality) and 31% failed. Also, Craig Larman highlights in his book “Agile and Iterative Development – A managers Guide” that historically 45% of functionality is never used (7% always used, 13% often used, 16% sometimes used and 19% rarely used).
A waterfall methodology addresses this problem through up front effort in requirements analysis and documentation with the customer. The artifacts of the process are verified against previous artifacts to ascertain their correctness. The customer then tests the delivered software and validates its completeness. Change is managed through a defined change control process. Cost of change is high and time between requirements elicitation and validation of completeness is long, thus there is a significant risk of delivering software which is incomplete (and therefore a failed project). This approach means the customer is heavily involved at the start and at the end of the project.
Iterative Incremental models, such as the RUP, validate the requirements earlier in the process by overlaying development with requirements analysis and software design (enabling demonstration of working, but incomplete, software). The aim is to mitigate risk by validating that challenging and critical parts of the system are understood correctly. These processes still generate supporting artifacts and have verification and change control structures (similar to linear sequential models). With this approach the customer involvement is still mainly at the start and end, although the customer will be slightly more involved than on a waterfall method.
The essence of all agile methods is the same… They are best described by the agile manifesto and the twelve principles of agile. Agile methods raison d’être is to frequently deliver working software to a customer that adds value immediately. Change is embraced to ensure only what is most needed is delivered and this is achieved through frequent (daily) face to face customer collaboration. Agile methods demand that the customer is involved throughout; the customer is part of the team.
The reason for this discussion is to highlight the importance of customer involvement. If you cannot have access to the customer when you need them, agile fails. In agile projects there is no documentation to fall back to, the customer is the only source of information you have: without the customer an agile project will fail.
Therefore, the most important thing to do when assessing the suitability of an agile method is to determine the level of commitment the customer is willing to give to constant contribution. It makes sense for the customer to want to be deeply involved in the product you are making them, however, there are a myriad of real world reasons why it might not be possible. With any process you deploy to solve a problem customer buy in is critical… The customer must understand what is required of them and be committed to deliver on that requirement. This cannot be forced and any attempts to make a customer buy into agile will result in difficulty. Sometimes, upfront analysis might just have to do…
It is also important to consider how frequently you are actually going to deliver functionality to the customer… If the customer doesn’t receive incremental builds of working software then how do you know what you’ve developed has actually added any value? This is discussed by Alistair Cockburn in an article entitled “Are iterations hazardous to your project”. He also coins the “Agile machismo points” idea; it highlights very well the importance of the core principles of agile methods!
It is possible to run an agile project on a fixed priced or time and materials basis. However, in both cases for the project to be agile the scope must be flexible. If the project is fixed scope, there is no benefit from using agile methods. If it’s fixed scope then more than likely the requirements will form part of the contract and thus be well defined (through upfront analysis). The point of agile is to allow change such that the developers are delivering software that will be used by the customer, essentially reduce the scary waste of 45% of functionality not being used!
So in summary:
1. Assess every project suitability against a set of criteria (reuse one off the shelf, like the Radar chart above). If it’s not suitable, don’t use it. Don’t assume because it worked for one project it will work for all!
2. Do not embark on an agile project if the customer is not available throughout the project. For clarity, available means you can see them face to face at least once a day… Or at least be able to pick up the phone and talk to someone who knows the answer when you have a question.
3. Are you going to deliver evolving software to the customer to solve real business problems? Is the customer proving the suitability of what you’ve developed in the last iteration? If no, you’re probably better off iterative incremental and not agile…
4. Is the customer able to re-prioritise and add requirements as they see the software? Are you contractually allowed to without invocating a time consuming change control process? Do you have to deliver 100% of requirements? If there’s no scope for change, then don’t use agile.
Remember, there are still iterative incremental models which reduce risk and increase quality. Your chose isn’t agile or waterfall! Hopefully this blog will help answer the question; we’re all still leaning so I’m sure there will be updates!