Pages

Monday, March 31, 2008

Building an Agile team

Recently I got an opportunity to build yet another Agile team and wanted to share some of my experiences around it. Here is some initial context before I begin sharing:
  • This team has around 5 people , with 2 junior members(<3>
  • My company has a strong CMM background and at the same time, provides free hand to tweak the methodology or experiment with new techniques.
  • The customer is not worried about whether it is CMM/Agile.
  • It is a distributed team spread at many places in India.
  • The client sits in US
  • Project is research oriented than a development project

When I started recruiting team members and started the project work, I didn't tell the team members anything about Agile or any jargon from Agile methods. I started with the simple technique of having daily meetings (AKA stand up meeting in Agile methods). Here is what we do during daily meeting, every day at the same time we have a call in the morning and a call in the evening. Team members who are in different locations dial in during the meeting. Each person would share their plan for the day before taking the coffee break. All this information collected during the call gets updated on to the Wiki pages.

In the evenings, we discuss what we have achieved since morning and reason for not achieving something. We don't use this information to crucify somebody, but we have built this tradition to help the person in need. People are eager to share the issues and ask for help immediately.

I know that, this type of stand up meeting is a bit different from the traditional ones followed in Scrum or XP, answering 3 questions. I have realized that, many a times the Scrum meeting becomes monotonous and people answer those 3 questions for the sake of answering. In fact, in one of my friend's company, the client has been adamant about having a daily Scrum meeting by answering the 3 questions "at any cost". Many a times, the team members used to cook up answers for the Scrum meeting as they didn't have many things to answer during the call. I have realized over the last few years that the practices should not be enforced on the team members. It should be slowly sold to the team and the value should be exposed to the team members through various techniques. In my case study, the team missed couple of calls however suddenly they realized that they are losing the focus on work and things started looking chaotic. They made even a firm decision not to miss daily meetings.

Usage of white boards

Once the work starts in the day, we don't have any formal meetings but many of them are through informal discussions. If somebody has a point to share or want to discuss they will go to the white board and write it. We have a regular customer call and we read the points written noted on the white board to discuss any roadblocks with the customer. Because of this, we don't forget many things.

Usage of Spreadsheet

We use spreadsheet as the project tracking tool. On a daily basis we just update the status of each task. As and when we come across any new task, it gets inserted into the spreadsheet. It is amazing to know, how many "unplanned" tasks gets added into the project planner. This tool was created iteratively. As and when we found the information to be useful, we used to either create a new column or add a new status or anything else.

Use of Wiki

All documents are directly typed on to Wiki, no documents gets circulated via email.

Client meetings

Every team member whether junior or senior attends the regular customer call. In turn this has resulted in more efficient spread of knowledge and efficiency at work. Most of time, in many projects run in India, I have seen only the project managers/architects participating in calls with the customer. This results in team members not understanding the reality and never getting to know the first hand information. There are pros and cons to this practice(at least in the Indian context), but I feel there are more pros than cons.

Our team is still young and I am in the initial stages of buidling this Agile team. I still have a long way to go before I introduce retrospectives and other good practices ......


Monday, March 10, 2008

Self organization and Swarm Intelligence

Recently I read this article about Swarm Intelligence. This article talks about amazing efficiency of the insects like ants, wasps, bees, etc. The scientists have researched the behavior of these insects and, have proposed ideas that could be used in our day to day business. The portion of the article that caught my attention was the 3 characteristics of social insects that is making them successful.

They are

  • Flexibility
  • Robustness
  • Self organization
Flexibility and robustness is influenced by self organization. The articles claims that
Through self organization, the behavior of the group emerges from collective interactions of all individuals

In the case study given in the article, the ants, bees don't have a leader directing day to day activities. The social insects seem to have two key priorities in their life time, finding food and defending against enemies. It seems to be a simple life as compared to human beings :-)
There is no need to have a backlog of tasks to monitor of the ants/bees. They get up in the morning, go in search of food, bring it back to their nests and live happily.

I was wondering why can't we be self organized like them(atleast in our work life) ? Specifically, Agile methods recommend self organizing teams. My take on this is, we as human beings can't be like ants, bees. It is very difficult (even though not impossible) for human beings to self organize themselves at work. We have many needs, desires, characters, emotions. Each of these parameters affect our thought process and decision making ability. We have our own individual identities as opposed to the ants and bees. May be these social insects have their individual identity, but looks like they give higher priority to the group rather than their individual wants/desires. I think we can achieve self organizing teams within our projects, provided we keep aside our individual priorities and work only towards the projects goal.

couple of questions that is coming to my mind..(for readers)
  1. Is your project leader capable enough to create a strong goal that would make you to lower your personal priorities ?
  2. Have you seen any projects with self organizing teams ?
  3. What does it take to become self organized in your project ?
  4. Are you willing to lose your identity for the project's goal ?
So bottom line is, it is easier for ants, bees and other social insects to self organize as compared to us, human beings.