When we think of the agile software development method Scrum, we think of a fast-paced process that includes working on multiple phases at the same time with a small team completing a software tool over multiple “sprints.” These sprints last one to four weeks and are dependent on the daily communication between the team members for success. The communication is supposed to be quick and should identify daily accomplishments and tasks ahead. The longer communication occurs at the beginning and end of each sprint, in which the team plans the contents of each sprint and in the end evaluates its performance to implement lessons learned and improvements. While this methodology can be successful within teams working at the same location or working in different locations, there is a limitation to how far apart the teams can be for this to work successfully.
For example, if the development and testing teams are in a different location than the analyst who clarifies and communicates requirements (in the form of user stories), chances are higher that details will be missed over audio and web conferencing. If the time difference between the two locations does not allow team members to work at the same time, answers and issue resolutions can be delayed by a full day. On top of that, if the analyst is working physically apart from the business stakeholders and the development and testing teams, communicating the small intricacies of what makes an online tool very user-friendly versus a complete eye sore can become even more difficult.
Traditionally, agile methodology works best when the team is small, five to six people, and there is one stakeholder representative who is the communication bridge between the IT team and the business stakeholders. If that bridge is missing or does not have the necessary information to translate business requirements into system requirements, almost everything has the potential to get lost in translation. Furthermore, most often teams utilizing agile methodology experience the “too many hands in the pot” syndrome, in which the business stakeholders want to conduct user acceptance testing after each sprint and provide feedback. There are more cons than pros to this approach.
The whole point of having a sprint is to build a piece of the puzzle until we have solved the entire puzzle over a few sprints. Testing piecemeal functionality results in the following:
Stakeholder: “I did not see [particular functionality] in the tool.”
IT Analyst/Lead: “This is not part of this sprint, as you can see in the list in front of you. This was shared with you at the beginning of the sprint.”
Stakeholder: “Oh, right. I forgot. Then what about [another functionality]? I thought that was part of this sprint.”
IT Analyst/Lead: “No, as you can see in the list, this functionality is part of the next sprint.”
A business stakeholder will always look at the entire puzzle instead of a piece by piece snapshot, because business stakeholders manage entire processes, not one piece of a process. Therefore, not understanding this basic piece of human behavior can lead to a large amount of time wasted, yes, wasted, on answering questions that end up being asked at the entirely wrong times.
