Applying Project Coin to Agile Development

Project Coin

As noted in Alex Miller's various Java7 posts, Project Coin is a set of small language changes proposed for Java7. As noted on a recent Java Posse podcast, these changes should be on the same order of magnitude as the new for-loop in Java 5. That is to say, the change should be small: a coin, as it were.

All well and good, but this post is not about Java. This post is about the reaction to the project. Though I prefer Project Coin it could also be called Project Breathmint, because it is refreshing (even fun) to talk about small features that do not ignite the flames of debate as much as say... *pause for effect* closures. These are lightweight changes that can really make a pleasant difference.

The Idea

My proposal is to consider your own Project Coin for your project.

The Background

There are many casualties in the lack of communication between developers and the stakeholders of a project, even on agile teams. One such casualty is this: customers, domain experts, and especially support staff often despise a given defect or quirk that is quite easy to fix. A recent case for me is a recurring exception trace in a log file (it occurs often because of a poor API design: the exception is thrown in a reasonable, normal situation). The support staff have learned to pattern-match it, but it gives them fits.

The Execution

We should not lose focus of the main money-maker: delivering maximum bang-for-the-buck features to customers, where said features are prioritized by stakeholders. However, it seems reasonable for a team to draft a Project Coin once per quarter. The first benefit will be reaped immediately: communication. Even if an item proves to be too large to be a coin, the dialogue among the team will be worth it.

Once the list is compiled, the team could shoot for one coin per iteration (e.g. every 2 weeks). Naturally, if an item doesn't make it, that is acceptable: these are literally bonus points.

The Project Coin items are perfect for newcomers to the project, for junior developers, or for Friday afternoons when we need a break. A danger is that someone will go hog-wild with a complete framework to fix a small problem, but daily stand-ups and code reviews should keep that in check. (Your team does have dailies and code reviews, right?)

The Upshot

I can't say that I've put this into practice. However, my team has talked about this idea in nebulous terms. Now that we have the coin metaphor from Java, perhaps it can become a reality for many agile teams.