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 ......