Have you ever been on a project that seemed like it was dragging on forever? Where morale was low, the goal was unclear, and the end was never in sight?
There’s no way to sugar-coat it – those projects suck. I’ve been on a couple of them, and after far too long I realized what was missing. Milestones. Places where we could put a stake in the ground and say “We’re done. Nice work! What’s next?”
Agile development doesn’t give us these on its own. Technically, every time you close a story it’s a milestone, and so are the sprint demos where you demonstrate your progress to the Product Owner. But those are just part of the process – business as usual.
Teams need something more.
Without a break in the action, the Agile cycle gets boring after a while. If they’re not working toward something significant, teams will lose focus. At best, this means less productivity and discipline. At worst, people start finding more interesting projects to work on.
So find a way to build meaningful milestones into your project. Here are some suggestions:
Defend your MVP
The MVP (“Minimum Viable Product”) is the smallest set of features you need in order to ship your product. Basically, the fastest time to market. But MVPs grow over time. “Oh, yeah, we should probably put this other feature in there too while we’re at it.” Defend your MVP! Take a moment each week to examine everything in the list, and see if you can tweak it. Does everything really, truly have to be in there?
Ship more often
The ultimate milestone is shipping a product. The industry is focused on releasing often, and for good reason. With frequent, small deployments, you get continual feedback and risk is much lower. You may not need 10 Deploys Per Day like John Allspaw and the folks at Flikr, but a faster cadence means more of what you do is getting to market – and that’s a good feeling!
Get creative
A new product needs to have a certain feature set before it can be released. And it can take a while before it’s ready. What else can you do to break up the dev cycle? Can you build a “partial MVP” and get people to start using it? Kind of a pre-ship ship date? Or maybe you pick a spot in development and say, “Once we reach this point, we’re taking the next sprint to work on this other thing.” Or maybe you define a milestone and get the CTO to buy the team drinks when you hit it. Think about creative ways to add some variety to your dev cycle.
If your team is tired and the end is still a long way off, maybe it’s time to shake things up a little. What can you do to give your team something to celebrate?
——
Did you enjoy this article? You’ll find a lot more helpful entries in my blog. Be sure to download my free eBook, “Building a Career in Technology Leadership”, too!
MVPs are fine for team projects, but I’m finding that they’re more of a hinderance for independent developers like myself. Or at least they are when a 1.0 is released, and it’s missing some of the features one might expect from an app like that, or it’s still having teething pains because independent developers don’t have a QA staff, and that causes poor reviews and ratings, which in turn prevent sales.
And with App Store sales only being made when it’s sold and never on feature upgrades, there’s no reason to add features later like one would with a upgrade-for-money app. Which makes it important to first sell a complete app.
Great points, Steve – especially about how bad ratings affect sales. You don’t want the first version of your app to be buggy or missing obvious features! I think for indie development the milestones would be more technical, like the first time you can use the app to actually do whatever it’s supposed to do (even if it’s ugly/buggy/etc.). Releasing the first beta version would be another milestone. Or, depending on the scope, maybe it can all get done before fatigue and boredom set in. 🙂