Agile methods don’t scale, if you are embarking on a big serious project you had better adopt a ‘heavyweight’ method. That way you have certainty, control over your resources and an agreed plan. Right? Wrong.
Agile methods promote using small teams because it improves communications. With improved communications the team members are more likely to understand the problem they are being asked to solve and therefore the proposed solution. Also when the project requirements change the team can more easily adjust. But what about large projects? How can small teams can deliver big projects?
The answer? Divide the big project into small independent projects. Nothing too shocking about that. But there is still a question about how to organise the work and structure the project. Earlier in the year I attended Spa 2007 where Dave Thomas outlined one approach.
The objective is to let projects have freedom to create the solutions to specific problems but to coordinate activity between projects. The approach is to structure the work into four phases:
- Envisioning;
- Definition;
- Development and;
- Release.
Envisioning
The envisioning team is tasked not with capturing requirements but rather with understanding the problem to be solved, defining the solution and finally building an executable prototype. The work is managed with Scrum but because the purpose is to build a prototype that meets the users’ needs the team works very closely with end users developing their solutions iteratively: adding fidelity and refining the design at each iteration.
If appropriate two envisioning teams can run in parallel developing ‘competitive’ ideas to explore different options.
Definition
The Envisioning Team provides a clear definition of what needs to be built; the Definition team designs how to build it. To do this the Definition Team is tasked with structuring the work and defining the initial Product Backlog. The aim is to reduce dependencies: not just between components, but between the overall requirements and the component designs. The work then is structured into a series of discreet teams:
- Feature teams (user facing services)
- Component Teams (core reusable components)
- Release Engineering (continuous integration and QA)
Feature teams can be responsible for no more than defining the unit tests for component sets – or integrating components with service specific code to provide specific functionality and/or glue sets of components together.
The Release Engineering team is responsible for ensuring that all the components and features work and conform to the agree interoperability framework. They therefore take each release and ensure the ‘system’ works, rather than trying to configure the system at the end of the project.
NB Components can be built out of phase with the rest of the project.
Development
The first job for each of the development teams is to review the product backlog to ensure that the project estimates are OK and the scope is understood.
If any product backlog item can’t be delivered or if there are any project dependencies these get escalated to the ‘risk backlog’ – which is owned by the Product Owner. Its the Product Owners responsibility to clear the Risk Backlog and not allow the individual projects to be effected.
Release
Code is packaged, documentation written, marketing etc.
And of course throughout this whole process everything is kept in the code: code, requirements, risks, people, estimates…
My name is Tom Scott and this is my personal blog. I currently work at Nature Publishing Group, I previously worked at the BBC. However, these are my thoughts and observations not theirs.
Made with a Macintosh
Published with WordPress
Designed with CSSEdit
Creative Commons
