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.
It sounds like you are describing technical debt. On an agile project I was involved with in the past, we used downtime in between release cycles (usually a week or two in the schedule every 3 months) to pick up items that were effectively technical debt. It's all what you can negotiate with your customer and the needs of the moment.
ReplyDeletehey Mario,
ReplyDeleteI hadn't heard of technical debt but I don't think it is the same thing.
For my exception example, technical debt is definitely the cause. But I am not suggesting fixing the API. I am suggesting changing the logging so that something less scary is emitted, for the sake of the users and support staff.
In other words, a coin is a cosmetic change, not a technical one.
One could well argue that in my example, it _should_ be fixed due to technical debt but if so, then this is just a poor example ;-)
Another example might be that the tab-navigation in a GUI is not ideal. The marketing staff might _never_ prioritize that bug as being of concern, but the every day user might truly cheer the fix.
As I write this, that is a key concern: every day usage. We love the changes in Project Coin (for Java) because we are every day users, on the front lines.
I hope this helps! I'm certainly not claiming that this is an original idea, but I see it as being distinct from the link provided.
Great thoughts as always Michael and I agree that this is not technical debt (although I think there is a similar parallel world there).
ReplyDeleteLast year we had the whole engineering team for Terracotta together and we actually did 1 day to build a new micro-feature. Some people came up with their own ideas, some worked off of existing requests but we actually had several cool things done by end of day and a number of great prototypes that we could use as a spike to take it further.
We had PM and field guys judge at the end of the day. They were ecstatic with a few of the new features, maybe happier than they are with most new big releases.