If Agile projects are going to be successful and not degenerate into freefall painful projects an up-front assessment of the project environment and its ability to accept and cultivate agile methods is required.
About ten years ago I worked with ObjectStore, an object oriented database which, at the height of the dotcom era, seemed like a really good idea. I spent some time in Reading with the local office to see how things worked and I was surprised at their process for evaluating opportunities. Basically, object oriented databases are very useful in some cases (or at least were) and downright rotten in others. At the time when Java was on the up and object oriented developers were rejecting the relational model, it seemed like a good opportunity to flog the product to anyone who expressed an interest. But the people at ObjectStore knew that it didn't work everywhere and put considerable effort into evaluating whether the problem fitted with their solutions - inevitably ensuring that every place where their product was used was successful - saving a lot of suffering and embarrassment in the process.
When it comes to agile methods I can't help feeling that there needs to be a similar up-front process in place in order to asses the suitability of agile for the particular project. Projects that lack a propensity to be agile can then be managed accordingly - from a project management perspective, the inability to be agile when an agile methodology is being employed should be identified as a risk, and identified risks can be managed.
Some of the non agile indicators are:
Organizational inability to adopt agile methods
By far the most common problem in agile projects is a keen and very agile development team being doing a project for a business (customer) that cannot adopt agile. Indicators of this are fixed scope, deadlines, budgets, contracts, penalty clauses, change requests and all the things that make perfect sense to the business, their project managers and shareholders. It is also a difficult situation to manage, but rather than rewiring the project into a waterfall or freefall project, it could be massaged to (mostly) work if done carefully. A project manager could:
- Initiate change management if the business is keen on agile but doesn't really get it (yet)
- Structure the project to appear waterfall from the outside but agile on the inside - which can work if the 'inside' team has really good business analysis and domain specialist skills.
- Structure the contract to have more frequent deliverables - you may not get much involvement per sprint, but signoff after every two or three sprints is better than just at the end
- Do a smaller project up front as a completely agile project to get all the stakeholders familiar with how it works before a major project is undertaken
Geographically Distributed Teams
If the business insists that development be done off site with weekly meetings (for whatever logistical reasons) it is a clear indicator that things are likely to go freefall and being forced into this situation is also one of the most difficult risks to manage. A project manager has to find ways of opening up communication channels in order to get the pigs (those who have their bacon on the line) as close together as possible. The problem is that formal communication channels (which include email) tend to stifle the openness of communication and are quite time consuming and tedious. More non traditional communication needs to take place - perhaps group webcasting, progress blogging, FaceBook pages, wikis, twitter-style microblogging, web based task boards and frequent publishing of screen recordings.
Non Staged Delivery
Systems that aren't actively used at the end of the sprint can suffer from a lack of (or meaningless) feedback and it is not an uncommon problem. Consider a system that replaces an existing, high profile website - the existing site cannot be turned off until the new one, with at least the same functionality, is ready. In these situations it is common for the development team to 'go dark', with long sprints and 'suprise!' functionality. What is needed is some sort of pseudo-live environment where people can be tasked with providing end-user input. They can be from a formal focus group or even a group of users that have access to a private website in exchange for discounts or other perceived benefits. The point is to identify and utilise a sample of users that are outside the development team - if they are part of the normal testing team they run the risk of having inbred, incorrect views rather than a representative user experience.
Large Teams
It is virtually impossible to have a scrum stand up meeting with (say) 50 people - and other agile methods suffer as teams increase in size (how about a task board for 100 developers?). Large agile teams need to be structured differently in order not to collapse under their own weight - mainly by splitting teams into smaller ones. A project may therefore be an 'agile programme' consisting of smaller, functional agile teams that function independently. It is important however to maintain as many of the agile principles as possible and, for example, allow different teams to have their own full (all the pigs) stand up meetings rather than having one stand up meeting where most of the pigs are not invited.
So, given indicators such as these does it mean that you turn down the project because it cannot fit with your model of Agile? The answer is definitely no, because these situations will arise more frequently as agile gains traction and becomes successful. Over the years agile methods have come out of obscure projects into more mainstream development and business is starting to demand agile successes on larger projects. Larger, more business critical projects have control mechanisms and other constraints that may seem to fly in the face of agile principles which need to be adapted and incorporated into large programme management methodologies without losing the spirit of agile.
However, in order to facilitate success it is important that these projects are assessed for their propensity for agility very early on in the project so that the risks can be managed and methods appropriately adjusted and, in true agile fashion, clearly communicated to the rest of the team.
Simon Munro