I am now in my third sprint as a volunteer scrum master with Silicon Valley Project Management, an organization that provides experiential learning through enhancing and building out a live website.

This posting is a follow up to my initial set of thoughts and lessons learned, published in this previous post. There is no particular theme, just a collection of random thoughts.

• Scrum masters should check in more personally and individually with developers to see if help is needed.

This idea was suggested by a developer on our scrum team who was new to the team and maybe felt a bit at sea during his first sprint. It’s easy to take the attitude that people should take reach out when they need help. But as a scrum master, I am becoming increasingly aware of my responsibility to proactively build relationships and trust with team members.

Along those lines my co-scrum master had suggested we meet one-to-one with each developer at the beginning of the first sprint I participated in as SM. That was great for getting to know the team members, doing a bit of relationship building ahead of time, and finding out their goals and interests in our program.

The more of this work I do, the more I’m realizing that so much of being an agilist is the application of people skills and emotional intelligence.

• What to do with all the ideas that come out of sprint retrospectives

We had a lot of uncertainty around the results of sprint retrospectives. They were all just being gathered into one big bucket from all the scrum teams, and nothing was really being done about them.

Eventually, one of our mentors initiated a process that we’ve been experimenting with.

I believe the following steps are from the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp.

0) Physically group items by category, e.g. “improve how meetings are conducted”, so that you can readily see related or similar items.

1) Vote on the items by using silent dot voting.

2) Arrange items by number of votes by placing them along a horizontal line.

3) Using a four-quadrant chart, position the most-voted items along the two axes of impact vs. effort.

4) Favoring those items that are high impact and low effort, make them actionable by brainstorming specific solutions and tasks.

5) Finally, create and define retrospective backlog items. We then used a Kanban-like task board to organize and manage the workflow.

• For visibility and transparency the burndown chart can be published after every daily scrum.

It’s a small thing but it helps to keep everyone on the scrum team apprised as to how overall progress is being made towards meeting the sprint goals by the team and not just be the individual developers.

• Use team building activities such as the following within small-group breakouts (with thanks to Don Colliver)

Questions / Tasks:

  1. Location
  2. Guilty pop pleasures
  3. Determine team name
  4. Designate spokesperson

Create a one minute team cheer:

  1. All shout team name
  2. Short team chorus
  3. Solo ‘moments’ - first half of the group
  4. Group chorus repeats
  5. Solo ‘moments’ - other half of the group
  6. Group chorus repeats
  7. All shout team name

The Team Cheer exercises were ridiculously fun and hilarious.

• Sometimes just agreeing on and setting a time for a recurring meeting is enough to build momentum and enable progress

We were forming and storming a new team with a charter different from the existing teams. I felt that we were making little progress towards getting organized, so I merely proposed that we have a weekly standing meeting as a way to get started. That simple cadence has kept us going in spite of being unsure of our priorities and our workflow.

It’s a good example of making a small, low-risk experiment to see whether a particular process or procedure is productive. The potential downside is that an experiment becomes fossilized as “the way we do things”, so it’s essential to hold on lightly and be willing to let go.

• The lean coffee format is a great way to host an open, agenda-less discussion

I’ve been regularly attending a lean coffee office hour hosted by Chris Sims at Agile Learning Labs. I love having the attendees propose what to talk about, having those topics/questions voted on, and democratically deciding what to discuss and for how long.

I recently hosted my own lean coffee meetup of a few of our scrum masters. Not only were people engaged, but as the facilitator I did not have to bear the burden of deciding on the agenda. Win-win all around.

I used the Lean Coffee Table service which works really well for doing lean coffee remotely. The user interface is simple and intuitive for both attendees and for the facilitator.