Implementing SCRUM – Part B [Getting Hold]

“My” experience with last two projects suggests that it takes about 2-3 weeks for *anyone* to get hang of a project [for instance what is ailing the project development in “particular” project]. It is only then that you start to understand and devise strategies which actually start working. This process of “getting to know a project” is littered with a lot of frustration and failed efforts.

Last week I was confused between my time between the two projects – the MySpace for Automobile Enthusiasts and the next generation social networking channel [lets call it Project A]. Project A perhaps needed me more and my heart somehow leaned more towards it as well. Project A suffered from a particularly lousy and long Analysis phase, inability to handle ideas coming when actual implementation was underway and slightly inexperienced [in social networking] designers/ developers executing the project. The project is late by at least 2 months. As of now, the team does not really understand the concept of “done” and the last projects done by the same team have come in for some heavy criticism from experienced designers/ developers. Last week “I” tried to get up a sprint backlog for a week to keep a track of the work to be done and exactly last week, there was a semblance of progress in the project. The team comprises at present of a dedicated HTML person, a designer and two developers with one GUI expert and part time technical experts – seems like quite a resource abundance. What we do not have is developer focus. They have closeted themselves in false and fake ideas fed to them over the years [like finding bugs is QAs responsibility] and are totally clueless on emergent design practices. As a SCRUM team, what we also don’t have is an effective sprint backlog for every sprint where time can be tracked easily and regularly. What we also don’t have is a product backlog with a vision – it sure has all the requirements listed, but it does not have a vision – hence, we do not know if a priority indeed is a priority and if yes, then why so? What we also need is an effective QA mechanism. I also sit away from the team and this obviously is not a great thing as I can’t mentor the team about key Agile principles and practices and also keep a simple check for my notice on whether its actually filtering down to the team. I am also not sure if the team understands SCRUM or not. We need to do something about this as well.

Let’ see what we can do about all this, possibly start with:

1. Crank up a product backlog with the client – something which has a vision and not just requirements
2. Crank up a detailed sprint backlog for every sprint – efficient analysis phase at start of the sprint. This should be done on priority. The team will need to select this backlog and then commit to getting this done.
3. Do we need sprint retrospectives every sprint – lets do it once every 2 sprints for now
4. Demo the work to external people – not involved with the project for critical feedback
5. Give a brief introduction to SCRUM and Agile Principles to the team.

Let’s see if we can do this next week.

————————————————————————-
Journey from no-style Project Management to Agile Thinking and Principles
http://agilediary.blogspot.com/