Global Development vs The Agile Manifesto

[article]

Agile. Global. Development. Think those three words don't go together?

Macadamian Technologies has been doing Agile global development for a couple of years now. We have permanent offices in Romania and Armenia, and we have long-term deals with developers in two other countries. Most of the projects we're doing now have some kind of global component.

Ah, but you're wondering, "Sure it's global, but how can it be Agile?" Okay, so let's look at the Agile manifesto, respectfully copied in its entirety from agilemanifesto.org:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In the rest of this article, I'm going to go over each of those bullet points, talk about the issues involved, and show you our solution.

Individuals and interaction over processes and tools...

Issues:

Okay, so what happens when individuals are in four different time zones? What kind of "interaction" can possibly happen then? Face-to-face collaboration on a daily basis would mean earning a lot of air miles and developers having permanent jet lag; better hope those airports have wireless access...

Not to mention the cultural issues. North American school systems prepare students to solve individual problems, and in North American culture, we prize initiative, something that may not be as valued in other societies. That's just the start of cultural conflicts that might come into play.

Add in something else-not the society's culture, but the culture of the corporation that other developers are used to, and you've got one big interaction problem.

Solution:

Oddly enough, we've found the solution to the problem of interaction between individuals lies in those tools (and, to some extent, processes) that the Agile manifesto doesn't value so much.

Gotta cut the manifesto guys some slack: we're probably not talking about the same tools. They're probably talking about being slavishly handcuffed to Proprietary Source Control ToolTM and Proprietary Task Reporting SystemTM, while we're talking about Skype, IM, call conference bridges, and anything else that connects people. After all, when they wrote the manifesto in 2001, wiki-anything was just a gleam in Ward Cunningham's eye.

The tools we use these days are all about individuals interacting. Like I said, Skype, which can be a better phone than a phone, letting you write stuff when verbal communication goes opaque; IM, which makes firing off a quick question to someone across the globe as easy as yelling over the cubicle wall; and call conference bridges, which have certain advantages over catching a flight across the Atlantic (though the movies aren't as good).

But most of all, we love our wiki (We use Atlassian's Confluence). I'll talk more about this during in other sections-probably until you're sick of it, gentle reader-but there's nothing more agile than a wiki. When you can't bring the team together in real space, a virtual one does almost as well.

Making a team space on a wiki won't let you look your teammate in Nagpur in the eye, but it will let you get on the same page. It lets everyone share any relevant information (or that hilarious Dilbert from yesterday), and gathers all the documentation in one, searchable space.

A wiki space (and allowing global partners access to your company wiki) is the beginning of something really important to Agile global development-the creation of a team culture that transcends local culture. The wiki will reflect values that global partners will pick up on. For example, Macadamian values include:

  • Encouraging questions
  • Dealing with work blockages: making your best guess, moving on to other things, asking for help
  • Responding to changes to the plan
  • Being wrong isn't fatal-better to take initiative and fail than to sit on your butt, afraid to move ahead

Making a team culture isn't easy, and it probably won't happen quickly. It's a long-term goal. Companies have typically outsourced well-defined projects, so global developers are used to being told what to do and how to do it, and aren't used to taking initiative.

The wiki is only the start-you, as project manager, have to live those same values out front, where global developers can see you. That includes not hiding your own mistakes (Oh, come on, you know you've made some whoppers.), praising people for taking initiative, deferring decisions to other people when their kung fu is better than yours, and publicly asking for help yourself when you need it.

Working software over comprehensive documentation

Issues:

Yeah, but documentation represents safety-you tell global developers what to do and they do it. Can you really expect global developers to create a version 1.0 product from a napkin sketch? Will they even know where to start? It's just plain easier to do a monolithic design document up front.

Not to mention that bootstrapping a global team is a challenge: you don't know all the issues that might come up. So many things are out of your control, including the hardware and software environments.

Solution:

Yep, it's going to be harder if the project is a 1.0 initiative. When you're working on a revision of an existing product, you're going to start with a working project and you'll just have to concentrate on not breaking it.

To do that, we use a highly iterative working style with goals defined for each week, and code "patches" (A patch is a delta of changes that the developer has made.) submitted to an online mailing list for peer review every day.

We're big believers in putting code through peer review before it's added to the source control. We use a peer review process that evolved from our open source experiences, and if I went into the details of that here it would take a while and this article would just get out of hand. So I will just say this: find a way to review all code for bugs before you add it to the source control. (Contact me if you want to hear more about our peer review system.)

The small iterations and peer reviews let you keep an eye on things and correct them before they go off into the ditch-but the goal is not for the project lead to maintain control. Instead, you want to get the developers to the point where they start to police themselves, so they find bugs in each other's code.

Ah, you say, "he's avoiding the version 1.0 issue." Nope, I've got stuff to say about that, too.

If the project is highly technical and it needs to get ramped up fast, consider assigning an architect for the short-term to create the stubs and put the framework in place. While the architect is doing that, your team can work on getting up to speed.

Now I'm going to bow down at the altar of wiki again: use your wiki to create the "just enough" documentation that the project needs. Instead of a massive design doc, each contributor can add what he's doing as he does it. That way you avoid a spec of biblical proportions in favor of Agile documentation where every word is gospel.

Customer collaboration over contract negotiation

Issue:

Okay, now this is an unsolvable problem. A global development team just can't collaborate with the customer the same way that an onsite team can.

Solution:

Why not? I've already talked about how tools can close the gap between time zones. All we have to do is apply the same philosophy to the customer.

To me, this kind of transparency is the customer's right. In our projects, the client is a major player. Every client gets access to everything every team member does: the client can read the developer mailing list, phone the team lead at any time, and post stuff to the wiki. The customer should have the right to contact any developer by email, Skype, or IM.

Even if the client is less technical and doesn't find bugs in the code or have suggestions for test strategies, he does have the right to ask for a working build any time. And giving it to him lets him evaluate our progress and request changes. Luckily, giving the customer a working build whenever he asks isn't a problem(See previous bullet point) because our peer review process catches bugs before they make it into the build. So we can be sure that the build from any random day isn't going to nuke the client's computer on install.

Responding to change over following a plan

Issues:

There's no way a global team can respond to change like a team that isn't spread all over the globe. Due to the different time zones and communication issues, they just can't have the same quick turnaround.

Besides, global developers like plans. They're used to working that way. They're also better at following a plan than turning on a dime.

Solution:

Instead of changing the plan, plan to change.

Short iterations. Lots of small milestones. Contributing to the project in a democratic, wiki style. Soliciting customer feedback. All these things will help a global team respond to change quickly.

And the time zone problem isn't as bad as advertised. Let's say that you're in Silicon Valley and discover an issue at 3:00 PM on Thursday. But you can't tell your developers in Nagpur to fix it because they're asleep. So, until close of business, that issue won't be fixed.

However, if you send the email right away, chances are they will have made good progress on the solution by the time you have your Friday morning coffee-after all, by your 9:00 AM, it's their 9:30 PM and they will have had all day to work on it.

But I won't lie to you; there's some truth to the idea that global developers are less familiar with the Agile style and are more used to working on well-spec'ed out projects. This is where you have to go back to the beginning of this article and read bullet point #1 again. It's all about you building a team culture that means responding to change is the rule, not the exception.

My last point doesn't have much to do with the Agile manifesto, but I want to make it anyway. Building an Agile team culture with a global development team isn't easy, and it may take time for team members to get comfortable with it. You can't just say to a person who is used to working on well-defined products, "Hey, you get to be Agile now!" and have them shouting yippee.

You can't expect this to happen overnight. As a result, don't bother trying it on a short-term project. But if you're entering into a long-term partnership with a global team, it's worth the time and effort.

So, are you ready to say the words "Agile global development" in the same breath yet?


About the Author
Jason is Director, Project Management at Macadamian Technologies, a software creation partner that specializes in taking next generation products from napkin sketch to market-ready. You can reach him at [email protected].

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.