After introducing you with the wonderful and talented people that form our team in my previous post, I would like to share with you a bit more about our day-to-day work and development practices and more particularly how we do Agile in a distributed team.
Agile in geographically distributed team – Can that work?
In fact, it does! It's not always optimal, and I'm not sure that's what people had in mind when Agile and SCRUM were first thought of, but we found our ways and tools to make it work for us. And we are not the only ones, in recent years I read more and more about teams and companies working with this kind of set ups, and I also start hearing more about it in conferences and trainings I attend.
So how does our sprint look like?
It's actually not very different from any other SCRUM team. After some trying and adjustments, we realized that a 2 week sprint is the right size for us.
Our sprints start on a Monday morning with a Sprint Planning meeting. I guess it might be hard to imagine a planning meeting where people are not in the same room, but we actually are. We all join in my virtual meeting room, where each of us can share his or her screen, talk and collaborate.
To make sure team members do not fall asleep, play computer games or pick their nose, I strongly encourage everyone to use their webcams. This helps ensuring that team members are attentive, involved in the call, and makes the atmosphere much more familiar and friendly. We can also see how jane did here hair that day and what T-Shirt oliver is wearing.
During the call michael, our Product Owner, introduces the tickets and stories he would like us to work on during the upcoming sprint. That's normally some cocktail between new user Stories to be developed, Bug fixes and some technical tasks.
The planning meeting normally follows a few grooming meetings, in which Michael discusses particular tickets with a smaller crowd of team members (experienced developers and/or Operations, UI or performance people whenever that's relevant), so the ticket should meet some standard of readiness to be included in the sprint. And not to forget that all user Stories we work on are extensively discussed and prioritized between Michael and our "Business" beforehand.
In the meeting itself, we discuss each ticket separately, giving the chance for each team member to ask questions and raise potential concerns. I don't like time boxing but always on the watch that discussion doesn't get too long, as we only have 2 hours to discuss all tickets for the 2 week sprint.
Another method we use during Planning meetings is estimations. But unlike other teams that use it to determine sprint capacity, we use estimations more as a basis for discussions between team members and making sure there are no big gaps in the way we understand tickets and what is required to complete them. For each story and for complicated tasks we run a cycle of planning poker, if we see the gaps between team members' estimations are too big – this definitely is a reason for concern and we then try to understand where these understanding gaps come from.
A great and free tool we use for estimations is www.planningpoker.com. They are now in Beta for their new UX, and we really enjoy using it. This also keeps all team members active during the call.
As we work very closely with our Product owner and enjoy great trust and support from him, we do not use story points to determine capacity for the sprint. We rely on our gut feeling to say stop when we feel we committed for enough for the sprint. We always know that if we have some more capacity later, there are some smaller tickets waiting for us.
In the next posts…
I will describe a bit more about how our sprints go, virtual daily meetings, how we use JIRA agile boards to manage our work and replace physical boards, how to do a virtual review meeting and keep your team from falling asleep and show you a great tool to hold virtual retrospective meetings.
- SAP Managed Tags:
2 Comments
