My very first team as a “Scrum Master” (having never taken a class or worked in Agile before – thus the quotes) wasn’t formed well and I’m pretty sure none of us knew what the heck we were doing Agile-wise. At least I didn’t. That said there is one thing I did with that team which I still do today. I protected them. Protection is important for teams and it’s not just the job of a Scrum Master to do it. When I say protect, I think, what I mean is to protect the environment. A team needs an environment where they can be honest without repercussions, feel comfortable holding each other accountable, disagree on how to reach common objective, focus on themselves and their commitment and work in a way that works for them. I’ll never forget the Product Owner coming over to me and whispering that a developer was watching TV in the galley while eating lunch. The Product Owner thought the poor guy should be in the room coding! It wasn’t enough that the team and this particular developer had been killing themselves for weeks – they needed to starve too. Obviously, that wasn’t OK and I said as much to the PO (bless his heart). As a Scrum Master, you need to care for and about the people on your team and help protect the integrity of their environment. Amr Elssamadisy’s blog has some great posts on the importance of a safe environment which are worthy of your time and thought. Protect the team!
Further along my Agile journey, I noticed some teams had working agreements that took up an entire wall. Well, not an ENTIRE wall but, almost. On my teams, the “norms” were always super simple and I don’t think I’ve seen more than 8 in any of them. My teams would have things like “If you’re sick, stay home.” and “Don’t eat smelly food in the room.”. I saw one team that had Team Norms, Meeting Norms, Stand Up Norms and Core Hour Norms. It was nuts. It seemed, to me, that the norms were representative of many individuals protecting what they wanted. Their agreements didn’t reflect a single entity at all. Maybe I’m crazy but, I believe Norms should be simple, things everyone can agree on and no more than 10 bullet points. Keep it simple!
Further still….I created a backlog for newly forming teams. The stories accounted for things teams need to do when they first form like agree on a team name, create a team vision, decide how to organize the board, inventory their skill sets, establish team norms and so on. Each story had acceptance criteria. I let the team prioritize them and they also estimated them. A sprint was equal to 2 hours and they used the complete Scrum Process. The first time I did this was really, really cool. The team went out, as a team, to scout out other rooms and interview other teams to get ideas. They didn’t split up and what they got out of it was SYNERGY. Everything in that room had their stamp on it and it was clear to anyone who walked in. Seriously, executives would comment on how good the energy was in that room. My only role in that whole exercise was to answer questions as they related to Scrum and keep it simple for them. So, to sum up, let the team own the team from day 1.
I heard a Scrum Master refer to himself as a babysitter the other day and it made me cringe. The truly horrible part was he was saying it to a class of team members who were learning about Agile. *sigh* The beginning time for a team is precious. There’s no history or baggage. There’s a great clean slate and anything is possible. This is time to take advantage of to team build, establish ownership (the team owns the team) and set the tone for duration of their existence. As a Scrum Master, don’t squander this time and don’t let anyone take it away from the team either. Protect their space to form. You’re not a babysitter or a hammer. People are smart. They want to do well and they will give their best IF they have an environment to enable them and a Scrum Master who is willing to protect them, keep it simple and let the team own the team.