Globally Distributed Agile Development

To avoid unnecessary delays, Jessica must fill in as many details as possible, make sure stakeholders approve of those details, and then go back-and-forth with the development teams (probably via email or phone conversation) to fill in any gaps. The more details she can add, the better. Things like GUI mockups, pictures, and acceptance criteria tend to go a long way in a situation like this.

Short user stories work because they are supplemented by face-to-face conversations. If these conversations are no longer going to be taking place, we need to add more detail to our specifications and task descriptions. Additionally, it’s important to use a system that ensures linking and enforcing a proper workflow as specifications are turned into development tasks that are eventually tested. This can be extremely useful in ensuring that miscommunications do not lead to work having to constantly be redone. It’s also very important because few things will demoralize a team faster than constantly redoing the same work.

Conway's Law states that any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway's law is based on the observation that in order for two separate software modules to interface correctly, the designers and implementers of each module must communicate with each other. Thus, the interface structure of a software system will reflect the social structure of the organization that produced it. In the case of an organization with distributed teams, work will naturally be divided up according to the distribution of its developers. Doing so results in an architecture that reflects the distribution or has artifacts that specially accommodate the distribution. Even if this design is not the best from a performance and scalability perspective, it is often then most convenient.

Regarding Jessica, let’s assume that all the requirements and specifications for the email feature have been approved and delivered to the development teams. The original story has now been broken up into three separate user stories that will be developed simultaneously to save time. The Fiji team will develop according to this user story: “As a maker of toast, I want the ability to configure SMTP settings on my toaster.” On the other hand, the Madagascar team will develop according to a different user story that states this: “As a maker of toast I want the ability to configure email groups based on the type of bread toasted.” Finally, the Uzbekistan team will develop based on this user story: “As a toaster I want to send a message to trigger an email when the bread is done toasting.”

Although each team develops its feature as specified in the respective user story, when it comes time to put all the pieces together, we find a problem. Uzbekistan has only coded one message for when the bread is done toasting, but Madagascar was expecting different messages specifying the type of bread. This, of course, leads to delays while the message details are sorted out by both teams. These delays are exacerbated by time zone differences and the fact that each team is unfamiliar with any other teams’ code. Many of these problems could have been avoided if the teams had created stories based on vertical slices through the architecture or if they had considered all the user stories as opposed to just focusing on those assigned to them.