Are you thinking of adopting the Agile process in your next project ? If so you are in the right place. There are quite few challenges for the team in order to adopt to Agile especially if the team is globally distributed. For instance, having an effective sprint iteration review or planning meeting, pair programming. Agile is originally meant for small teams with face to face interactions. However large distributed teams have started adopting Agile due to its promising results. Here we can discuss some of the challenges that the team may face and how to resolve them effectively. The readers of this post are expected to know the jargon of Scrum Agile.
In case the team is novice to distributed agile , it would be best to start with a Agile pilot project. Choose an appropriate project to pilot scrum where you can demo the achieved functionality to the management. Typically it could be a new product feature or an extension to an existing feature. The project size should be small. Few dependencies with other teams will ensure less complexities during the scrum iteration. There should be coherence among team members and its very important for the whole team to participate in daily stand up meetings. The stand up meeting time shouldn't exceed for more than 15 mins and mainly be utilized for the team to express any blocking issues so scrum master or other team members can address the issue with a follow up call. Once the pilot project gets kicked off , the next step is how we track the teams progress ? Perhaps since its a pilot project there is no tracking tool yet that the company adopted. You could use a simple excel with format backlog story, original estimate, estimate spent, estimate left and status. The team should regularly update this excel. Product manager can then extract the burn down chart from the excel data to monitor team progress rate and could use to extrapolate the final finish time for the Pilot project.
Now that we have successfully completed the pilot project, we will address the real challenges in a massive project with teams distributed across different time zones. , missing scrum masters or product owners in a particular timezone team. The below principles can mitigate some of the challenges.
1) Form different scrum teams
Each team owning a product feature. A product feature could be comprised of multiple backlog stories. Several factors should be accounted for during scrum team formation. The successful formula should be location, location.. Ideally an individual scrum team members should be located in the same office. Typically not the case in every project out there. At least try not to mix up the members in all different time zones. Its less complicated with almost 2 to 3 different time zones. If possible, distribute independent product features among scrum teams.
2) Scrum master in each time zone
If a scrum team size is huge has members with 2 different timezones then there will be a main scrum master and a proxy scrum master for that team. Schedule 2 different daily stand up meetings in each time zone. Main scrum master should participate in both stand up meetings. Same principle can be applied to product owner if needed.
3) Scrum masters meeting with the product management
Regular meeting between all scrum teams masters and product management after each iteration. This is to track each teams progress and discuss about the backlog stories priority. Product owner and scrum master from each team will present their teams progress, stories attempted and the burn down chart.
4) Scrum review meetings
At the end of each iteration the each scrum team schedules a review meeting. The scrum master should make sure the dependent scrum teams attend these review meetings. for e.g to schedule which backlog stories that team will uptake for the next iteration.
5) Track scrum progress
The team progress should help the management to extrapolate to see if we can meet the deadline.
No comments:
Post a Comment