Sunday 8 February 2009

Agile Methodology

The first time I heard about the Agile Methodology was when I was working on my previous project. We were using RUP, however being a large scale project things weren't quite going according to plan.
A few of our senior software engineers got together and decided to take the Agile approach. It worked very well for us and we pulled ourselves out of the rut and delivered on time, which the client were very happy about.

The basic gist of Agile is collaborative working. The following exist in Agile development:

  • Product Owner

  • Product backlog

  • Sprint team

  • Backlog

  • Stories

  • Points

  • Tasks

  • Burn down chart

  • Velocity

  • Planning Session

  • Stand up meetings

  • Retrospective



Generally there is a business problem that needs to be solved through the development of software and the person responsible for this problem is the product owner, who has a product backlog of business problems.

A team or multiple teams known as sprint teams are formed for this purpose. They generally consist of developers, testers, business analysts and a scrum master. Sometimes (but not commonly the product owner or the product owner proxy). The team is a self organising, multi tasking team. The team will work on the software in sprints. A sprint is a fixed amount of time (between 2-6 weeks).

At the beginning of each sprint the team is involved in a planning session where they determine the velocity that they will work at. During the planning session, the team take the backlog and prioritise what needs to go into that sprint. They then divide these up into stories and assign points based upon the velocity. The points are assigned using planning poker, and team members have to estimate individually, then once every team member has indicated their estimate a consensus is reached based upon discussion.

After the planning session the team work on the tasks (these are the stories broken down into smaller components) in the sprint and every day a 15 minute daily meeting occurs where they discuss their progress amongst other team members.

There is no outside interference when a sprint team is working. At the end of the sprint there is generally a demo to demonstrate what was achieved and a retrospective meeting held for lessons learnt.

This is the basic gist of Agile development. For details please visit the link above or read Scrum and XP from the Trenches.

On my previous project I worked alongside a sprint team, mostly working on support work for the teams so I wasn't really involved in the core development for the sprint team.

When I joined my current project, we were encountering similar problems to those of my last project. There were a few of us from our previous project who joined the current project. Once again a couple of the senior guys suggested Agile development.
Once again this worked very well and we were able to deliver Release 1. For Release 1 our business analysts were the product owners. Once again, I wasn't involved in the core development within a sprint team.

My first real experience with Agile development was about a month ago when we started Release 2. I had expressed an interest in being involved with core development work and was finally provided with this opportunity.

This time round the product owner was the client, and their proxies are actually a apart of our sprint teams. I hadn't really been to a planning session before and it was a very interesting experience. During my first planning session, I found it very hard to determine how to allocate points to the stories as I'd never worked on a story (or core development before). We had time boxed the planning session to 3 hours, however it overran due to lengthy discussion about the stories.

We started the sprint and I must say, I found Scrum to be a very effective way of working. The teams work very closely together and having all the developers, testers, business analysts and the client(as the proxy) together meant that the team was very productive. I found that having stories and allocated time for tasks meant that I focussed much more on achieving my goal. Also with everyone sitting together the communication and turn around was excellent.
Including a client member on the team also means that we get a much quicker response back from the business and that they are more sold into the process and ensuring the success of the team as they are also liable.

The retrospective was very interesting also, we were given sheets of paper to write issues we encountered during the sprint and how we could resolve them for the next sprint. The scrum masters then went through the common themes and discussed them. Recurring themes were given higher priorities to over come for the next sprint. Basically, everyone got to have a say.

Our second (and final) sprint for this release started on Monday. I was better equipped for the planning session and able to make sound judgements on point allocations. So far the week has gone well and we seem to be on track.

I will keep posting our progress as the weeks progress :)

No comments:

Post a Comment

Search This Blog