Pages

Sunday, August 09, 2009

Inventing your own Light weight methodology - A Case study


In the past I had implemented a project by inventing my own light weight methodology and I am sharing my experience in this post.

Even though the inspiration came Agile values and principles, but didn't follow any specific methods like XP or Scrum as a whole.


Context:
1. "<5 " member team
2. Collocated team (dev team in India and technical SME in US)
3. Web application development
4. Team composed of members who are fresh out of college and in equal proportion experienced members
5. Team was well aware of the technology
6. The team members were passionate about learning the new technology and hard workers too.


I was an architect and also played a role somewhat like a Scrum Master.

1. Every day in the morning when the team had arrived, we used to sit in a circle and ask individuals plan for the day and if they need any help in resolving any issues. This could be compared to a scrum meeting except that we didn't ask the 3 questions nor we stood in a circle.

My observation is, it is not that the ceremony which matters but the values behind the ceremony that makes the difference.


2. When each team member used to speak out about his plan, I used to make a list of action items on a white sheet of paper. Let us call it as Action List.

If your team sits closely in cubicles and does not have access to huge team rooms, white boards or post-its, then the above method of writing on a white sheet of paper could help.


3. Many a times the onsite team would have done some review of the application and would have suggested changes through email. I would add them to the Action list

4. Once every one has completed sharing their action items and impediment list, they used to take a quick 10-15 minutes break and return back to work.

5. The action List was kept at a visible location so that everyone can see.

6. The team members used to glance through the Action list, depending on the priority (discussed verbally) they pick up the task and start working on the same.

7. After completing each task, they would come back to the Action list sheet, take a look at it, pick up one of the pending tasks voluntarily. As soon as they complete any task, they used to put a check mark on the same.

8. There was a progress review in the afternoon and at the end of the day another review on where we stand. It was more like a retrospective but without much rituals like +/Delta analysis or so.

9. At the end of the day before the team used to leave work, we used to quickly talk about the tomorrow's plan.

10. Informally the team used to discuss about the design, coding and other issues during the cafe breaks too.

11. As an architect I used to sit and code, and at the same time if any of the team member's are stuck then I used to jump in to help them out. If I can't help them, then I used to reach out to other experts through my contacts and get them the necessary help.

12. Estimation is done by the team. Since the team had experience with the domain and technology, based on past experiences, they used to come out with the estimates.

13. Couple of other good engineering practices include,
  • Daily code reviews
  • peer reviews
  • Continuous integration
  • Daily builds
  • Regression testing using Selenium
  • Unit testing using JUnits and EasyMock
14. Interestingly we didn't have a separate testing team, it was the developers responsibility to test it thoroughly and release it to the customer for UAT.

Above method that I had applied is a very simple one and does not have too many ceremonies attached to them.

This project was successful, team and the customer was happy.

1 comment:

Derek Neighbors said...

I think ultimately the last line should be the benchmark of any methodology.

This project was successful, team and the customer was happy.