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
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.
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