We (Conversocial) recently adopted Scrum. This is the first in a series of blog posts containing what we've learned whilst adopting Scrum.
On the first day, we Scrummed like men possessed and saw that it was good.
On the second day, we got it wrong.
By the afternoon of the second day some of the team had gone off-piste and instead of working from the backlog they were working on ad-hoc things that hadn't gone through the scrummaster.
I was angry. Only a day and half for us to lose focus and derail into the old way of doing things.
My first reaction was to tell these people that they were doing it wrong and moan at them.
Instead, I slept on it.
Overnight I realised that the problem wasn't them being wrong or that they were deliberately sabotaging things. The problem was that they didn't realise they were doing anything wrong. The root cause of this was a lack of knowledge about Scrum and the blame for that was mine.
That morning, instead of moaning at the guys, I sought to educate them. I wrote a long e-mail explaining the benefits and how the ad-hoc things could have been addressed by Scrum better. The result? It worked and we're now more focussed on our backlog and are really gaining momentum.
Moral of the story is: educate, don't moan.
If you're interested, the e-mail was something like the following:
I thought it might be an idea to go over why I think working in Scrums is a good idea, as I feel like yesterday we deviated into what became a day of fixing bug emails and X working on other things.
When we started doing Scrum on Monday the plan was to commit to two weeks worth of work - and most importantly, sticking to it.
This gives greater:
- Focus - it means we get in the zone, can be completely immersed in a task and produce great code - quickly (just ask Y)
- Visibility - we know exactly what is done and what isn't done
- Morale - we get a greater sense of progress and achievement, and importantly get fired up to do more
This allows us to:
- Prioritize effectively - push-back forces you to really think if something has to be done - this reduces non-sprint work and helps us get the benefits above
- Discover our abilities - the scrummaster should assign it to whoever is best placed to do it, to get it done quickly
- Keep focused - everyone except the scrummaster will have fewer interruptions, keeping us in the zone
As a case study I'm going to show why this should have gone through Y:
- X isn't familiar with the metrics side of Conversocial. Hence, this took longer than it needed to.
- Because it took longer it was more likely to miss the deadline (which I understand it did miss). So, we might as well have just put this in as a high priority for the next sprint which is only 12 days away now.
- Due to no push-back and rushing this there wasn't enough clarification of what stats we really needed and the stats we got as a result were not very useful.
We have a very good team of people and it's a shame to be wasting their time not being as focussed as we could be, as a startup out key advantage is that we are quick and to do that we need focus.
So, in future, can we please have all ad-hoc things (stats, support, urgent features, etc) all go to the scrummaster (Y this sprint)?
In hind-sight, that was actually more ranty than I really wanted but we're all still learning and improving ourselves :)