Friday, 14 May 2010

Agile – bringing it back on track

So in my last post I outlined the situation I encountered when I joined my new company, now here’s what happened at the end of the first full sprint.

The scrum master worked with the product owners to groom their backlogs which then came to the team to story point to allow us start calculating velocity for future planning.

The scrum master was out of the office so I stepped in and ran the review, retrospective and sprint planning.

In the review we had no product owners turn up so to set expectations I got the members of the team that had worked on various projects/products to demo them to the rest of the team, this served 2 purposes:

  1. Team gets used to demoing the work that they’ve completed
  2. Share knowledge within the team

The review went well with the team asking questions about the various projects to get a better understanding of what the different team members had been working on – its not full understanding of the code but it better than nothing plus good to see the team wanting to share the knowledge.

We then moved onto the retrospective and I got the team to do Start, Stop, Continue to identify what they’d like to change in the process, after we went round the table getting feedback from the team we all voted on the things to focus on.

After the retrospective we did the planning, now this was the first time in a long time that the team worked out the number of hours they’d have to work during the sprint (based on 6 hours a day and 9 days in the sprint, last day given over to the sprint meetings) then tasking time ‘off the top’ for meetings, training, etc.  Once we had the actual amount of hours to work with we got the stories newly groomed by the scrum master and tasked them out, and we continued until we reached about 80% of the available hours and then decided as a team to commit to the work.  We tasked out some additional stories in case the team got through work quicker than expected just to have tasked stories in hand to simply pull in and work on.

Doing this was a different way of working and some members of the team were a little uncertain as to why we were doing this and what we would gain, what was nice was the members of the team that did understand explained it to the others rather than me telling them and coming across as ‘dictating’ to them.

During the next sprint we worked through the stories on the board, the scrum master protected the team so the pink stickies on the board were reduced (unplanned work) and the product owners attended the daily scrums.  We got hit with a massive support problem but had taken a substantial number of hours off the top to handle this so we didn’t have to drop any stories out.

At the end of the sprint we had succeeded.  All committed work completed, tested and ready to be deployed (we have to get approval for system deployment by a global change board, otherwise would have deployed in the sprint) and we had managed to handle the support, including a massive problem what we got hit with.

It seemed that my actions were helping but that was just one sprint, the next sprints will decide if any lasting change has been made.

Next post will go into the next set of sprint meetings and what happened in the next sprint.

No comments:

Post a Comment