Extreme Programming at Agile Velocity
718.891.1451

DISTRIBUTED AGILE

What is Distributed Agile?

Distributed Agile is the implementation of the Agile software development model employed in a remote fashion instead of conducted internally, solely within a software development organization.  For those who are familiar with the concepts of Agile software development, that might sound like a contradiction.  That is, the Agile method is all about small groups of developers, ideally around six or seven, working very closely together in intimate collaboration in a highly iterative production manner.

So how can some or all of a team be located physically far away and still have the process work?

The answer to that question is for the “core” of the team to still be located all together – in our case, in Ukraine – but have other interfacing elements of the Agile model located in the US.  Specifically, in Agile you start with the role of the “Product Owner,” which is usually the client.  The Product Owner is who specifies what the software to be built needs to do and why.  Product Owners directly interface with a Scrum Master, who is the leader of the Agile development team.

The first tasks that a Product Owner and a Scrum Master perform are to sit down together and plan a Product Backlog.  A Product Backlog is essentially a Product Development Roadmap that has been segmented into specific functional development objectives and then prioritized.  It reflects the definition of User Stories and Use Cases of how users of the software will interact with it.

Once that list of software items to be built is established, then the Scrum Master sits down with his development team on Day-1 of a Sprint and plans out who is going to do what.  A Sprint is a defined window of time, usually 2-4 weeks in length.  Another task of the Scrum Master is to establish a Burn Down Chart.  This chart is a list of all the tasks needed to be accomplished during the Sprint, who is assigned to complete each task, plus a budget of estimated hours for each task that is believed it will take to achieve it.  Then, each morning the team meets with the Scrum Master for ten to fifteen minutes and reports on their Burn Down from the previous day, and they identify any issues blocking them from completing their assignments, etc.  This process allows the Scrum Master see if they are on schedule, i.e. if the budgeted amount of hours is tracking to the percentage of completion of that task.  If not, then he can make adjustments.

When the Sprint is complete, it is then reviewed, and the completed element of working, debugged, and quality assured code is provided back to the Product Owner to demo its functionality.  If anything is wrong, then new tasks are added to the Product Backlog, reprioritized, and the process repeats itself, moving into the next Sprint.  What is also very important is that when the deliverables are demoed, the Product Owner is afforded the opportunity to see what may have been a good idea on paper, but in reality does not look very useful or appealing.  Thus, this iterative development model allows changes to be made quickly and nimbly, and priorities to be redefined on the fly.  This is how you end up with working code that is truly useful, instead of a long list of features and functions that users may ultimately rarely or never use.

So from the above description of the Agile process, that all seems to make sense when everyone is clustered together, but how does this model work when the development team is remote?

The answer is that, as noted previously, the Product Owner is located onshore, who typically is the Client.  The Scrum Master that interfaces with the Product Owner is also onshore, meeting face-to-face with the Client, working collaboratively to turn business requirements into software product development specifications, and ultimately into the prioritized Product Backlog.  However, in the Distributed Agile model, there is one additional player: The Tech Lead.

The Tech Lead is the team leader in the remote location who serves one or more specific roles.  First, he overlaps with the onshore Scrum Master to perform the daily Scrum Reviews in the remote location.  Second, he serves as the Project Manager maintaining the Burn Down Chart for that Team.  Lastly, he may himself be one of the senior developers taking on some of the development assignments himself.

This model then allows the Scrum Master onshore in the US to serve as what’s called a “Scrum of Scrum Masters” – a kind of super-role, where multiple subordinate Scrum Masters from multiple remote teams are exchanging information with him on their team’s progress on a daily basis.  It’s the best of both worlds: the onshore side of the equation remains intimate and engaged hands-on with the Client, and the remote team works together in one place in the highly collaborative and iterative model.  The accountability and management now flows through a team Scrum Master, as usual, but that team Scrum Master interfaces directly to a Scrum of Scrum Masters, who after the initial planning phase, only needs to serve as an information conduit, and troubleshooter when needed.

Thus, the flexibility, quality and velocity of Agile is enjoyed, right along with the cost effectiveness of a remote software development team.  This is Distributed Agile.

Do the onshore and offshore resources ever meet?

Yes, they can, and is strongly recommended that they do so.  It is highly effective in the Distributed Agile model to periodically meet face-to-face with the entire team.  For example, it is very common at the beginning of a team engagement for some core team members to travel from Ukraine to the Client’s location and work side-by-side with internal employees for a couple of weeks, and then to return to Ukraine to begin the development Sprints.  Likewise, many Clients find it very useful to travel to Ukraine at least once a year to visit their team(s), conduct planning sessions for the future, engage in team building activities, etc.  The bonding and camaraderie that is cultivated in these visits is invaluable.

In addition, it is recommended that video conferencing be used for as much information exchange as is possible – whether that be via Skype or other higher-end systems.  Often body language and facial expressions can convey far more than words alone.

Best of all, done right, Distributed Agile works!