A quick intro to development methodologies
Just as there’s more than one way to pet a cat, there’s more than one way to develop software. At the risk of over-simplifying, you can consider two broad methodology categories: waterfall and agile. Strictly speaking, these are software development methodologies, not project management methodologies. You can plug any of them into your project management lifecycle. Over many projects, your project management methodology will probably come to closely resemble your software development methodology.
Waterfall
The waterfall methodology is linear. The project moves through specific phases in one direction from beginning to end. Waterfall is an old methodology that has fallen out of favor, but hasn’t disappeared. It works best when the requirements are known at the beginning and won’t change. This almost never happens in software projects. Waterfall is more common in construction and civil engineering—it’s hard to iteratively develop an office park or a bridge.
Agile
Agile isn’t really a methodology so much as a philosophy. The Agile Manifesto describes the principles of this philosophy. “Iterate quickly and produce usable software” is the bumper-sticker version.
Agile acknowledges that you can’t know all of the requirements at the beginning, and even if you did, they would change over time. By producing usable software in a short period of time (generally a month), you can get meaningful feedback. This allows you to adjust to changing or newly-discovered requirements.
You can pick any number of specific methodologies (or your own custom blend, since Agile values “individuals and interactions over processes and tools.”) The remainder of this section gives a brief introduction to three of them. If you want a more in-depth treatment, Manage It! by Johanna Rothman goes into great detail about Agile project management.
Scrum
Scrum is probably the most popular Agile methodology. It is designed around the idea of a sprint—a short, fixed-length development window. The team plans and executes the work in a pre-defined period of one-to-four weeks. The fixed, short timebox encourages decomposing the project into small features that are easier to accurately plan. At the end of the sprint, the feature is complete and can be given to the customer.
Scrum features daily “standup” meetings where each team member what they accomplished the day before, what they plan to accomplish today, and any blockers they face. Standups are short (typically timeboxed to 30 minutes) to encourage brevity. The name comes from the idea that the meetings should be held with everyone standing; there’s no time to sit in the chair and get comfy.
Because of the short timebox and the daily standup, Scrum is not a particularly good fit for open source projects. It works best for teams with few outside influences that are physically close by (or at least in adjacent time zones). A global project with people contributing around their day jobs and other interests can’t demand the level of rigor Scrum requires.
Kanban
Kanban, which is Japanese for “sign” or “signboard,” comes to us from Japan’s automotive industry. Unlike Scrum, it has no fixed time limits. Instead, it focuses on the flow of work. In this way, it’s incremental, rather than iterative.
Kanban uses visual boards (sometimes as simple as a sticky note on a wall) with columns that represent the different states that work can be in. Tasks are written on cards which move from left to right as they progress through the workflow. The simplest form is “todo,” “doing,” and “done,” although you may choose to have more granualar states.
When a team member has capacity to do work, they take a card and move it through each state. This allows the team to minimize waste. The kanban board gives the whole team—as well as external stakeholders—a quick view of the work. Some teams enforce a limit on the number of cards that can be in a given state in order to identify and reduce bottlenecks.
The as-you’re-able nature of kanban means it’s hard to give completion estimates for a given feature or set of features. But by limiting work in progress and letting team members take cards as they have capacity, it means things get done as fast as possible. This fits well with the variable-capacity nature of open source projects. As an added bonus, the easy-to-understand nature of kanban allows non-coding parts of the project to adopt it as well.
Extreme Programming
Put away your sword; it’s not that kind of extreme. Extreme Programming (XP) is a development methodology focused on four values: communication, feedback, simplicity, and courage. Communication comes in the form of pair programming: two developers sharing a console. This not only allows more junior developers to learn from experienced counterparts, but also for immediate problem solving.
XP gets feedback from rapid iterations, as in Scrum, but also in a focus on tests. Unit tests check the code as it’s being written. Integration tests performed nightly make sure the pieces all fit together.
Like Scrum, XP does best with co-located team members. This is particularly true when pair programming. XP also depends on an “on-site customer,” where the customer is actively engaged in the development process. This makes XP well-suited for bespoke development work, but less so for open source projects.
Note: This post was in an early draft of Program Management for Open Source Projects.
