There is a story about a bunch of corporate employees that have been working together for so long they’ve cataloged and numbered all the jokes they’ve told (and re-told) over the years. Eventually, no one need actually tell the joke. Someone simply yells out something like “Number Nine!” and everyone laughs in reply.
As Agile methodologies and practices become ubiquitous in the business world and jump more and more functional domain gaps, I’m seeing this type of cataloging and rote behavior emerge. Frameworks become reinforced structures. Practices become policies. “Daily Scrum” becomes code for “status meeting.” “Sprint Review” becomes code for “bigger status meeting.” Eventually, everyone is going through the motions and all that was Agile has drained from the project.
When you see this happening on any of your teams, start introducing small bits of randomness and pattern interruptions. In fact, do this anyway as a preventative measure.
- One day a week, instead of the usual daily scrum drill (Yesterday. Today. In the way.), have each team member answer the question “Why are you working on what today?” Or have each team member talk about what someone else on the team is working on.
- Deliberately change the order in which team members “have the mic” during stand-ups.
- Hold a sprint prospective. What are the specific things the team will be doing to further their success? What blockers or impediments can they foresee in the next sprint? Who will be dependent on what work to be completed by when?
- Set aside story points or time estimates for several sprints. I guarantee the world won’t end. (And if it does, well, we’ve got bigger problems than my failed guarantee.) How did that impact performance? What was the impact on morale?
- During a backlog refinement session, run the larger story cards through the 5 Whys. Begin with “Why are we doing this work?” This invariably ends up in smaller cards and additions to the backlog.
There’s no end to the small changes that can be introduced on the spur of the moment to shake things up just a bit without upsetting things a lot. The goal is to keep people in a mindset of fluidity, adaptability, and recalibration to the goal.
It’s more than a little ironic and somewhat funny to see autopilot-type behavior emerge in the name of Agile. But if you really want funny…Number Seven!
Image by Ronald Plett from Pixabay
Scrum mastering remote teams demands an extra set of skills than those required for co-located teams. The non-verbal cues we’ve learned growing up and throughout our careers are often not available with remote teams. Consequently, we have to train our ears to listen more attentively and follow-up to verify any assumptions regarding meaning from conference call, email, or instant message communications.
As scrum masters, we also need to coach team members to deliberately introduce practices that accommodate the lack of non-verbal cues during scrum meetings. For example, there are two practices I implement during remote stand-ups that facilitate the feel of co-located stand-ups.
- I call out the name of the team member who’ll kick off the stand-up conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. I’ve found this keeps the rest of the team focused on the conversation better as they won’t know when they’ll be called. Everyone will have to track who has already presented to the team. In the past I would randomly call out names until everyone on the team had their chance to speak. While they didn’t know when their name would be called they could still count on me to make sure everyone had their turn. Frequently, however, I’d have to call out a name several times to get that person’s attention away from whatever it was they were “multitasking” on. Having the team call out the next person to present has helped resolve this issue.
- After the team member has presented and before they pass the conversation to the next team member, I coach them to pause and ask if there are any questions from the team. In addition to signaling the end of their presentation, this makes the remote stand-up a little less mechanical and puts the thought “Do I have any questions?” in the minds of the rest of the team. More specifically, I coach the team with some version of the following: “Pause after your presentation and ask the team if there are any questions, observations, suggestions, comments, or clever remarks.”
Using techniques like this with remote teams does not replace the richness of co-located scrum meetings. They do, however, move the two a little closer.
Photo by Ivars Krutainis on Unsplash
The dialog about the value of daily scrum meetings is as vigorous as ever. I hope it never gets settled. That’s because I frequently argue both sides. Just not at the same time. Which side I’m on depends entirely on the context. If the team composed of a single functional domain that has worked together for an extended period of time while co-located in a tuned collaboration work environment, then scrums of any frequency are probably a waste of time. If the team is for the most part remote and composed of independent contractors representing multiple functional domains, than it can be argued that daily scrums become THE most important scrum meeting.
I want to talk about the latter scenario in this post. Remote scrums can be the most challenging meetings for a scrum master to facilitate. (In the interests of space, I’ll have to set aside cultural and language issues that are frequently an issue while running scrum with remote teams. I do this not to minimize the importance of these issues, but to recognize they are worthy of much better treatment than I can cover here.)
Remember the agile manifesto? The first two line read:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
Simply stated: Don’t bother taking notes during a scrum. Not as a group, anyway. Individual agile delivery team members are certainly free to do so if it helps their individual efforts. Scrum notes are a false crutch. It’s as near to a 100% guarantee one can get to say that no one will every go back and re-read scrum notes. If someone is demanding scrum notes be taken, suspect a waterfall zombie in your midst and respond accordingly. Worse yet is that the poor agile delivery team member tasked with serving as scribe is going to be so busy trying to capture stuff they will miss much of the conversation and information exchange that makes a quality scrum so vital.
- Early in a project the scrum master should specifically call out team members during the scrum and do so in a different order each day. This will prevent team members from talking over one another as they miss the visual cues that tell people meeting in person who is likely to speak next. Changing up the order keeps the whole team alert as they will not know when their name will be called. As the team gains experience with each other, switch to calling out the name of the team member who’ll kick off the scrum conversation. When they’ve completed informing the team what they’ve worked on yesterday, what they’re working on today, and anything in the way of success the delivery team member calls out the next team member to take the conversation. This will further develop the remote behaviors that compensate for the missing non-verbal communication.
- At least once a week, more frequent if warranted, briefly reiterate the sprint goals and minimum viable product (MVP) definition at the start of the scrum-up. I’ve also found it very effective to challenge the team about mid-sprint with an intuitive check on how they are doing with respect to the sprint goals and MVP definition. Any feelings of dread there? Any sense of anxiety? If so, what’s causing that feeling. Move down the 5 Whys path to find any root causes. This will help shake out any hidden dependencies or reluctance by any one team member to ask for help.
Consider quality virtual meeting hardware and software an essential tool for your business. We wouldn’t accept a surgeon who goes into the operating room with kitchen knives because they’re “good enough.” Sound professional, be professional. Clear and efficient communication is essential to the success of remote agile teams. Have the best possible communication tools available in place and cut corners someplace else.
- A good view of the scrum board via web conferencing. This is the big picture the team needs to keep their individual efforts in context of the whole sprint effort.
- A high quality and reliable audio connection
- How each team member’s cell reception? Does their connection drop frequently? Is their voice muffled or otherwise hard to hear? They may need a phone upgrade, particularly if their phone cannot leverage WiFi calling.
- Are they on a land-line?
- Are they using a cordless phone that’s subject to interference or cuts in and out?
Photo by Natalie Pedigo on Unsplash