I must admit, I really don’t get some of the scrum “naming” conventions. First of all, what’s the first association you have in mind when you hear a word scrum? What I imagine is a bunch of big guys, heads down, bottoms up, pushing hard. And Scrum Master? Sounds like a guy you need to obey, not really a service guy as you read in the role description. And then how about calling iterations – sprints? What was wrong with iterations? To me, software development is more like a marathon than a short sprint, unless you can run 400 sprints at once…
picture by © Chris Frazer Smith
Either because of the chosen names, or because of the of the way scrum was originally defined, there are few problems you might get into:
- Having standup meetings where people report to the Master (if you see guys in the standup circle always looking at the same guy while talking – you have a problem)
- PO playing an aggressive customer role and pushing folks into DemoDrivenDevelopment Mode (see one of the previous posts)
- Team forgetting the big picture, with emerging design ending up in no design
- Team replacing heavy waterfall planning with no planning (how often have you heard of “flat backlog?)
- Developers feeling constantly under pressure, getting exhausted after “400 sprints”, not having time or energy to play or read
One of the biggest issues with agile introduction is the confusion people have between roles of the scrum master and the project manager. One needs to remove the obstacles in front of the team, while the other one needs to provide the planning to the stakeholders. From the moment that role is shared by the same guy, it is hard to avoid situation in which people see the Scrum Master as the Master. Be aware of that. That’s all I can say. The longer you work with the team and more trust you earn, the easier it will be to combine these two roles.
When it comes to the planning, this is a hot topic, and in my next blog I will explain how I do it. There are plenty of books around, and this time I will only recommend 2 blog posts:
- Jeff Paton blog post “The new user story backlog is a map” , in which Jeff mainly addressed the issue of the release planning.
- “How to slice the Elephant” from Alistair Cockburn, who in his usual funny style talks about problem of loosing the big picture during development
And how about creativity and motivation? Ken Schwaber said once: “Scrum is like your mother-in-law, it’s constantly pointing out your shortcomings.” (for the record, I love my mother in law). It is true that we need to learn from the feedback, but it can as well be tiring and boring – even more if retrospectives are done too often leading to the same conclusions. In one of my previous posts I touched upon this topic “How to do Lessons Learned“, and unless really necessary, I suggest you don’t do them every iteration – you better go for a beer with the team and celebrate if you’ve done something great.
One way of embracing creativity is to introduce “Fed-ex” days. Atlassian folks today get all (TED) credit for it, but as far as I remember, they were not the first guys to try it out. Fed-ex approach is a great way of enhancing existing application with some cool features, or sneaking a new language or framework you want to try out – but you need to be careful there and avoid “pattern-happy” people abusing the concept.
So, put your rugby jersey on, heads up and be ready for the fun, the field is rather muddy first time you try it out.