Initially, agile techniques were targeted only at small, co-located teams usually, but now larger teams that are geographically distributed have adopted agile. How has that change come about and does distributed agile really work?

Siddharta: Right, so agile always talks about co-located teams and even now most people agree that co-located teams are always going to be more productive than distributed teams. But there are a whole lot of other things which can decide to make you go in for a distributed team – for example availability of skill sets or strategic decisions by the company. There are many things which tell you, you need to go in for a distributed agile project. We’ve seen over time, distributed agile has been becoming bigger and bigger. In fact, there are a lot of things being distributed.

Jeff Sutherland, one of the scrum founders, talked about teams in the US and Russia doing distributed agile and how productive they are. So there are a lot of people who are really succeeding in doing distributing agile. But the thing is to succeed in distributed agile – you need to make a few changes. Obviously, communication is not going to be as good as if everyone is co-located; similar bunch of practices which ensures that you try to maximize the amount of communication available, it might be a shorter iteration so that you can get further feedback.

You try to split groups not amongst teams – so you don’t want to have developers in one location and testers in another. But along functions or bits of functionality. So you might have developers and testers working on one part of the system in one location, and developers and testers working on another part of the system in another location. And you want to maximize the amount of communication bandwidth that you’re going to build through chat, voice messaging or through cameras and things like that. If you make these kinds of changes you can succeed. I know a number of companies, not just out of India, who are doing distributed agile and are successful.

Selina: Ok. So if you look at it, the nay-sayers of agile say that agile practices don’t give too much important to design, or the design aspects. But design is vital to a product’s long-term success. What do you have to say on this?

Siddharta: This is something that you hear very often – that agile teams don’t do design, there’s a similar thing that agile teams don’t do documentation. But these are kind of misconceptions. A lot of people understand agile to be coding without design, without documentation and equate it to adhoc development. And nothing could be further from the truth.

We need to make a slight distinction between not doing design and not doing Upfront design. So the term used in agile circles is Big Up-Front Design (BUFD). What agile does not do is to get all the details upfront and do a BUFD. So we don’t have a design phase like your typical but agile teams do do design.

As and when they keep incrementing features they revisit the design. And design is something that you look at throughout the project, it’s not technically something at the beginning alone. At the end of every iteration, it is re-evaluated; re-factoring is done constantly to improve the design. This is something which happens continuously. So agile does continuous design and evolving design, but they don’t do BUFD.

So it’s not to say that agile doesn’t do design, in fact it does it right through out the project development. Constant evaluation and redesign.

Selina: So how is design planned? In every sprint or whenever it’s required, you take a look at it?

Siddharta: Whenever someone is recommending a feature, they think about whether it fits in the existing design or not. If it doesn’t fit in, then assuming you are all co-located, you can take a few people and decide these are the kind of changes you need to make and then go ahead and implement them. So it happens on a day-to-day basis, week-to-week, sprint-to-sprint basis.

Read the rest of the interview here or listen to the audio here

1) Continuous Integration (CI) : Whether you are following a Dedicated or Time & Material or Fixed-Bid type of engagement, CI is a very useful and proven Agile tenet. The Root Cause Analysis of the issues that come up during the last stages of a typical release will point to Integration issues as one of the root causes.
There are tools around which can be used for automatically building and deploying your code at very frequent intervals (or on a need basis) so that the integration issues are closed as and when they are found, instead of accumulating till the end.
One good example is CruiseControl, which has versions for Java as well as Dotnet environments. You could visit the thoughtworks site for more info on CruiseControl.

2) Pair programming: Pair programming is an agile tenet which advocates having a pair of programmers work together on all coding aspects, instead of working individually. Compare this with a typical scenario where the programmers work individually for all
their work. 100% pair programming is a controversial topic, and we will not get into that debate in this post. But what is not controversial, and indeed beneficial, is to use pair programming in a contextual manner. That is, whenever you are faced with a difficult problem, have 2 people work on it. That has proven to be much more productive than the aggregate work done by them separately. Also, there is a knowledge backup within the team for all the difficult sections within the codebase.

3) Small releases: Have an overall fixed-bid contract which allows about 20% deviation in the scope. Then have smaller iterations where small chunks of feature requirements will be identified, zoomed-in, designed, implemented, tested, and be ready to be deployed.

In other words, it is very common to find the fixed-bid billing model tied to the waterfall methodology. There are inherent problems with the traditional waterfall software developement life cycle (SDLC) methodology, and it is better not to mix waterfall and fixed-bid. Pictorially it can be represented this way:

Requirements->Design->Coding->Testing->UAT->Golive

Feature set #1—>Feature set #2 —>Feature set #3
Where, the first line indicates the typical approach using Waterfall model the second line indicates the approach using smaller closed iterations (Agile model), with the various phases of an sdlc compressed into each iteration.

The main difference is that in the waterfall model, the compartmentalization is in terms of phases, whereas in Agile, the compartmentalization is in terms of features—ie, in Agile all the phases will be implemented for each set of features in the order of decreasing priority of features. We will talk more about the mechanics of this, in a future post.
In summary, some of the Agile tenets can indeed be used in a Fixed bid model, actually reducing the heartburn for all the stakeholders in the client’s as well as the vendor’s side.