Title: When Agile Might Not Be The Best Solution
Session Type: Experience Report/Discussion
Submitter: Anna Shipman
Abstract: In the context of a company that follows a broadly waterfall approach, we have tried with a new project to follow agile principles. This was developer-initiated but had the full backing of management. However, in the most part, these processes have failed to find their mark.
In broad overview, it seems that the closer we move back to a waterfall approach the more we get done and the happier the team are.
I propose to talk about the agile practices we adopted, how we attempted to implement them, what problems we had and why some of the practices didn't appear to work, along with what processes we eventually alighted on.
I would hope that it would lead into a discussion about whether there are scenarios which are better managed *not* using agile processes, and if nothing else, help highlight what some of the less obvious pitfalls of adopting agile are.
Session Details:
15-20 mins presentation/talk in which I will cover:
- the practices we adopted
- the initial difficulties we faced
- how we changed the process and the problems we faced then
- why I think the practices didn't work and what we ended up with
20-30 mins discussion in which I'd like to cover:
- whether it's that we didn't do it right, or whether these problems indicate issues with agile that are worth addressing
- if it is that we didn't do it right, what recommendations can we make to other organisations who don't wish to/can't afford to hire coaches?
- whether or not it is ok to just choose some agile practices and adopt them, and if it is, ideally some kind of agreement on which practices could be included in the pick'n'mix and which ones absolutely cannot
- whether there are projects which seem to have the right preconditions (e.g. smallish, open to change, management and dev team on board) but would be better off *not* adopting agile
Who might be interested
Developers/project managers who are thinking of bringing in Agile to see whether they might encounter similar problems and perhaps find out how to avoid them.
Coaches to see a scenario where their principles may not work or alternatively to point out where we went wrong.
People on either side of the 'Agile must be all or nothing' divide who fancy a good debate.
Additional information:
The team was 5 people initially, expanding after several iterations to 9, and has so far been running for four months. The only member with direct experience of Agile is the project manager, but others in the team and the company have read widely, and we have had input from contacts at other companies. Among other practices, we have adopted two-week iterations, daily meetings, planning poker, and user stories. I am one of the developers on the team.
This session could complement Dan Rough and Rob Bowley's session as it sounds as if their attempt has found more success.
