Scaling Agile Software Development for Larger Projects

“Small projects can succeed through sheer force of will and a bit of luck.  Medium and large projects require a more systematic approach” (McConnell, 1998, p. 36).

Most of the Agile Software Development methods are designed for small team sizes, for example the original XP team had 8 people, but what if we’re talking about 30 developers (let alone customers); what process should we use?

Categorising projects and methods

Alistair Cockburn (2002) categorises projects by the Criticality of the product and the Number of People, and he recommends picking a method based on this categorisation. He measures Criticality on this scale:

C=Loss of Comfort, e.g. order a pizza but get lasagne.
D=Loss of Discretionary Money, but system errors can be fixed by a manual system
E=Loss of Essential Money. System errors cause bankruptcy.
L=Loss of Life

In one project I was almost involved in, the categorisation would have varied over time. The initial functionality was a proof of concept involving change of address functionality, which was C (Comfort), or at worst D (Discretionary Money). Subsequent functionality was unlikely to kill the customer, i.e. if the system made a mistake it would still count as Discretionary Money. The team was expected to grow from 6 (ish) to 30 (ish). So in terms of Cockburn’s  categorisation system the project would have gone from a C6 to a D30.

[By the way Steve McConnell (1998), quoted above, categorises a medium sized project as 3-25 people for 3-18 months with a code base of 20-250 K source lines of code.]

XP

“Size clearly matters. You probably couldn’t run an XP project with a hundred programmers. Nor fifty. Nor twenty, probably. Ten is definitely doable” (Beck, 2000, p. 157).

Cockburn (2002) says XP is appropriate for C4 to E14 projects. This is not to say that XP can’t be used for bigger projects (it is already), just that it has to be tweaked to work for them:

XP, as written, has been demonstrated on projects with up to 12 programmers and four onsite customers. It may have trouble with larger teams due to its reliance on tacit knowledge. It is difficult to build extensive tacit knowledge without good osmotic communication, and it is hard to do with more people than conveniently fit in a room. A larger project team trying XP will have to adjust the teaming structures interfaces, and use of documentation to accommodate the greater coordination needs of the larger group and the thinner communication lines. (p. 169).

This has been demonstrated on at least one large XP project run by ThoughtWorks.  In his article XP On A Large Project – A Developer’s View Amr Elssamadisy described a big XP team that abandoned some of the XP practices, and introduced more conventional practices to cope with the size.

Crystal Orange

Cockburn’s (1998, 2002) claim Crystal Clear is a D6 method, Crystal Yellow is D20 and Crystal Orange is D40 – all are similar, it is just for bigger projects he introduces more formality. The Crystal family of methods is considered light-but-sufficient so I thought I’d compare Cockburn’s Clear (D6) to his Orange (D40) to see what we might add to our mix for larger projects.

The process definition (what Cockburn calls the “policy standards”) is identical in the two methods, except the duration of an increment is slightly longer in Crystal Orange.

Policy Standards Crystal Clear Crystal Orange
Incremental delivery Yes (2-3 months) Yes (3-4 months)
Progress tracked by delivered software and major decisions, not documents Yes Yes
Automated regression testing Yes Yes
Direct user involvement Yes Yes
2 user viewings per increment (at the end of the 1st and 2nd deep iteration; at the end of the 3rd the system goes to QA) Yes Yes
Downstream activities start as soon as upstream is stable enough to review Yes Yes
Process review workshops Yes Yes

Crystal Orange adds a number of specialist roles.

Roles Crystal Clear Crystal Orange
Sponsor Yes Yes
Lead/Senior designer-programmer Yes Yes
Designer-programmer Yes Yes
Usage Expert Yes Yes
Business Expert Yes
Project Manager Yes
Business Analyst Yes
Technical facilitator (e.g. JAD stuff) Yes
Architect Yes
Design mentor Yes
UI designer Yes
Reuse point Yes
Writer Yes
Tester Yes

The Crystal methods require more documentation than XP. However, Crystal Orange adds only two extra work products Crystal Clear – status reports and inter-team specs – and replaces the lightweight requirements specification with a more conventional requirements document.

Work Products Crystal Clear Crystal Orange
Release sequence Yes Yes
Schedule (user viewings and deliveries) Yes Yes
Annotated use cases or feature descriptions Yes
Requirements document (purpose, use cases, non-functional requirements, interface definitions) Yes
Design sketches and notes as needed Yes Yes
UI Design / Screen drafts Yes Yes
Common object model Yes Yes
Running code Yes Yes
Migration code Yes Yes
Test cases Yes Yes
User Manual Yes Yes
Status reports Yes
Inter-team specs Yes

So a bigger Crystal team uses more specialised roles, and produces more deliverables.

DSDM

The DSDM manual (DSDM, 1997) sets a limit of 6 teams of 6 people (including customers), and says not to use it for safety critical systems, so DSDM is probably a C4 to E36 method. DSDM is heavier than the other methods in that there are many prescribed processes and work products.

Work ProductsYes Description / What non-DSDM people would call itYes
Feasibility Report Project brief / business case
Outline Plan High level plan
Business Area Definition Requirements document
Non-Functional Requirements List
Systems Architecture Definition Architecture document
Outline Prototyping Plan Development Plan
Functional Model Some of Data/Object model, Use cases, Screens, Data Flow Diagrams, etc
Functional Prototype Interim release
Design Prototype Interim release
Tested system Interim release
Delivered system Final release
Implementation Strategy Implementation Plan
Development Risk Analysis Report Risk log
Review Records Record of user feedback on prototypes, i.e. interim releases
Test records
User documentation
Project Review Document

Scrum

Many people use Scrum (Schwaber & Beedle, 2002) in conjunction with XP, claiming this makes XP more scalable. The Scrum strategy for scaling is to have more Scrum teams – one team for each “application” and one team for the shared resources (sometimes called the Architecture team). Scrum of Scrums meetings provide inter-team communication. In fact Scrum claims to be infinitely scalable, but the examples from the book only mention 3 parallel application teams, and presumably a shared resource team, so in my opinion, Scrum is proven as a C5 to D32 method.

Conclusion

Basically a larger team needs more specialist roles and more documentation, even if they’re trying to be Agile.  DSDM already has those roles and deliverables as standard.   Crystal and XP add formality to the their default processes to cope with larger projects.  This also fits my experience of running large Agile projects.

Scrum differs by offering a light process for scaling up.  I haven’t tried it so I can’t comment on whether it would work.

References

Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

Beck, K, & Fowler, M. (2001). Planning Extreme Programming. Boston: Addison-Wesley.

Cockburn, A. (2002). Agile Software Development. Boston: Addison-Wesley.

The DSDM Consortium. (1997). Dynamic System Development Method [3rd ed.]. Tesseract Publishing.

Elssamadisy, A. (??). XP On A Large Project – A Developer’s View.  ThoughtWorks.  [Also on-line at http://www.xpuniverse.com/2001/pdfs/EP202.pdf]

McConnell, S. (1998). Software Project Survival Guide: How to be sure your first important project isn’t your last.  USA: Microsoft Press.

Schwaber, K., & Beddle, M. (2002). Agile Software Development with Scrum. NJ: Prentice Hall.

Leave a Reply

Your email address will not be published. Required fields are marked *