The first part of a small series as mentioned in A pre-amble to the basics of Scrum, this post is focused on the scrum roles and how we see them fit into the Visual Studio ALM Rangers world of projects.
IMPORTANT POINT: It is important to emphasize that the intent of these posts are to share my understanding of Scrum, my initial thoughts on the distributed Rangers environment and the use of Scrum, and to discuss the content to be in a position to formulate a Scrum-based framework which will add benefits in our distributed, virtual and usually part-time Rangers projects that warrants the cost. Your candid feedback is therefore appreciated, either by adding a comment or sending me an email
Basics – Scrum Roles
A scrum team consists of a Scrum Master, a Product Owner and team members who are committed to the project. All other stakeholders, such as customers and management are involved, but only collaborate with the product owner and scrum master.
The scrum master works with all stakeholders, primarily the product owner and the team, to ensure that the Scrum values, practices and rules are understood and adhered to. In addition the scrum master assists with the removal of obstacles and impediments that may impact the team, without getting involved in the actual management of the team.
- The scrum master cannot be the product owner.
- The scrum master can, but should not be a team member, as this can introduce conflict in terms of impediment and task decisions.
Although the role does not officially include dragging in tons of coffee and pizza when night shift are needed, or monitoring power generators when final test runs are impacted due to power failures and simply sitting with the team when an extra pair of critical eyeballs are needed, I strongly believe that these small contributions fall under impediment resolution category and the team-morale-impediment sub-category.
The product owner the (only) owner of the product backlog, the prioritization of backlog items, the guardian of the value and quality of the team work and the interface to the outside-of-the-team stakeholders, such as management and committees.
- The product owner should not be the scrum master.
- The product owner can, but should not be a team member, as this can introduce conflict in terms of product backlog prioritization and decisions.
The team are a group of five to nine (that’s number of members, not the time of day they work) cross-functional and self-organizing members take ownership and therefore the responsibility of product backlog items during sprints. Collaboration, cross-training and skills-exchange are some of the key attributes of scrum teams.
As I always say to my three sons … the team (the boys) achieve or fail as one … there is no space for titles or me-myself-and-I attitudes in scrum teams.
If we now list the common roles you may encounter when working Rangers projects, the task of finding the right overlap seems daunting. Here is a list of typical roles and descriptions:
Development Lead (Dev Lead)
Leader of a feature team, who understands specific technical areas and has an ability to convey that understanding through project management and contributions to product strategy.
Product managers (PM)
Leader who provides strategic, programmatic and marketing leadership.
Product unit managers (PUM)
Leader who oversees a product unit or group.
Technical expert, who has a broad and deep understanding of technical areas and an ability to collaborate with the product team and the customer.
Highlighting the key roles on the Visual Studio ALM Rangers Projects Scrum Guide quick reference poster:
The following map shows the key areas on the poster that are focused on the roles. Note that this blog is based on the poster dated 24-April-2010.
The quick reference poster …
- … has an area where the team can write the product owners name.
- … has an area where the team can write the scrum masters name.
- … emphasizes the fact that the product owner owns product backlog and prioritization thereof. It also shows that we should have teams sized 5-9 individuals.
Some initial thoughts on roles and teams within Rangers projects
- Scrum Master … the scrum master should be a certified scrum master, not overlap with product owner and not be part of a scrum team under the watchful eye of the scrum master. As shown in the illustration on the right, the scrum master can be a team member of a team that is assigned to another scrum master. This is to ensure that there are no conflicts of interest in terms of the handling of impediments and product backlog task decisions. Being a Core Ranger would also ensure that the scrum master is aware of the Rangers environment and a track record with management and the product owner(s).
- Product Owner … the product owner could be one of the product managers or product unit managers, however, the obvious choice is for the Rangers lead to assume this role as the lead has the necessary experience and links into the product and services groups.
- Team Members … nothing new here. The team members are extended Rangers from services or the product group, or external Rangers from the MVP or other technical communities.
Team Size and Structure
The greatest challenge is the nature of Rangers projects and teams. Some of the key attributes are:
- Team members are distributed across the globe, limiting face-face collaboration
- Team members are scattered through most, if not all, time-zones, limiting the feasibility of one consolidated team scrum meeting. Staying up until the early hours of the night to attend a 15min standing scrum meeting is not on anyone’s wish list.
- Team members are usually participating on a part-time basis, ranging from a few hours per month to a few hours per week. This impacts the bandwidth and the velocity of the team and complicates planning.
- Team members are often contributing to projects on a variable voluntary basis, which makes it difficult to determine the true team bandwidth and velocity over time.
To ensure that we have optimal collaboration and participation in scrum meetings and other team discussions, it is important to slice up our planet into three of four time-zone areas. Each slice will have one scrum team, optimally focusing on one feature … F/R-T = Feature – Regional Team. In terms of the scrum master we can opt for regional scrum masters or alternatively with a scrum master who is happy to run a scrum in the morning, one in the evening and one in the middle of the night if we have three regions. In case of the former, we will need to have a Scrum-of-Scrums (SoS) where all the scrum masters have a scrum meeting to consolidate the feedback and impediments.
- Region 1: UTC-8 (Los Angeles) – UTC-0 (London)
- Region 2: UTC-0 (London) – UTC+8 (Perth)
- Region 3: UTC+8 (Perth) – UTC-8 (Los Angeles)
In other words if we have two scrum teams working in two separate time zone regions and each focusing on a different feature, we could represent the team scrum collaboration map as:
What do you think?
Next up …
- Part 2: What are the scrum time boxes and will we use them our the distributed, virtual and part-time world?
- Part 3: What are the scrum artefacts and how will the Rangers use them?