After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.
The Scrum Guide doesn’t specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.
Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.
Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?
Just as with providing constructive feedback, we shouldn’t wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.
A recent Washington Post article described how kindness can be contagious.
Anyone who has participated in or initiated a “pay it forward” chain would likely agree with the article’s author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.
A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.
I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.
Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?
- Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
- No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
- Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
- Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won’t work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
- It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent’s balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.
Finally, “Take care of your cue ball, and it will take care of you“. Support and lead your team and they will help your project succeed.
I’ve run into a few situations recently where Scrum Masters (SMs) are performing multiple roles and while they might have the capacity to do so, on any moderate sized initiative, it might be difficult for them to fulfill all the responsibilities of the SM role.
Some people may challenge this by stating that the SM needs capacity for daily standups, sprint planning, sprint reviews & retrospectives, but that should still leave them plenty of time to take on another role.
This perception is incorrect.
Agile ceremonies represent just the tip of the iceberg for an SM. As the intro to the SM role in The Scrum Guide states: “The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.” Notice the use of the word “everyone” instead of “the Development Team”. Surrounding any project or release are many stakeholders who the SM needs to work with to ensure that their interactions with the Development Team are in alignment with Scrum values. And as any good Project Manager will tell you, effective stakeholder management consumes a lot of time! Removing impediments from the team’s path will also take significant effort.
If the company does not have separate agile coaches to work on elevating organizational capabilities, the SM will likely spend effort on activities such as coaching executives, training functional managers and collaborating with their fellow SMs to identify patterns.
But let’s say we have agile coaches and there are minimal stakeholders for the SM to work with. Couldn’t an SM play another role?
Even if capacity permits, I’d still recommend avoiding either of these roles:
- Product Owner: Even if an SM has sufficient product domain knowledge, an effective PO has to spend a fair bit of their time interacting with all the stakeholders who have needs and wants related to the product and the effort required to distill these requirements into a clean product backlog is significant. There is also a potential conflict of interest by having the “what” and the “how” intermingled.
- Technical Lead: I know that a true agile team is “flat”, but for organizations going through their transformation journey, until quality development practices have been institutionalized and the shift from specialists to generalizing specialists is well underway there will be a need for senior technical contributors to review the work of more junior team members, mentor them and make key solution decisions. It might be difficult for one person to balance the servant-leadership and coaching stances of an SM with the more directive nature of a technical lead. When an SM is providing guidance to a team member, will that team member know which hat the SM is wearing?
Focus is one of Scrum’s five values. An SM playing multiple roles may not be providing their team with a good example of this value in action.