The discussion of simultaneous phases in The Art of Agile Development's "Understanding XP" chapter was originally planned to be a practice in Part II's "Planning" chapter. As the book evolved, we realized that the idea of simultaneous phases was so foundational that it needed to be introduced at the beginning of the book, so we moved it forward.
As a practice, "Simultaneous Phases" had all the accoutrements of other practices: FAQs, contraindications, and so forth. None of that was appropriate for an introductory chapter, so we deleted it. We were able to save the "Alternatives" subsection for the Adopting XP chapter (it became "Applying XP in a Phase-Based Organization"), but the rest got axed.
With version control, however, nothing ever really dies. Here's the material that got cut.
Simultaneous phases sounds very chaotic. How do we keep track of what we're doing?
- Iterations, §X.Y
Although you won't be working in phases, you will work in week-long iterations. These provide structure to your work... more structure, in fact, than a typical phase-based project. Within that structure, you will have more freedom than normal, too, allowing you to choose any activity that will best help the team make progress.
During each iteration, focus on finishing stories rather than finishing phase-based tasks. As a team, figure out what you need to do in order to finish the iteration's stories and allocate the work accordingly.
To help with this process, you will create an iteration plan at the beginning of each iteration. See section X.Y, "Iteration Planning".
Which is more efficient, phase-based development or simultaneous phases?
I'm not aware of any research on this subject. Based on my experience with both approaches, I suspect simultaneous phases are more efficient. Simultaneous phases with short iterations allow the team to focus on delivering results. It leads to a rapid feedback cycle, which allows the team to fix mistakes and take advantage of opportunities quickly.
Although working in phases allows the team to focus on just one activity at a time, this has the side effect of removing the team's focus on the results they are delivering. Slow feedback causes mistakes to compound, increasing their cost to fix. These expenses seem to outweigh the benefits of working on one activity at a time.
Without phase-based deliverables, how do stakeholders know that the team is doing their work properly?
- Iteration Demo, §X.Y
The team demonstrates their progress every week during the iteration demo. See section X.Y, "Reporting" for more ways to demonstrate progress and section X.Y, "Trust" for ways to improve stakeholders' trust in the team.
When you work well in simultaneous phases, team members fluidly switch between requirements analysis, design, coding, and testing as the situation requires. Every iteration, you start and finish a completely new set of stories. You recognize potential challenges and opportunities quicky and can adapt and change the plan as necessary.
- Whole Team, §X.Y
- Sit Together, §X.Y
Simultaneous phases depend on a whole team that sits together. Without these two practices, your team will have difficulty getting information quickly enough to successfully deliver software every week.
Specifically, a team without an on-site product manager will likely have difficulty release planning. Without on-site customers, you will probably have difficulty understanding requirements. Without skilled designers and architects among the programmers, you will have trouble producing a workable design. Without integrated testers, you are likely to overlook certain types of errors.
See section X.Y, "Alternatives In Whole Team" and section X.Y, "Alternatives In Sit Together" if your team sits apart or is missing people.
- Iterations, §X.Y
- Release Planning, §X.Y
Simultaneous phases also require iterations and a release plan to provide structure and oversight. Be cautious of using simultaneous phases without them.