Lessons Learned with a Global Team using Agile
A global, multi-vendor project using the agile methodology – 6 different teams in 4 different time zones – and though there were many opportunities for the process to falter, it ended up being one of the most inspiring, collaborative and successful projects I’ve been a part of. It was successful not in that it was perfectly planned and executed but that we adapted quickly when issues surfaced.
We were fortunate enough to have everyone not only self-motivated and strong but also eager and excited to deliver solid work. We had two week sprints so there wasn’t time to waver in implementation. Agile can easily promote an intense work environment but when managed smartly and adaptively, it produces impressive results and a motivating work environment.
It was important to accept that not everything within the methodology would work successfully on the project (as any project with agile). Throughout the process challenges arose in communication, collaboration, team morale, and integration. Acknowledging the issues and responding quickly contributed significantly to the success of the project.
Here are some of the key lessons learned:
1. It is crucial for EVERYONE to believe in the process and the ultimate goal of the project. Because of the collaborative environment and the quick turnarounds that agile requires, if a teammate is not pulling his/her weight or is sending negative vibes, this will break many things: communication, delivery, morale, etc.
2. The project management tool used for planning is the heart of the project. Every person on each team has to actively use the tool and be completely comfortable with it.
3. Establish the effective amount of communication without too many all-hands meetings. Easier said than done but efficiency and morale are at stake when someone is asking “Why do I have to keep talking about what I’m going to do?“
4. During each sprint planning meeting, it is essential to reiterate the overall goal of the project / phase before assigning user stories to the sprint.
5. Documenting and conversing within each user story, task and bug clearly defines the events and decisions that take place throughout the process.
6. Define success metrics within each user story. This proved to decrease time spent in integrations, QA, delivery and acceptance
7. Distribute and explicitly outline responsibility. With so many working pieces and moving parts no time should be wasted in figuring out who owns what.
8. Unit testing and automated processes may take initial setup time within a sprint but it is time well spent to say the very least.