I’ve done a lot of reading about the topic of Project Management using SCRUM and worked on a project before Christmas in which I used it as a framework. I would like to think that one of the successes of the project was that it has opened a few peoples eyes to the fact that there are different ways of running projects other than perhaps the more traditional methods. It has led to a lot of people starting to talk of the use of Scrum in the organisation. This is no bad thing, I must confess though that I didn’t follow the framework to the letter, furthermore, nor would I suggest it, I do think it has a lot to offer but it is important that you implement it in a way that works for you rather than blindly following practices dictated by somebody else.
It’s better to understand the principles and the values. I have always suggested that people read some of the books that I have and also a number of blogs that I subscribe to. I suggest these with the intention that they get sufficient information to enable them to make their own mind up, for them to then be able to have a discussion with somebody else as to the merits of taking an approach like that.
Papers like Scrum and XP from the Trenches make very interesting reading and focusses on the outcomes of implementing practices but are certainly no starting point, rather perhaps the Agile Manifesto.
For me, the understanding is as important as the implementing, a point that is made very well by Tobias’s recent article.
Tobias makes some points that struck a chord with my own thinking. In his first point he suggests that Product Owners should be part of the team. One of the successes of the Skunkworks project that I worked on was the time commitment from the steering group, sure we suffered from a lack of direction at time though I consider this my own fault more than anything but they were always there when we needed them. If anything I would request for future projects of that nature that one Product Owner is nominated at the beginning of a project and that they, where possible, collocate with the team.
The point relating to length of Sprint / Iteration is interesting, I used one week Sprints on the Skunkworks project owing to the time scales that we had, this worked well for us but it was very intense. Thankfully we never hit any major problems that deflected our main efforts too much, in subsequent conversations that I have had with people though I have recommended a 2 week Sprint, in my mind a 30 day cycle would still be too long for the team to develop any sort of rhythm. This is my own personal feeling, I guess it’s just what works for you.
Having only used Story Points to estimate for a short while I can not really comment, however when we did use them I could see how they benefited as a tool to both gain a better understanding of any given problem but also to speed up the estimation process.
Points 4 and 5 are the ones that stand out the most for me. We didn’t implement a task board until about 3 weeks from the conclusion of the project but it had a profound effect in everyone’s (By everyone I include people outside of the team.) understanding of what we needed to achieve in the time remaining. From the outset I had maintained an Excel Spreadsheet for the Product Backlog which was fine but it wasn’t visible to the people it actually needed to be to. The more I think about it, the more I think that visibility is a key driver to the success of a project, it allows for people to make decisions earlier that can bring something back on track for example, rather than being confronted with something monumental at the end (The biggest failing of a waterfall approach in my mind.).
Finally, I can see that point 7 makes some sense, I do however think that new teams, either freshly assembled or established ones with some exposure to SCRUM, benefit from somebody taking the SCRUM Master role on. I think that an important part of the SCRUM Master role is for them to own the SCRUM process and that they should be able to act as a a reference point / coach to team members.
For me, the principles of SCRUM just make sense, what makes more sense though is doing what is right for you to get the project delivered. It doesn’t matter what you call it. As long as it works.