Thursday, November 25, 2010

Agile Development

Last couple of years I have been working on a project where we use Agile Methodology for software development. It was a great learning experience for me to move from the WaterFall Model to Scrum Model.

Team Foundation Server(TFS) provides out of the box support for project management and for practicing Agile Methodology for software development. TFS is a great tool not just for source control but also has so many features geared towards agile software development. The basic idea behind following agile development is that, you divide a big chuck of work into small pieces and then decide which pieces are high priority and take that work and deliver it end to end at the end of each sprint. With this kind of approach you have something ready by the end of few sprints and if you feel like there are design flaws you can catch those early in the development cycle.

The way we used to practice Agile Development was, we broke the whole team into 2-3 smaller teams with one team consisting of 2-3 devs, 2-3 testers and 1 Project Manager. Generally project managers meet before the sprint starts and decides the priority of the  Product Backlog Items(PBI). Project Manager tries to make sure as much as possible that the PBI's are clear and have a done criteria. i.e what is expected by the end of the sprint from that PBI. It is the responsibility of the team members (Dev's and Test) to make sure that they have clear understanding of the PBI. Project Manager then hands over the list of PBI's to be completed in that sprint to the Scrummaster. First day of the sprint, is the planning day where,  in the first session, Project Manager explains, the list of PBI's to the team and what is expected out of those PBI's.

There is a storypoint assigned to each PBI and  the team members give there estimates for each PBI. Story Points are useful because after couple of sprints, you can calculate the velocity of the team. Story points are generally given as one of numbers in the Fibonacci series.

Second part of the planning meeting is where, PBI is broken down into Sprint BackLog Items(SBI). These are the workitems that can be assigned or owned by the team members. Basically PBI is further broken down into small chuck of work. Team members give there estimates for each SBI. Generally work is broken down in such a way that no of hours required are less that 6-8 hours.

Team has to commit that the work they take will be completed at the end of the sprint. After the planning meeting no new work is taken for that sprint. If  a team member gets blocked it the responsibility of the scrum master to unblock them. Daily standup meetings are done where team members give there status to the whole team regarding what work was done and if they are blocked on anything.

At the end of each sprint there is a stakeholder demo meeting where the team presents  the work that was completed in the current sprint. Other advantage of this is, the other teams can get an idea of what work is happening. There is also a retrospection meeting which is conducted by the scrummaster to see how the process can be improved. Team members generally will give there opinions about what went well in that sprint, and what things can be done to improve the process.

Like anything else in life, initially there is always some struggle/tough period, but once you get the hang of it, its very effective process. I love working in Agile teams! :)

I hope this helps someone :).