As we discussed in the reading, the socio-technical theory of coordination suggests that the best process is the one that designs your communication and coordination around the technical dependencies in your architecture. Now that you're close to having your architectural specification done, try to determine which components depend on each other to decide:
To represent your decisions, write these decisions for each component like the example below:
Jane's going to build the WidgetFactory. It depends pretty heavily on the existence of WidgetA and WidgetB, which Joe is building, so Jane will have to nag Joe about his progress, or devise some way to stub both widgets. Joe's committed to having the widget interfaces done by April 4th, so Jane isn't blocked.
This should tell you who has to coordinate with who. Now, estimate how long it's going to take to build each of those components. What do these estimates mean for the order you should build your components in? Generate a schedule for when you're going to build each component by, like this:
To relax these constraints, you can always "stub" functionality (e.g., write a function with a hard coded return value so you can call it, but implement the function later).
This work will be just part of your next homework assignment.