Trying a new development methodology with my Product Team - Scrum!

Many of you may or may not know that for the last year I’ve been deep into product development instead of my normal role of consulting. (My company continues to offer consulting services and we’ve grown to over 40 employees! ) Our growth has allowed the company to invest my time and company capital into a product that I’ve wanted to develop for years. We plan on releasing a beta in the first quarter of ‘08.

We started with a hybrid approach of partial specifications and some form of agile development.The one thing that I’ve noticed is that this has put some stress on the development team. The traditional way of developing for a client was just not working. I wanted an Agile approach but I’ve had to re educate the development team. I believe they have been so used to the process of having everything handed to them in the spec, that they’ve lost the ability to be agile. We don’t want to be cowboys but I’m too strong a believer that “too much process” can hinder progress. However, I do have other senior executives that may think otherwise.
(That’s a different post. that I have to do someday.)

Our product process has begun to evolve into the scrum methodology before I even knew it existed. It really started back in May. We needed to demo what we had so far for at the BI Conference. The entire team went into a sprint to get specific features completed. We were able to complete the task and had a successful show at the Conference.We went back to developing normally for a few months but I was feeling it was probably taking a bit longer than I would have liked.

Then we had another conference in September and the sprint began again! These sprints seemed to have produced the best results. The one thing that we could improve upon is the hours. We need to have the same passion but get the guys only working a regular shift.I know sometimes the development team feels frustrated, but I 100% strongly believe that these sprints to show where we are, even if things are not completed, has proven certain things definitely work and other components we thought would, don’t. I know some felt rushed and missed a few thing but that’s what re-factoring is for. To me, prove the idea can work and then tighten it up! Re-factor and unit Test it to death!Over the last month, I’ve talked to a couple of my friends who are working for new startups and the one methodology that has been brought up in the conversations more than a few times was the Scrum methodology that they adopted from the beginning!

Why the word Scrum?It comes from the fact of having a small team (like Rugby). In Rugby (which I played in High School in Canada), you have a scrum to determine which team gets the ball.Everyone works together by huddling in a circle and under the scrum a player called the hooker (which I played) would try to get the ball as the team used their feet to hook the ball back.So the term scrum is perfect because everyone is working together to complete a specific task.Everyone has their role. In sports you’re constantly having to adjust your game plan and be agile enough to change it when need be. Why should software development be any different?

Scrum works for small teams around 5 to 9 members (perfect I have 4 developers and myself), usually has involvement from the client (again perfect because our partner is actively involved), and outside consultant to help once in a while (perfect, we’re bringing help from an expert one to two days a weeks, when needed, to help maximize productivity).

Characteristics of Scrum

• A brief daily meeting , at which progress is explained, upcoming work is described and any issues/concerns are raised.
• A product backlog of prioritized work to be done.
• Completion of a fixed set of backlog items in a series of short iterations or sprints.
• A brief sprint planning session in which the backlog items for the sprint will be defined. (Mini Specs)
• A brief sprint retrospective, at which all team members reflect about the past sprint.

Last week I decided to have a daily meeting with the team to see how things are going and what we need to do next. I called it the 10 at 10. (A call at 10 for 10 minutes). We also setup a new tool called Trac that completely integrates with Subversion and includes milestones, and tickets that can be used to set up tasks. This is going to be great because now we’ve set tasks for people to complete for a specific period of time.