SCRUMMmmmmmm….

I recently started using the SCRUM methodology to help deliver a team of SharePoint developers. Since I am still quite new to SCRUM I thought a few of you might benefit from my experiences and the pitfalls along the way…

Stick to the plan

If you ever think of using SCRUM my first and most important advice would be to start out by following the rules of SCRUM to the letter. Start out by doing what has been described in many books, websites, blogs, … change the process and the way of working only after doing a few sprint runs. Not a single rule of SCRUM has been written down without any reason. So, why would you not give it a try instead of changing the rules from the start with the risk of a failing  project, de-motivated team, … (as I did, what did you expect?!)

In my first project as a SCRUM master I saw the benefits and knew what I wanted to achieve, but due to the limited time available I started to do the work instead of my team: I started creating user stories myself, left only limited room for discussion (just the stand-ups), didn’t really include the team in defining a sprint backlog. In fact I was just playing the project leader and pretended to use SCRUM.

Nevertheless I hoped that by using SCRUM I motivated the team, created room for changing specifications and helped to spread the knowledge about the project amongst all team members, … But what I really achieved was a dull stand-up, no motivation and a failing project. No sense of responsibility for the project whatsoever had been introduced…and it became painfully clear.

It was by reading a book on the subject that suddenly it appeared to me what I had been doing was all wrong! And the answer to my problems had been there all the time…I just needed to follow the rules (how many times have I been that before :) )

Yesterday I started a new sprint planning with a renewed hope of achieving the goals I had set. The product owner had a small set of things to be done (I must say that there’s still some work there..). With the team I started to go through the list and encouraged them to ask questions. It was really funny to see how the planning poker made them nervous and afraid to not make a fool out of themselves, but the result was that they were all trying to find out what a certain job was about, what effort it would take and how it needed to be done. I was really surprised that this simple trick created such an involvement and awareness about what the team members had been doing. To cut short: we as a TEAM established a first real agreed sprint backlog. The team committed to the plan and everyone seemed to enjoy the new way of working.

One step at a time

Did you ever start about a million jobs at a time and never finish one of them? Well, I did…and so did my team. When we first started using a scrum board, it was filled with users stories that involve a whole set of taks that on average take about 3 mandays. The result was that everybody was doing multiple tasks at a time and never ever one was reaching the ‘done’ column.

More importantly it was quite impossible to follow-up on these tasks…I didn’t have a clue why things were slowing down and what the status of the project was. Yesterday we started working with user stories that are made up of a bunch of task that never take longer than a few hours. This is more manageable and more fun (because we now reach that final column on the board), and it all has a fantastic side effect: all tasks can be taken up by different members of the team. What used to be the responsibility of just one person is now distributed among the team. Communication occurs more often and the frustration seems to disappear all by this one easy little rule!

Demo time

Motivation is really key to success in my current project (have I mentioned that it is in the public sector…makes things easier to understand :) ). Therefore another really dumm ass idea of me was to win time by not doing a demo on the end of the sprint.

It is clear now that it encourages to deliver a fully working, fully tested product at the end of each sprint. It makes my team proud if they can show off the new functionality and it again raises the awareness on the complete project. Plus it gives me a great chance to thank them for their work.

I can’t wait to see what the result of our new approach will be. I’ll keep you posted!