3

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?

Improve this question

5 Answers 5

Reset to default
4

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.

Improve this answer
1
  • 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, 2011 at 19:27
2

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.

Improve this answer
1
  • +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, 2011 at 10:22
2

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.

Improve this answer
0

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.

Improve this answer
0

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?

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.