Hello Agile!!

BANGALORE, INDIA: After Eight years in the software industry, I have finally boarded the Agile Bandwagon! Having experienced waterfall based project execution methodologies and its variations I was quite eager to experience Agile. Joining Thoughtworks gave me this opportunity.

This is short write-up on my view of the Agile methodology followed in my team in Thoughtworks.

Agile methodology involves following a process that is flexible. Agile is more about people than the process itself. The methodology encourages a lot of people interaction. With this knowledge of Agile, I joined an Agile team in Thoughtworks.

The entire team sits around a single long table. This resembles a dinner table with laptops and workstations taking the place of the dinner plates. This is the first step in encouraging more people interaction – a practice recommended by Agile.

Absence of partitions and above all privacy can be deterring factor for a new entrant from a traditional cubicle based environment. However, this is not as bad as it initially appears. This mode of work is enjoyable; once accustomed to this style of work, the cubicle based environment can be real damper.

My project, for a US based client, consists of two releases. Each release delivers a subsystem of the project that goes into production. Every release is divided into several iterations. Each iteration is two weeks in length. An iteration delivers a set of modules of the project.

Its team’s responsibility to ensure a working system (that can be taken to production) is available at end of every iteration.

The project has an inception phase wherein all the requirements are collected. Each requirement is called a story and a Master Story List is the outcome of the inception process. A release plan is another major deliverable of inception. Implementation of the stories is the next stage of the project lifecycle.

Iteration-0 involves the Business Analysts’ (BA) selecting the stories for analysis from the master story list. These stories have to be implemented in Iteration-1.The choice of the stories is completely in agreement with the client’s requirements and priorities.

Iteration-0 allows the Developers (Dev) and the Quality Assurance (QA) personnel to setup the required infrastructure for the implementation phase starting from iteration-1.

As you might have already guessed, BA always works one iteration ahead; during iteration-1 they work on stories for Iteration - 2.

Each iteration (starting from iteration-1) begins with an Iteration Planning Meeting (IPM) in which the selected stories are estimated by the developers in presence of client, BA and QA. The selected stories go onto the story wall.

A story wall records the different stages in the lifecycle of a story during an iteration. A story typically passes through these phases - Ready to Play, In Progress, Dev Complete, BA Sign Off, QA Sign Off and Client Sign off.

Each day begins with a Standup - a meeting with the entire team standing in form of a circle (or any other geometric/non-geometric shape). Every team member explains his activities of previous day and the plan for the current day. I guess Standup is a way to prevent the wasteful status update and other meetings that exist in the other project execution methodologies.

Every activity of development is done in pairs - including coding. It usually takes a while to get adjusted to coding with someone watching! Until the realization dawns that both are peers with a common goal of getting the task completed.

One of major advantages of pairing, as I see, the learning you get from your peer. It also removes the fear of working on new technologies and trying new things since you have someone to support or lead the way. It’s the pairs that sign-up for every activity pasted on the story wall.

Every implementation is done by a pair; consequently every line of code is gets reviewed by one of the members of the pair during the time of coding itself. Further, code review also happens during pair rotation; a new pair starts working with code. As a result of this process no separated code review phase is recommended in an agile project.

However, practically there is definite possibility of not so good implementation to exist. This may be the consequence of the capability limitation of the members pairing. It’s also possible that the new pair (after pair rotation) may just get on with the implementation without to refactoring the existing not so good code. Such cases do exist in few of the modules in my current project.

Another important activity of the development phases is testing. Testing is given a lot of importance in my team. Test cases are valued as much as the code! This is a welcome change from my pervious work environments where testing was a wrap-up activity. Having test-suites provides the developers the confidence to improve code and fix issues without the fear of being caught unaware by the side effects.

In addition to testing, another activity that involved during development is the documentation. Documentation is not given significant importance in my team - this usually makes the system understanding difficult. I have heard Agile advocates documentation on need basis and not as a process; so the decision is left to the team. In my project - a simple overall block diagram of the layers in the system and the communication mode/data between the layers can give a person (trying to comprehend the system) a good picture of the system.

The development phase of the iteration ends with a Showcase which is demo of the modules built during the iteration to the client.  Showcase is good way for both parties the development team and the client to exchange feedback.

Showcase allows the client to see the system evolve; helping client to make better informed decisions during the course of the project. Any changes suggested by the client are taken up as a new story to be implemented in the forthcoming iterations.

Client is involved in all stages of the project – inception, release planning, IPM and Showcase. A daily conference call is also in the schedule of the project. The client is aware of team members in the project and can contact anyone in the team. It’s the same for the team members too. Interaction with the client is by no means restricted.

A team here has 3 roles – a BA, a Dev and a QA. A flat structure exists, with no pyramid hierarchy. This structure works really well in getting the job done. Common issues people might face with this kind of structure could be ego clashes among the least and most experienced professionals.

The mode of functioning of the whole team and its structure is good, sometimes better than the Waterfall and RUP based methodologies. I believed this after experiencing few iterations in the team!

Nothing is perfect – it also applies to this system of Agile. Agile emphasizes on people, getting right people on board is a must for this system to work. The advantages certainly outweigh the disadvantages in this Agile system. Agile development process is definitely worth a try.

It’s been a good start for me here since I now believe the thought works!