Coaching as a Scrum Master never ends, even for more tenured teams!
Been dealing with a couple of hiccups lately at work, and one in particular was a bit of coaching towards a member of one of the development teams. Probably just writing this up so I can get most of how I feel out of my system!
Anyway, so the discussion went as follows (not verbatim, btw):
Dev: When we go to planning, we as a team declare our availability during a sprint to set out a goal to do X amount of story points in velocity, but when we are done committing items for the sprint we also balance out the work across team members based on our collective velocity, that's not necessarily fair for the dev who will have time away during the sprint to be given an equal amount of load as those who are at fuller capacity.
Me: Our sprint goals have never been aimed at finishing X amount of work every sprint. Sprint goals have always been about a product functionality that the PO wants the team to bring into a potentially shippable increment. At the same time there's no written rule that only one developer should be responsible for finishing the user stories "assigned" to him.
The last point was to emphasize the definition of the Development Team as per the Scrum Guide.
*enter a bit more debate on the "velocity" and the "sprint goal" piece*
Dev: True, there is no written rule that restricts dev team members from picking up other people's work but the team is made up of individuals who have their specialties and there is undue pressure for them to finish.
Me: *insert emphasis on definition of Development Team*, furthermore we are not penalizing the team member or the team if the person does not get to work on certain sprint items if other more priority or sprint goal items take longer or take precedence. Again, the team works together (and by team I also include the PO) to meet the sprint goal.
I always tell the team that when we used sprint metrics, it's meant to visually inform the team of how they are doing and how they can make adjustments toward meeting sprint goals, and that the completion rate (velocity) provides the PO confidence that what they sought out for the team as Sprint Goals can be done within that velocity.
Anybody had a similar experience coaching the team with things like these?
A few things to consider.
It seems like there is a lot of specialization on the team. Scrum Teams work best when they are cross-functional. Is the team aware that the lack of cross-training and cross-functionality causing some of this friction in planning and Sprint execution? What are you doing to promote cross-training the different team members, both within the team and to the broader organization? I think it's important to recognize that two people will never be interchangeable, but it seems like particular people do particular types of work.
How are you choosing what goes into a Sprint? There is a set of functionality that is desired by the Product Owner, but how involved is the team in looking at the work and determining if the desired functionality and the achievable functionality are in alignment? Is the team considering not only the priority and estimates of the work, but also the availability of team members, the skills of those team members, and the workload when deciding what other things could be brought into the Sprint?
Have you or the team brought up the assignment of work and how that doesn't fit into a pull model? Since specialization appears to be a problem, has anyone brought up an experiment of pairing or mobbing? Although it means less work gets done (for a little while, anyway, as people use pairing or mobbing as a teaching tool), it has an advantage of being able to increase long-term throughput of the team.
Hi Thomas, thanks for sharing your inputs.
We actually have most of these in place - the development teams have knowledge on the core modules and functionality. At the same time, we do have a RACI matrix in place to cater to each member's team specialization with the caveat that there is knowledge transfer - there have been cases where we have reviewed the existing matrix and made changes so that other team members could also get training and experience in other modules.
In general, the development team is very involved with the PO's in determining the ask and the expected outcome of functionality, and are very eager to share these discussions at a high-level with the development team during the daily scrums. The team's very collaborative and often quick to adjust, which is good, and are always open to pair programming and being able to review often, especially if functionality has a larger set of code that could affect the system.
All in all, I'm pretty happy with how self-organizing the team has become, and that they really care to champion the process. I guess looking back at the conversation, the developer's concern was on their perception of "assignment" and the what they felt was the underlying sense of pressure to deliver something alone with no coaching and no safety net in instances where there is limited capacity. I've often assured him that we need to step back and see that the team works in a collaborative environment and work together towards sprint goals. This dev's pretty sharp, I just find myself often coaching him to work/embrace the pillars of the Scrum framework.
What visibility have you put in place over bottlenecks and other forms of waste caused by these work silos? Establishing transparency over the problem is instrumental when coaching, since it moves the advice you give from the abstract to the concrete.
Hi Ian,
I recently (as an ask by the team from 2 retrospectives ago) initiated a mid-sprint review so that the team can see:
- Item statuses
- Running count of team's velocity
- Charts (cumulative flow and burnup)
From there, I asked the team how they feel about they are doing to meet the sprint goal and pose questions on what they can do to ensure that the sprint goals are met.
We've only run this once on the 2 teams (one of those is where the team member I mentioned i part of) I work with and it does help - in fact, one of the teams that used to lack diligence in their work items' life cycle did a much better job last time out, so we're looking to make this a permanent part of our process.
I do agree with you about the visibility - we have some limitations with our task tracking tool at the moment, but ultimately we're looking to have a more accessible/visible dashboard so the team can see how they are doing at real-time and make adjustments.