Several developers and I were recently added to a waterfall project. We were told that the project was almost done but needed a few extra coders to help finish it up (that's the first mistake). We were all assigned different modules to work on.

This phase of the project became more agile in that we were doing nightly builds and deployments to a test environment and the qa team was actively testing and reporting bugs. Occasionally our regression tests on the new modules would fail - stuff that used to work no longer worked. We discovered that there were design changes being made that only involved the developer working on the module and the architect and PM. The problem was that this affected the modules of other developers.

The developers got frustrated with one another, asking that they be informed of design changes, because it may have an impact on their work.

What is the best way to communicate design decisions that may be made in a hallway conversation or an email between a few parties. Should there be a formal process for handling design changes, even if they are extremely minor?


If you need to move quickly making changes that might affect others, then perhaps you can find a way to isolate others from your changes, such as with interfaces, facades, or adapters.

Other options include (1) learning how to make the corresponding changes that "the others" might need to make, and either sending them patches or making the changes for them, (2) notifying them before you commit your changes and asking "the others" for an emergency review, (3) inviting an "other" to work with you when you sense that your work will affect their module.

I imagine you could find other approaches, but each of these would work.

  • Since the deadlines are so tight, the team leads are not open to building in an extra cycle. So we're counting on the individual who makes the changes to also change the other modules that are affected. If there is any doubt, the developer will ask others for review before committing changes. – rycornell May 17 '11 at 19:27

I'd recommend building in an extra cycle

  • to review design changes,
  • integrate them into the source code repository (like SVN) and
  • resolve code conflicts

before moving ahead with other design or development changes.

This could be its own milestone (complete design) or built into every iteration.

  • +1 for recommending that design changes are reviewed. Discussions in a hallway or via emails may be valid as ways to consider future development opportunities, but should not be the basis for making design changes at any point in a project, and even more so towards the end of the development. Design changes carry a big risk, and therefore need proper governance. – Iain9688 May 15 '11 at 10:22

Document your design decisions by means of unit tests, and start using continuous integration. You won't need to talk about design any more - you will see it in action.


It may just be the way you've worded it, but I'd argue that the design changes aren't minor if they're breaking the modules of the other developers.

If you don't want to go completely formal and review every change beforehand, then your developers need to have enough knowledge of the overall design to assess the impact of any changes and involve the other teams as appropriate. You mention architects - they should be ideally placed to do this so why isn't that happening?

I'd also suggest some form of central change log (your SCM tool may give you this) so that if breaking changes do still occur, you've got more chance of understanding how they came about.

Finally, if there are few areas of the system that can be amended without affecting others then you might have a larger design issue.


I'm not an expert on Agile, but I see this as a communication problem that can apply to any methodology. Would it help for the teams to meet daily for a quick review of the changes before they start working. Then again at the end of the shift?

Your Answer

