Waterfall methods seem to work well for smallish projects that are well defined and well understood. At least from my own experiences of putting things together, but realistically to think of all possible scenarios and to write up all the possible solutions to the problem seems a little bit wacky. To also assume that the requirements process has captured requirements that won’t change close the end of the project is also a little unreasonable or unrealistic, this would be especially true on a project that is planned to run for a few years with fairly substantial goals in an ever changing research and development environment.
Waterfall styled methods just cause problems with planning and adjusting the process to the needs of the stakeholder (no matter what the stakeholder thinks they need, they will change their mind). Again this is especially true for long running projects.
So why not use agile methods? Simply because there is little or no plan and it requires real collaboration, delegation of tasks and trust to work towards a common goal. People get afraid perhaps?
The trick is communication and trying to introduce agile methods slowly and steadily into the system. I’ve been slowly introducing the idea of pairings, sprints and elements of scrum with kanban (yes, that’s lots of buzz words there already). Getting people to agree to talk is probably the hardest thing to do, and it’s even harder to try and get everyone on the same page without ego’s getting in the way.
It’s paying off a little for now, the team members are beginning to at least talk and exchange ideas. In my world that is a huge step already. Next is it try getting things done by prioritising tasks and resources.
Share!
See Also
- using continuous integration systems in a team
- the joys of working with a team across multiple institutions