Sometimes you have to feel pain to learn a lesson. This is true in life, love, and software development. When a team is new to agile development after years of waterfall development, sometimes people dogmatically adhere to the agile manifesto without adapting to unique organizational circumstances. I recently experienced this first-hand on my own project, and it was painful.
For sprint 1, we played fast and loose with our requirements. We wrote higher-level user stories with little in the way of documentation. This works just fine when you have a close-knit team that is collocated. It just so happened that three continents and multiple time zones separated our project team.
We shared user stories for sprint 1 with the developers. The developers created the software. During testing, we realized that there had been a massive gap in the understanding of the requirements between our BAs and our developers. What was missing during Sprint 1 of our project was a central tenant of user stories themselves—conversation.
How could we fully talk through every user story with a team that was on the other side of the world? Our team only has a 2-hour window every morning when both teams are available during working hours. The answer to our Agile woes turned out to be something we are quite familiar with at ArgonDigital—models.
In that 2-hour communication window, visual models provided enough context and clarity for our development team to grasp the user stories and ask questions. Process flows and a rigorously maintained data dictionary helped bridge the disconnect of multiple time zones and thousands of miles.
