Absorption of SCRUM - valuable lessons learnt

If you are software professional like me and have experience with SCRUM as well as waterfall , yet inherit a team that hasn't had much experience with SCRUM. What should you do as critical success factors to get going and move the team in the right direction. I am reflecting on some recent "real life" experiences that I hope will be useful to you and the community out there. These experiences come from a recent implementation of SCRUM at a fortune 100 software company.

Here is a typical real life situation:

1. you have a release to push out and you're responsible for it
2. you have a new team, which has little or no SCRUM experience
3. you're in charge of figuring out what process is best while not hampering the team and yet instilling a sense of discipline with a new process and there isn't too much time for training

Faced with this challenge I decided that having the right SCRUM Toolkit was an important first step.  There are a couple of very good options out there and here are some examples:

• SCRUMWORKS by Danube (http://www.danube.com/scrumworks) - there is a free version and a license version. The free version allows you to do basic management like manage sprints, add backlog items to releases, allow a team definition and show basic burndown charts. It works over the internet and its free and a great tool to get started. The paid version has better charting, integration with JIRA and other useful features.
• RALLY by Rally Software(www.rallydev.com) - this is a paid for monthly scrum tool, more advanced than SCRUMWORKS, but it depends if you have the budget to cover costs. its free for up to 10 users. For more details on pricing go to the company website. Rally has many good features on tracking and is very comprehensive.

There is always the "excel" version to use which means that an excel sheet is used to look at burndown, tasks left, backlog etc. I am not a big fan of this approach because its hard to coordinate among the team members and if you are managing a larger team, the updates can get time consuming.
Note: There are many other tools in the market, so make sure you use the best tool for your level of maturity in SCRUM and team culture.

Second, I spent time providing my team with basic training on principles of SCRUM, I focused on a couple of key aspects:

1) SCRUM is bottom up - team members should be accountable for hours and there is always a "goto" person for a task to be completed

2) SCRUM collaboration - this really means, you need to ensure your team is open about communications and having the daily scrum. Ensure a team lead, or manager allocates a SCRUM master and ensure daily SCRUMS occur.  Ensure this is also monitored and ask only 3 questions:

• What did you work on yesterday ?
• What are you working on today ?
• What is preventing you from reaching your goal ?

The KEY is to not let the SCRUM turn to a long meeting where people try to resolve the impediments facing them. I can't stress this enough, as I find with new team members and people adopting SCRUM, they have a natural tendency to resolve the issues in the SCRUM itself

3) Plan , Plan and Plan - you have to spend time planning and estimating your sprints and how many you will have. Its worth the extra time to do this up front and spend time with the team on this.

4) Burning up, Burndown - the team naturally seems to understand the concept of burndown, but seems to resist the concept of burnup or they don't understand it. It takes time to understand and internalize these concepts. Spend time explaining and guide the team to ensure that its "ok" to burnup if there is legitimate reasons to do so.

5) Backlog management - features go on the backlog, organize them in a release which allows people to frame key features for the release you are currently working on. Explain the difference between tasks and the backlog.  Assign level of effort points to items. I typically use Fibonacci series ( 1, 2, 3, 5, 8 ...). For a great article on this read: http://kenschwaber.wordpress.com/2011/03/11/planning-poker/

6) Team updates - its critical that the team update impediments if they arise, close them out and update hours ( burndown ) on tasks. People can think its a "hassle" or unimportant - but its the essence on getting metrics.  As a spent a lot of time ensuring updates where timely and accurate.

7) Definition of "Done" - Get proper agreed definitions of what the definition of "Done" means for the team so that when a team member marks a item as Done, there is no ambiguity about it.  This is impact to quality further down your cycle if this is not agreed to and followed by everyone.

Thirdly, I was guiding the team and monitoring the process on a frequent basis.  What I mean is to facilitate the team in grasping and internalizing SCRUM concepts like daily SCRUM meeting, updates, logging impediments, burning down etc. I think this is key to success when you start, since the team is still absorbing the concepts, working them out between themselves and trying to satisfy software release goals. The amount of monitoring, which is why I like more automated tools, which allow you to manage a "dashboard" is key in real time. This is even more important when you have a distributed team in various time zones ( which was my case).

Finally the last part of the puzzle, is to do a retrospective. I had some spot checks during my release but spent the "downtime" after my release going through completed sprints and what worked and what didn't. We looked at sprints that we planned well and others that we had to invalidate and start over . We also had a frank open discussion about it. As I expected, there were still lingering questions on how to handle certain situations.