Scaling up agile projects

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.

Large Scale Projects


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.


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.


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.


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…

6 responses to “Scaling up agile projects”

  1. So, basically he is saying use the four-phase approach of Unified Process?
    I couldn’t have described the RUP four phases better.
    That’s an interesting turn-around for an Agile leader. ;-)

  2. I’ve not used RUP myself, but my understanding is that certainly there are a lot of similarities. However, I think there are some important differences.

    During the initial phase: Envisioning focuses on creating an executable prototype based on understanding the users’ context and problem to be solved. Whereas Inception is more about developing a business case, document requirements and the like.

    The Definition phase critically focuses on defining the programme of work i.e. how to break the work into small, independent projects and the interoperability framework to tie them together. But certainly the Elaboration Phase is similar to parts of the Envisioning phase, with parts of the Definition Phase.

    There are also lots of similarities with DSDM of course, probably more than with RUP. It shouldn’t really be a surprise that there are lots of similarities between different methods since ultimately we are trying to do the same thing: we need a way to know what to build, how to coordinate related workstreams and manage the delivery of the product. The devil is, however as they say, in the detail.

  3. You really can do all the envisaging and defining you want but until the data meets the code you’ve no idea if it’ll work

    Build something, play with it, fix it, continue

  4. But how do you know what needs to be built i.e. what (business, user and technical) problems needs to be solved? This is the job of the envisaging team – to work with users, data etc. to understand the problem and to iterate solutions.

    If the development team is an external one (i.e. not an internal team to the business) then at the start of a project it is unlikely they will fully understand the problem they are trying to solve; and even with internal development teams they often don’t understand enough of the detail (or at least the individuals on the team don’t).

    Envisaging isn’t about designing everything up front – it is about trying to start a project with a clear, joint (developers, designers, and the client and other stakeholders) understanding of what needs to be solved and how the team will tackle it. Its also about trying to ensure you don’t duplicate effort between teams (remember this is about large project with more than one team working on it).

  5. […] written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the […]

  6. […] Ive written previously about using an envisaging team to scout out ahead. Not to design the solution but to understand the […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: