Background
In my current organization we have been trying to incorporate Agile / Extreme Programming methodologies for development activities. In my honest opinion very few people really understand the meaning of Agile. Here are the list of principles on which Agile is based.
Agile Estimation
From my personal experience, people think that having a SCRUM team, two week iteration, an iteration planning meeting and daily standup is all that is needed to say we follow agile methodology. Recently I was part of an iteration planning meeting where few of the folks from process and quality control department joined in to understand the ways in which we were implementing Agile in our project. There were typical questions related to estimation and planning like how do we estimate the time for a user stories, what is the velocity of the team etc. There was lot of confusion around how should we estimate for a particular user story.
http://www.agile-software-development.com/2008/01/understanding-your-velocity.html is a very nice explanation of how velocity is calculated for an agile project.
The scrum master was of the opinion that stories are estimated assuming that 6 hours are ideal for a developer in a day. Hence if a story takes 3 days to complete we will have 3 story points assigned to it. This calculation seems ok until we don't bring pair programming into picture. During the meeting it was told to the quality folks that we follow pair programming. Immediately the question came whether we are taking tasks or stories for the iteration or sprint as it is also known as based on pair hours or man hours. The scrum masters reply was that we select tasks or stories which can be completed based on the available number of man hours. This meant that if we had 6 developers working for 10 days in an iteration for 6 hours daily we will have 360 hours at our disposal. We could accommodate 360 hours of work. But if a pair works on these tasks we effectively end up having 180 hours in which case we could commit to take up the tasks for only 180 hours. There wasn't a satisfactory answer for this whether we should be taking 360 hours of work or 180 hours worth of work. The scrum master kept saying its 360 hours of work which was completely contradictory to the theory of working in pairs. That's where I say that people mistakenly say that they are working in an agile environment.
In my honest opinion if we are religiously following Agile than the estimates should be based on paired hours and not on man hours. There were few good suggestion from Irfan Shah who is a consultant from ThoughtWorks working with our team. Irfan shared few of his previous experiences which were quite helpful. Not everybody likes to pair with other but there are numerous benefits of doing so. From my personal experience I would suggest people who want to use agile methodologies should encourage pair programming. The idea of having an iteration planning meeting is to make every developer fully aware of the tasks we are committed to deliver in a sprint. In true agile way developers should estimate for each of the tasks based on their skill sets and expertise. But this is very rarely followed in real life. Instead of assigning tasks to a developers, team members should pick up tasks themselves. Every member is responsible for delivering the tasks chosen for the sprint. Also while deciding tasks for the sprint availability of the resources should be taken into consideration. Since we are working on a two week cycle if any resource is planning to take long term leave or vacation for a week or so ideally this should be taken into consideration during planning meeting. But I hardly find these things being considered. Unless we account for these factors I don't think we can consider ourselves to be truly agile.
There was also a suggestion to have a formal code review done by using an excel sheet where once the task is completed, developer would make and entry and send it across to the reviewer. The reviewer would review the code and update the code review comments and send back the excel. The developer was supposed to implement the review comments if any. This process was quite laborious and from my previous experience I could say that people would not follow it after one or two iterations. Hence I rejected it outright and suggested that in true agile way we should not make very formal. But before checking in the code get it reviewed by a designer or architect. I am also of the opinion that if we are doing pair programming that in itself is a code review. The pair is responsible for developing code by taking collective responsibility and it should be of the highest standards. If we spend 5-10 minutes reviewing the code before having a formal review by an architect or designer it should give us an indication of any changes.
Conclusion
In the hindsight I would like to say that if a team is following Agile, the whole team should estimate for each story. If we are doing TDD, usually pair programming should be used to improve code quality and stories should be estimated based on paired hours and not on man hours. If we follow the 12 principles of Agile there shouldn't be a separate need for doing a formal code review. We should trust the team members to produce best quality code.
No comments:
Post a Comment