A little over a year ago, I got my Scrum Master certification. The two day certification was extremely encouraging and inspiring, and I really felt I was ready to take on the world with my newly-acquired skills. And Certified Scrum Master sure does sound sexy, doesn’t it?
One of the things I like the most about the Scrum Master role is the coaching aspect. I really enjoy coaching, and I love the satisfaction I feel inside as the process begins to grow on the development team. When they start gathering at one-minute-to-daily-scrum-time so they can report the day’s progress to each other.
But why is Scrum so hard to get to work properly?
At the company I work, I have been trying hard for a year now to implement, if not all, then some of the Scrum process into our daily workflow. And my boss has been backing me as best as he can. My main problem is that he (and basically everyone else in the organization) don’t really understand Scrum. Some know of the basics (daily standup “scrums”, sprints, timeboxing, burn down charts), but I’m learning the hard way that if Scrum is to be successful in our department, everyone around us needs to somehow be aligned to the process and work model. Basically, I think that sending everyone to get Scrum Master certified would definitely help. But of course this isn’t really an option.
One of our biggest impediments is that we don’t have real product owners. This role is basically missing, and we “get by” at every sprint start by asking someone in the organization with domain knowledge to play the role of product owner. We also face the challenge that many of our projects are either complete re-writes of older products, or they’re something new altogether. They aren’t simply existing products that we’re just adding features to. This means that the scrum teams are facing a huge amount of architectural decisions during sprints. And seeing as we don’t really have an “architecture team”, many decisions are just made at meetings they hold together. These meetings are expensive – they often come up completely unplanned and can easily throw the burn down chart way off (I’ve seen it happen many times).
Another impediment is that we’re in the process of integrating systems from a competitor that we acquired earlier this year. This is of course a top-priority from the management group and they will spare no means to get the job done. In practice this has the effect that team members can get pulled at moments notice to do something else. And there is little I can do to stop that.
Another challenge I’m facing is the whole aspect of reporting. Finance would like us to begin reporting hours spent on each and every development project. The problem is that “time spent” is not measured in Scrum. At least not if you want to follow the process completely (which is a goal for me – Ken Schwaber, the father of Scrum, says “If you are not an expert in something, you are not at liberty to change it” – and I totally agree) I cannot possibly adapt Scrum to “work better for us” if I haven’t fully tried it in its basic form first. And we’re still getting there. But nonetheless I still have to figure out an effective way of reporting hours from the team, without asking them to actually start logging work done.
The next thing I’m going to try to push into the team is the concept of using story points when planning the product backlog. I want to start pushing the concept of relative size of backlog items, as opposed to using hours or man-days. The reason I like the idea of story points is that managers have a tendency to accept hour or day estimates as a commitment from the team. By using story points we abstract this away and convey the fact that backlog estimates are extremely rough and are solely based on hunches (because of the nature of backlog items, in that they are not at all very specific).
Next week I’ll be attending the ÖreDev conference in Malmö, Sweden. I’ll be following quite a few Agile sessions and hope to get some answers to some of my questions. Like “How can we get better at following the Scrum process as a company and not just as a small isolated team”
Subscribe