The authors’ claims aren’t plucked entirely from thin air. Rosenberg and Boehm have run a small number of software projects programmed by university students using this approach, and they consider these projects successes. Student projects notoriously have 100 % staff turnover every semester, and students may not be very experienced programmers; this lends their story credibility. In their professional past, they have also run other large projects along similar principles, with good results. Unfortunately, this is also about where the evidence stops.

Let’s go into what the Parallel Agile approach builds on, and why the authors think it works.

It’s easy to speed up a software project2² In the litterature known as compressing the schedule. by adding more programmers to it: all one has to do is decompose the system into more independent parts, and assign one part to each programmer. Done. This has been known at least since the 1950’s, and is not new.

But that’s also not the difficult bit. What’s difficult is decomposing the system into that many independent parts, and then integrating all parts together into a unified whole. I have written before about why I think it’s better to decompose into fewer parts, rather than more parts. The authors of Parallel Agile think there are two keys to solving this decomposition problem.

Before any programmers are assigned work,

1. Design a relatively complete domain model3³ A domain model is, loosely speaking, the universe defined by the software, the names of all objects that it’s going to have.; and
2. Write down a relatively complete set of use cases4⁴ A use case is essentially a small feature slice..

Then give every programmer one use case each, and tell them to only integrate through the domain model (i.e. effectively instruct them not to talk to each other too much, and just trust the integrity of the domain model). If done properly, this really should work, because each use case is somewhat independent of the others, and technically it is possible to integrate everything via the domain model – and it would yield very decoupled code, to boot.

This is where I sense one of the potential flaws of the idea. The code might turn out to be excessively decoupled; things that should share code and/or data will be developed completely independently. This means duplicated effort during initial development, and if the duplication is not reconciled during integration5⁵ Which it sort of cannot be because then Amdahl’s law will constrain the scalability promises of Parallel Agile., then this cost becomes interest paid on technical debt with continued development. In some cases6⁶ A very tight deadline with fierce financial penalty, for example, or a classful of cheap student programmers to throw at the problem. that tradeoff might be worth it. I’m not sure it saves money in the long run for most projects.

Note that not even the authors imagine that they can design a complete domain model up front, but they believe that with very little effort, it’s possible to get, say, 80 % of the way there. The remaining 20 %, they seem to imply is likely to be mainly about private attributes and things that are relevant for specific use cases only, so they can be filled in by the programmers as they go about their day.

Similarly, the authors admit that some uses cases may be discovered only once programming has started. The nature of task assignment (one use case per programmer) naturally means some programmers will finish their tasks early – these will be the reserve force that handles newly discovered use cases as they come up. That part sounds sensible.

The authors say there are three phases to a Parallel Agile project:

1. Proof of concept: prototype-driven requirements discovery
2. Minimum viable product (mvp): Model-driven design
3. Optimisation: Acceptance-test driven release strategy

Nice picture, but not how it appears to have worked for basically any of the actual projects presented in the book. There seems to be little qualitatively different between these phases, which is also admitted by the authors when they say that “part of the goal of this phase was carrying over and completing unfinished work from the last phase.”

Another problem with the three-phase picture is that it makes the common, but incorrect assumption that programmers develop software until it is finished, and then they switch over to maintaining it. In my experience, software is not an event that happens and then it’s over – it’s a continuous process. It’s impossible to divide a continuous process into three distinct stages, especially up front. (And indeed, at least one of the authors’ own projects seem to be progressing into a fourth phase with continued development. I suspect there will be a fifth, and a sixth, and so on, until the project is abandoned.)

At some points the authors even call these phases sprints, and that was when the penny dropped for me. That’s what they are. They are fixed-time7⁷ Due to the inflexible length of university semesters. iterations, not phases.

However, it seems to me there are two separate phases. But we can call the first phase the zeroth phase since the authors don’t admit it as a real phase of development.

The authors mention in one or two situations when they were faced with technical decisions of high uncertainty that they evaluated multiple approaches. However, it sounds like they evaluated these approaches sequentially, i.e. tried the most promising first, and then if it failed to pan out tried the second one.

Essentially, Parallel Agile is a way to run a project at huge cost (many salaries to pay), in exchange for some certainty that the project will be finished to a tight deadline.

There could be another way to use the ideas of Parallel Agile, and I’m not sure if the authors have discarded that idea, or simply not thought about it. Instead of starting from 40 use cases where one thinks all 40 will make it into the final product, assigning one use case to each programmer, one could start from a smaller core of 20 use cases, and then on average try two variants of each – still all in parallel.

That way, we would still be effectively implementing 40 use cases, only some of those use cases would implement similar functionality from a user perspective, only taking different approaches. We will get fewer features in, but on the other hand, we will have a greater probability of having each functionality work10¹⁰ If there’s only a 70 % probability that any particular approach to a feature works, and we try four different ways, then there’s a 99 % probability at least one them works. This is essentially the promise of set-based concurrent development, which I’d like to understand better.. Since we focus on a smaller core of use cases, there will also be a lower effort required to integrate them.

Exploring multiple alternatives to the same thing in parallel is guaranteed to result in work that needs to be thrown away (to the horror of managers all around), but it is more likely to result in a successful product. It is a way to scale up effort, not to speed up implementation, but to speed up requirement discovery and thus reduce risk quicker.

In the part of the industry where I’m from, it should be more important to pay to reduce risk than to speed up implementation. But then again, that’s still a harder pill to swallow for management types.

I realise this review may sound harsh and that’s not really my intention. When the authors say they are astonished by the results they’ve had, I trust them. I’m genuinely glad they’re sharing their discoveries. The book has given me a lot of good ideas for how I can improve my processes. But I’m also sensing inconsistencies in how they present their approach, and quite a lot of arguments against the straw man version of alternative approaches.11¹¹ Things like “timeboxing is bad because people mistake timeboxes for tight deadlines” or “unit testing is bad because people focus too much on statement coverage”. Yes but no. I don’t think the authors do this by mistake, I think they are trying to correct common misconceptions but for someone like me who does not share those misconceptions it comes off as disingenious. That unnecessarily clutters the authors’ main points.

My main takeaway from the book is perhaps not that there is a magic wand to make nine women produce a baby in a month (there may or may not be), but rather that the authors very successfully reinforce the importance of developing a domain model, and then being insistent that most integration should go through it. I believe that is helpful advice regardless of whether you use Parallel Agile or not.

However, I’m also not willing to write off the idea entirely. Here’s what I want to try in a personal project, if I stumble over one that seems well suited to it:

1. Start by modeling the domain and use cases that woud be present in an initial version.
2. Stub out storage and api code for domain objects.
3. Develop incrementally:
   • Work strictly on one use case at a time, filling in the storage and api code as necessary. Create the use case as an independent deployment unit.12¹² Possibly also try spending more time diagramming than I usually do before hitting the keyboard.
   • In parallel with the above, develop automated acceptance tests.
4. Integrate the independent use cases with each other.

This is, if I’ve understood it correctly, the core of Parallel Agile and if it works well for 30 developers in parallel, then it ought to work well also just for the one developer doing 30 things in sequence. Modus tollens, if it doesn’t work sequentially, then there is no way it could work in parallel.

• Getting Used to Microservices