What is Agile?

AGILIS or “Agile is Scrum” as the name predicates is Verbat’s take on the Agile methodology with an emphasis on Scrum in the geographically distributed landscape.

The potential advantages of distributed development are:

• Access to a larger pool of skilled talent.
• Lower development cost.
• Quicker time to market.

Conversely its disadvantages are:

• Communication: When you’re not face-to-face you are unable to observe body language which embodies a lot of valuable communication cues.

• Temporal: Finding common working times, increasing the communication challenges. To combat these challenges you will find that you need to create more documentation than you normally would.

• Cultural: Different work ethics, commitment, holidays etc.

• Scope Creep: Scrum allows requirements to be flexible and if tasks are not well defined; it will lead to scope creep and incorrect effort estimates. In a distributed environment this can be a volatile combination.

• Effort: How a Distributed team with developers operating from India (possibly with a scrum master) comes to terms on effort estimation with a product owner situated in another country?

• Project Progress: How can the progress of a project be communicated to the stakeholders?

Even though the disadvantages outweigh the merits of a distributed agile development, it is by no means a deterrent. If this has piqued your curiosity, keep reading the rest of this article to find out if this is a good fit for your organization.

The 2014 Software Development at Scale Survey found that 39% of teams are (mostly) co-located, 23% of teams were near-located, and 38% of teams were far located.  (Note that this survey only asked about development team members, not whether stakeholders were also in the room).

Previous surveys have found that it is rather rare for stakeholders to also be co-located with the development team, the implication being that 39% is a very optimistic estimate for how co-located agile teams are.

As you can see in Figure 1, the 2012 Agility at Scale survey found that organizations are having success (the green bars) at all levels of geographic distribution. It also indicates that some organizations are failing (the red bars) at each level of geographic distribution.

The implication of this study is that although it is possible to succeed with agile development regardless of how geographically distributed the team is, that there are no guarantees that you will in fact be successful.  This is why the advice in this article should be of interest to you.

Teams co-locate because it maximizes their ability to communicate in person. Working in the same room is core to all the Agile methodologies, including scrum. As Ken Schwaber, author of The Enterprise and Scrum, said

“The best communication is face to face, with communications occurring through facial expression, body language, intonation and words. When a white board is thrown in and the teams work out design as a group, the communication bandwidth absolutely sizzles.”

Given that communication is such a significant part of the efforts involved in delivering software, why then are distributed teams so prevalent?

The answer speaks to the reality of doing business today: As companies need to have a global presence, to access global talent and to develop outsourced options. Although co-locating your team is the recommended, optimal approach for implementing Agile processes, many teams are unable to do so for critical business reasons and must learn to follow Agile principles and practices in a distributed development.

All projects require some documentation. On agile projects, however, documents are useful only if they’re barely sufficient to serve the design, delivery, and deployment of a working product in the most direct, unceremonious way.

When you work on an agile project, however, you concentrate on the documents necessary to support product development. Agile approaches dramatically simplify the administrative paperwork relating to time, cost control, scope control, or reporting.

As Martin Fowler puts it adequately,

“Agile methods downplay documentation from the observation that a large part of documentation effort is wasted. Documentation, however, becomes more important with offshore development since the face to face communication is reduced.”

Mat Simons of ThoughtWorks Clarifies this further

“There are two keys to successful documentation on agile projects. The first is finding the point of “just enough” documentation. This is difficult to determine and will vary by project. Fortunately, the iterative nature of agile development allows you to experiment until you get it right. The second key to successful agile documentation is to not get attached to it or have unrealistic hopes of keeping it updated. Documentation must be created to serve a specific purpose, and after it has served that purpose you’ll all probably have more important things to do than keep updating the documents”.

As this is a extensive topic, I am covering this in two parts to give you a better sense of my understanding of Agile.