The "Gold standard" standup meeting?

During a meeting I facilitated this week, a manager stated "you need to attend the gold standard standup that one of my scrum masters run. We visited and were so impressed by her that we'd like our scrums to follow that patter."
     Enter irritation. "Why the irritation Brian?" Was it ego? I'd been running stand up meetings for years and I thought they were good. But, I can always learn something from someone else. So, there was that; ego. But there was also the "gold standard" comment that kept bothering me. So I went to the gold standard standup yesterday and I could see why management liked it. It ended in 14 minutes. The scrum master / tech lead sat at her desk updating the hours remaining in the tracking tool on behalf of the team. It was efficient. I learned a few things.
      But my team is different. We are twice the size of her team with three times the tasks. I also believe that the entire team can share the pain (RTC) or joy (Rally) of updating the tool on their own time. I see the daily standup / scrum meeting as a framework. The agile founders were looking for something very simple in that meeting. For the committed work, we just need a 24 hour check point where we want to know how the work progressed, how it will progress, and if anything is blocking its progression. On top of that, the team brings its own spice into the mix. We have disco lights and music to welcome the team as they walk in. Every day we end with a 1,2,3, clap, but on Tuesdays we end with a 1,2,3 fake laugh. Thursdays are Indian music day so when the team enter, many of whom are from India, they hear the sounds of home*. We laugh a lot. It's the one meeting where we get to see each other and we better have fun. This is our standard that we've collectively built, but could never be repeated by another team. It's gold to us.


* So, to be completely transparent, one out of five times they hear the "sounds of home". The other four times they walk in with a grin. I know that grin. It's the "this is what happens when the Irish guy picks the Indian music" grin.

When the humanity of a Scrum Master blocks the team

It’s important for us to make an immediate impact when we first start on a job. It’s only human. We want our boss and peers to say, “I’m sure glad we hired Emily.” Many a scrum master arrives in a team with ideas of things that need to change, and is eager to make all those changes in a short span of time. However, a wise scrum master will recognize this human desire to make an immediate impact and resist it at all costs, even the cost of looking like you’re not making an immediate impact. The scrum master must resist the urge because bringing large amounts of change into a team brings with it large amounts of risk. In Scrum, we prioritize what gets delivered, and we deliver small chunks of it at a time. We do this, because the most valuable part of the product must be released first, and a small release of code is less likely to break the system. Likewise, the scrum master’s improvement list must be prioritized and released into the team in small chunks. 

Observe the team, make a list of the problems and create a personal backlog of changes you could introduce. Prioritize the list of changes and bring in the most valuable change first. Delivering large amounts of change into a team can break the team spirit, causing the scrum master to become her own blocker.

Sinks and Sidewalks: An Agile Tale

When I arrived at the airport the other morning, I realized my water bottle was still full (a security problem). The option of chugging the entire bottle didn't  fit with my plan of sleeping in my window seat, so I looked around for a wall sink or a men's room. Chugging the water or finding a sink were my only two option, in my mind. It's the way I'd always done it. I was going to ask the info desk woman where I could find the nearest sink, but switched my question last minute to express my need. "Where could I dump this water" I asked her? "Right outside that door on the sidewalk," she said. "I hadn't even thought of that," I responded, as I walked ten feet to the door.

Customers know their need, but often attempt to solution the outcome from within their limited experience and paradigm. By expressing to need to the agile team, the team is given the chance to come up with a better solutions than the customer thought possible. 

Had that nice woman at the airport been offered my solution to my need, I would have been able to dump the water, but may have needed to walk further than necessary, when the sidewalk was right there.

#Agile 101