Richard Lawrence

Effective agile teams get things done. They build software day after day that’s not just “code complete” but really shippable. And when their product owner says, “ship it,” they can get their shippable software into production at the drop of a hat.

The Definition of Done can be a powerful tool to make these things happen…If it’s used right.

Most agile teams I see have one of four relationships with a Definition of Done:

1. They don’t have one
2. They have one but don’t really use it
3. They have one but can never satisfy it
4. They have one, satisfy it for each story, but still have lots to do at the end of a release

I rarely come across teams who use the Definition of Done to good effect day after day, sprint after sprint. Find out why and how to fix it »

I’ve written before about the amazing financial impact of releasing more often. And I know from personal experience the positive impact that frequent releases have on learning and on product quality and value. So, I enjoyed this post on one company’s experience with continuous releases. Yes, you read that right; they release, on average, 50 times per day.

We call this process continuous deployment because it seemed to us like a natural extension of the continuous integration we were already doing. Our eventual conclusion was that there was no reason to have code that had passed the integration step but was not yet deployed.

Read the whole thing and consider what it would take in your organization to get to continuous deployment. How fast could you go? And what impediments would have to be resolved to make it happen?

As the saying goes, “Cash is king.” It doesn’t matter how good your P&L or balance sheet looks or how good the business case for your project is, if you don’t have enough cash every month to pay the bills, you won’t stay in business.

With the economy tightening, then, companies are desperately trying to cut costs in order to stay cash flow positive. In IT the major cost is salary, so cutting costs means cutting people. Nobody likes that.

Fortunately, there’s a simple way to reduce expenses and increase returns on a software project: incremental releases.

Read the rest of this entry »

It seems like fully half the projects I come across are rewrites in one form or another. It ought to be common knowledge by now that rewrite projects have a very bad track record, but perhaps the bad results are connected to the inordinate attractiveness of “doing it right this time.” The chance to replace the ugly production system with a new, pure, buzzword-compliant ode to software architecture is one of the more compelling siren songs for developers. Too bad about those rocks.

Given that rewrites aren’t going away, here are the things I recommend software organizations consider to maximize their chances of avoiding the rocks (and maybe even be wildly successful!).

1. The problem isn’t as well known as you think it is. Run away from specs that say, “The new system shall do everything the old system does plus new functions X, Y, and Z.” No one knows exactly what the system does. It got to where it is today through the accretion of features, hacks, and workarounds. You’re almost guaranteed to break someone’s unofficial report when you rebuild the system “right.”
2. BDUF still doesn’t work, even if the previous version of the system already exists. Sure, you’ve architected the perfect service-oriented, social-media, domain-specific new system. Unfortunately, it’s wrong. In the end, the new system is going to look nothing like you envision. You can’t see the future any more than the previous team could. (In fact, they were probably replacing some other system and “doing it right this time.”)
3. The customer almost always wants the existing system plus something new. By now, the existing system is probably what David Anderson calls table stakes. Since the existing system exists, you’re already in the game. Don’t start by building the table stakes again. The new features are probably spoilers or differentiators. Those have real incremental business value. If the existing system works, build the new features first. Figure out a way to integrate them with the existing system as necessary. Then grow the new system to choke out the existing one. (Martin Fowler call this pattern Strangler Application.) Eventually, you’ll have your whole new system, but it’ll bring new value from day one instead of spending months or years catching up with the existing system. It’s harder to architect a system incrementally than from scratch, but architects like challenges, right?
4. Involve the business. Don’t let them send you to the existing system as a specification. Starting with the new features makes this a pretty easy sell. Someone’s excited enough about those new features to work with your team. Keep a blend of new and replacement features through the whole project and they’ll stay engaged.
5. Release early and often. Business value can only be realized if people are using the software. Moreover, the quality of the feedback you receive will be better if your software is being used by real users with real data. This is standard agile stuff and shouldn’t come as a surprise to anyone, but rewrite projects seem to have a logic of their own.

For more rewrite project advice, check out Chad Fowler’s excellent 2006 series on the topic.

What other tips would you give teams considering a rewrite project? Share them in the comments.