We can read and hear everywhere that “Scrum” and “Virtual” are two words that cannot fit in the same sentence, since the fundamental principle of scrum is to bring all team members in a single physical room.
I wanted to write this article in order to share with you the successful experience I had being the Scrum Master of a Virtual Scrum Team.
Context of my Scrum Team
I have been acting as Scrum Master in an IT Enterprise Analytics team for more than a year.
The mission of this team is to deliver end-to-end Analytical solutions for all lines of Business, based on a backlog primarily driven by the adoption of SAP HANA.
The Scrum team started with 1 Product Owner and 1 developer in Germany, 1 Scrum Master and 1 Developer in France, and 2 Developers in India.
We quickly faced some issues with involving the Indian colleagues in our Scrum Team, mainly due to the time zone difference, so they were then replaced by 2 colleagues in France.
Finally, we welcomed into the team 2 RUN responsible persons (Product Architects) in order to facilitate the solutions transition into the Support & Operation
The Scrum team set up is now the following:
Germany (all team members in the same location):
1 Product Owner
2 RUN responsible persons (Product Architects)
France (all team members in the same location):
1 Scrum Master
In total, we have 3 HR Line Managers.
Here are some rules of thumb I followed and highly recommend:
Clarify roles, mission and goals
Every team member needs to clearly understand his role, but also the role of the team. What is the team mission ? What are the goals ? What is my role ? How you I interact with the other team members ?
All those questions must be answered by the whole team together. It will be the starting point for a good collaboration and team cohesion.
Example of goals: Deliver the backlog items in most efficient manner, get the Business satisfied, deliver stable solutions, improve the team collaboration and skills continuously.
In order to formalize this, I think that it is good to organize at least one workshop per year with the whole scrum team in the same location.
The goal of this event is really to redefine the team goals and roles (by reviewing the team charter) and make sure everyone adheres to this vision, improve the team cohesion by having fun (by organizing some team building exercises -you can find lot of ideas here: http://tastycupcakes.org/) and also think how to improve the team collaboration and productivity (you can do an overall retrospective).
From my point of view, one of the most important things to care about is the team spirit.
Without strong team spirit, the team members won’t be happy and proud to be part of the project team. If they are not happy and proud, they won’t be motivated and they won’t collaborate and “play” correctly the Scrum “game”.
I think that the Scrum Master role is to do everything he can to improve continuously this team spirit. In my team I have put in place several tricks to do so.
Scrum meetings can last hours. That’s why I always present the meeting agenda to the team before starting a meeting. Especially the break time !
I also always bring sweets (candies or chocolates) during Sprint Review, Retrospective and Planning. It helps the team to keep focusing on the meeting and for sure it brings fun and favors team cohesion and open discussions.
I recommend to have a Scrum team with all members working in the same time zone and to dedicate budget to Business trips in order to meet face-to-face
I really think that travelling at least once a quarter is essential for the team spirit. Being in the same room from time to time helps the team members to identify themselves to the team, to remember why they are happy to work with those colleagues.
Each time the whole team is in the same location, we organize at least one visit/diner, and never in the same location. The goal is to share fun activities and get to personally know each other. In Paris, we did a boat tour and visited the Sacré Cœur for example. We then all go back to our daily work with lot of memories in our heads and the colleagues are no more only “colleagues”.
Team spirit is not only fun and team cohesion. It is also a way to think and to work.
The team members must be active, attentive in meetings and proactive in their daily work by volunteering for task assignment, for example, or by supporting other team members.
They must be supportive of each other by answering questions, helping unblock technical problems and taking over tasks, when possible, from overloaded
The Scrum Master role is to kindly push the team in this direction.
Example of team charter in attachment of this post.
Another key for success is Transparency.
To be able to work together, the team members must trust each other, and it starts with transparency within but also outside the Scrum team.
The team members must always be transparent by:
- Providing constructive feedback but also accepting other opinions and feedback
- Accepting and sharing open discussions
- Informing the team on availability (vacation, bank holidays, training, travel, other activities…)
- Reflecting any progress and changes in the product backlog (to also be transparent with stakeholders and with management)
One Scrum meeting is dedicated to transparency: the retrospective.
It is really important that every team member participates in this meeting and shares feedback. It is essential to improve collaboration as well as delivery quality and velocity.
In addition to this retrospective meeting, I organize a weekly coffee corner in each of the locations (one for the German colleagues and one for the French
colleagues) where we can have open discussions on any topic.
Following team spirit, team cohesion and transparency, team members must collaborate together to achieve the team goals.
The team must be flexible. To do so, the team should be cross-functional, meaning that each team member should be able to work on any backlog item – independently of the technology or the functional area.
At the beginning of the Scrum project it may be complicated, but one of the objectives of a Scrum team should be to become flexible.
The team members should constantly share their experience and their skills. They can, for example, establish a buddy concept where 2 team members are always working together, supporting each other and sharing their knowledge. Sprint after sprint, the team will become more and more flexible and autonomous.
Having a flexible team helps with:
- Having team members cross-skilled – everybody can understand and takeover all items
- Being able to implement all backlog items independently of the expert’s availability – because everybody is an expert.
- Having team members that are more active and participative in the Scrum meetings – they understand all topics and can easily take part in the discussions
Also to have more interactive meetings, it is always better to favor face-to-face or visio meetings. For example, during Sprint Planning, you can play Planning
Poker with real cards thanks to the Visio camera.
Integration of people responsible for Support & Operations in the Scrum team
Two people responsible for the coordination of Support are fully part of our Scrum Team. Within our team, we call them “Product Architects”.
They are the Single Points of Contact from the Support organization in the Scrum team. The Product Architects are managing their Support teams in parallel of being part of the Scrum Team. They are involved in the solutions deliveries from the beginning by taking part in the requirements and design discussions. They proactively organize the handover to Support and help with the delivery process. They attend all Scrum meetings in order to always be aware of the ongoing activities and open issues.
I have centralized in this section all the tools we are using within my Scrum team to improve our collaboration and the quality and velocity of our deliveries.
If you want to work as a team and to be transparent, the first thing to set up is a shared folder.
You will store in this folder all documents related to your scrum team and to the backlog items.
To share the product backlog but also the sprint backlog with the team and with the stakeholder or management, we use the JIRA Agile tool.
In my scrum team, we use to create backlog items not only for implementation but also for everything that needs to be delivered or done with the implementation (documentation, testing, Delivery process)
This tool is the single point of truth of the team. Each team member refers to this backlog to know what needs to be done next according to priorities.
It is really useful to :
- create the product backlog
- create dependencies between the backlog items
- create the sprint backlog
- for each backlog item, define the acceptance criteria, define the assignees, define the story points estimation
- follow up on the burndown chart during the course of the sprints
- for each sprint, define the tasks, estimation and assignees
Before each sprint planning, each developer has to fill the Capacity Plan excel sheet.
It is a table where we calculate the total capacity for the incoming sprint. It allows us to plan the sprint and assign tasks accordingly.
This file also allows us to track the team velocity (number of story points done according to the capacity)
During the Sprint Planning, Sprint Review and Retrospective meetings, we use Visio rooms to have more interactive meetings. We can see each other and play real planning poker cards.
All team members can close their computers except the Scrum Master who is sharing his screen and leading the meeting. It prevents parallel work activities like emails,… and keeps the team members focused on the discussions.
In the other Scrum meetings, we usually use a conference room tool such as Adobe connect or Microsoft Lync where we can do our conference call and share our computer screens easily.
Backlog items template
In our backlog, we often use some standard items such as testing or documentation.
In order to not spend too much time reviewing acceptance criteria for those items, we have created an Excel file where we store backlog item templates : default lists of items to deliver an end-to-end solution with default title, acceptance criteria and, when possible, story points estimation.
In order to estimate the backlog items story points in virtual mode, we use a very good tool which is very simple to use – http://www.planningpoker.com/.
The Scrum Master can create an account on this website for the team and create “games”. The developers can then connect to the games and estimate online.