I’ve been part of a team recruiting for Scrum Masters …well, pretty much since I joined NewVoiceMedia. Now, for the first time since I joined we are about to be fully staffed (woohoo!). This got me thinking about what advice I would give to new Scrum Masters when they join a new company, or just a new team.
I find it quite difficult joining a new team. Often, they are already formed and have their own way of doing things that they believe is good. It might be, for all I know, and that’s my problem.
Given that my job is pretty much to ease their pain and help them become better than ever before, the first few weeks with a new team are excruciating for me. I want to help. I want to be valuable. I can often see things that look sub-optimal from the outset, and ‘fixing’ this is what they are paying me for after all, isn’t it?
NO, NO, NO! I have to remind myself that it’s a long game!
One of the absolute best pieces of advice I can give a Scrum Master who finds themselves in this position is this:
Sit on your hands.
Seriously. Do nothing but observe for at least an entire iteration – more if you can.
Rushing to fix things risks missing context, and you could so easily make things worse. I have also found that delaying getting involved early increases the respect and trust I get from the team members further down the line.
So, take a bit of time.
Doing even the right thing, at the wrong time, makes it the wrong thing.
If you watch and observe for the first few weeks, your next problem with a new team is knowing that you’ve improved things when you do start to help them.
For the first few months with a new team I focus heavily on the following things.
I have mentioned before how much I value journalling, and this is another opportunity. Take notes on everything you see, and feel free to be judgemental if you like. I know, you won’t often hear me advocating that, but no one else is going to read it.
Here’s why it might be helpful:
It can help to capture your observations and impressions using more stark language than normal. Later, when you re-read your very partisan notes, it challenges your thinking. Your brain will try to validate the statements you wrote (after all, your brain will reason, you must have thought that because you wrote it). Also, because time has passed and you now feel part of the team, your brain will naturally leap to the ‘defence’ of your team. You will want to explore the opposite point of view to what you wrote.
Right now though, its all about capturing observational data.
You are likely to be completely wrong on at least 50% of your early observations anyway, so embrace that too.
OK, so we are going to observe and record at first, but then what? How do I, as a new Scrum Master for my team, measure that we are improving?
I want to measure that my team is adopting agile practices, and that they are continually improving. As we focus on how we do things, it can take us slightly longer to do them. Velocity and cycle time are 2 of my favourite core metrics for an agile team and are useful in the long term view, but may initially look worse. This is normal as we work to improve how we do things.
So what else can we look at instead?
Set a Benchmark
As part of my journalling, I observe and frequently capture instances where I see evidence of great agile behaviour. This allows me to set a benchmark, and with snapshots taken periodically over time, I can infer trends in improvement.
When ever I join a new team, I take this list with me as a starting point. I always ditch some of the questions, and add new ones too – even during the process. After all; every team is different, and has its own personal challenges.
This really is a tiny subset of the things that you might want to measure, and I like to focus at this stage on things that are good in the team. You could also look for signs of waste, good or poor communication, problems in live, problems with deployment. Its about finding a foothold to start with a new team, or in a new company, not measuring all the things!
2 Important Things:
- I never, ever, EVER publish them, or share them. No good can come of that, believe me!
- Don’t tell your team. Controversial, I know, but this isn’t about hiding things from them, its about making a fair assessment.
If people think they are being watched, they alter their behaviour – it’s just human nature.
Human beings can’t help gaming the system, if there is a path of least resistance, human beings will take it. As their scrum master, you will shortly be having great conversations with your team around good agile practices. Giving them compelling reasons to take a more difficult path is kinda your thing here.
Take A Moment
Often, a team will do something on your sample day but not on your next sample day. This can be frustrating and its VERY tempting to say “well I saw them do that yesterday, so I’ll mark it as observed today”. Try to stick to only observations made during the sample day in question and not game it. After all, this one census is of no worth on its own anyway, only as part of the whole collection over time.
I always equate metrics to pixels in a picture: of little worth on their own, but together make up a reasonable picture of reality.
I would suggest weekly snapshots are too often from my experience, but hey, whatever works for you. I snapshot fairly regularly at first – perhaps every 2 weeks for an initial 2 or 3 months. After this, the time between snapshots gets longer and longer, rather than regularly spaced.
Take Your Place
Inevitably I stop snapshot taking altogether once I feel fully aware of their world view. Its not a conscious decision, I just look back one day and find I’ve not recorded for a while. It always makes me feel good when I do this – it was an imperfect system that I have outgrown. I am at one with my team 🙂
Where might you want to double down your efforts or change tactics with certain practices? Perhaps you need to arrange a workshop or further training for example. Is story break down a problem, or communication between developers and test? You have a whole heap of information at your fingertips – just work out what one thing is most important to address first.
What do you do as a new scrum master when joining a team? I’d love to know.