Parallel Agile (PA) is a simple but highly effective way to organize large projects so that teams can more easily deliver software in parallel. Its goal is to reduce the cost of communication between teams so that projects can scale out efficiently.

PA combines these key ingredients:

• microservice architecture
• an adapted and updated version of the Spiral Model
• advanced code automation in the form of a domain-driven code generator

The spiral model (full name Incremental Commitment Spiral Model, or ICSM) has its roots in large, million+ lines of code development efforts. It emphasizes iterative, feedback driven, risk minimized development through short cycles (we could almost call them sprints!)

We won’t dwell here on the details of the ICSM, but instead we’ll jump straight to PA’s simplified spiral model:

We’ve found 1 month per phase works well: it allows developers to focus on the job at hand without the distraction of too much agile ceremony. With a large team of developers working in parallel, this means you can deliver a large-scale project in 3 months.

Proof of Concept Phase

The first phase starts with a domain modeling workshop with the stakeholders — a few hours is usually plenty. Your team creates a prototype from this domain model. The “magic sauce” here is that you can automatically create an initial, baseline version of the prototype in a matter of seconds — so you’re prototyping against a live database and API.

For the majority of the phase you’ll be enhancing the prototype and gaining early feedback from the stakeholders. Because the API is generated, the team can focus on the UI and the data model to get it all just right.

The first phase is also a time of requirements discovery — identifying user stories and breaking them down into use cases.

The domain model serves as a “software backplane” that all of the use cases can plug into as they are being independently developed.

MVP Phase

The second phase is “design and build time”, where:

• The developers implement the code and unit tests for each use case, focusing particularly on edge cases — “unhappy paths”
• The testers write acceptance test scripts
• The stakeholders provide feedback on early builds

Optimization Phase

Because the project’s been given such a healthy start, with everyone knowing precisely what they need to do, the completed MVP should be pretty close to the finished product. However, the third phase — optimization — makes absolutely sure.

The software testers get testing, the stakeholders put the software through its paces, while the developers fix bugs and refactor where needed.

Here’s the twist: Do all of that… in parallel

To enable developers to work in parallel, your team applies the spiral model on a per use-case basis. Each developer is allocated one use case which they implement end-to-end.

In other words:

Where specialised skills or experience are needed, developers can organise into short-lived “strike teams” (or long-lived feature teams) — e.g. a React UI developer teams up with a big data expert and a server-side engineer to deliver a single use case together.

To further enable parallel development, organize the domain model logically into microservices, each with a set of consumer-driven contract tests to ensure service A remains in sync with, say, the message output schema from service B.

Organized in this way, teams can create and deploy individually without tripping over each other… meaning you can scale out by adding more developers to work in parallel. This is achieved with very little friction which would otherwise have slowed the teams down.

In short, Parallel Agile unleashes the “people power” of large teams to get things done faster than small teams can. Give it a try!

PA now has its own book, available from February: Parallel Agile – faster delivery, fewer defects, lower cost by Doug Rosenberg, Barry Boehm, Chuck Suscheck and Matt Stephens (that’s me).