When you have a deadline for a release, and limited development resources to get there, you are forced to be ruthless about features you develop, and identifying the business value of each of them. You have to think about “Minimum Viable Product” (with “viable” being a real part of that phrase).
And you have to ruthlessly think about the “business value” (whether that’s in terms of meeting end-user needs, or your organizations needs), and make sure you are focusing on the features that provide maximum value most efficiently. That is, trying to minimize developer time and other expense while maximizing value.
(These are not usually totally quantifiable things, at least in advance, so this isn’t actually just an equation. Developer time may be quantifiable in retrospect, but is only an estimate before the fact. “Value” may be quantifiable if you are a for-profit concern who can measure value by revenue, but often again not until after the fact. Although there are ways to A/B testing and such to do minimal investment to discover if more investment is justified. I’m more used to working in non-commercial environments where value isn’t really easily quantifiable at all — but it’s still there).
You have to do this because you have an enormous “wishlist” of things various stakeholders want, and you know you can’t possibly accomplish them all and get your product out by the deadline — whether that’s a hard deadline, or just in the sense of getting the product out ever, or not waiting long past when you could have gotten it out, in pursuit of accomplishing everything you possibly could.
Well, maybe you don’t have to, but it’s generally more clear to everyone involved that you ought to, when you are worried about getting the product out the door soon enough to meet deadlines or stakeholder expectations, when there’s actually some stress involved and you aren’t totally confident this will be easy to do. Its more clear that the only way to keep from going crazy and meet your goals is to apply a bit of ruthlessness to evaluating possible things you could do in terms of business value.
(If you are using any kind of agile, scrum, or buzzword-less process/division of labor that involves a “product owner” role, then it’s the product owner’s responsibility and authority to be making these decisions. About what work to choose to do next, in order to maximize value. In consultation with all sorts of stakeholders, as well as the rest of the development team (the “product owner” is part of the development team too), of course).
But okay, let’s say you met that deadline, your product is out, and let’s say that it was quite successful, by whatever means you measure success, quantifiable or not. (Again my experience is mostly in non-commercial environments where success is not as obviously or easily quantifiable as just “revenue”, but there’s still some kind of success, even if it’s just the judgements of internal and external stakeholders and end-users — if there wasn’t such a thing as success vs less success, why were you even doing it in the first place? :) ).
Now the pressure is off — you made it to the finish line! You still maybe have a giant list of things some stakeholders thought of as possible things to do, or things they would like to do, or someone’s pet thing, or whatever. Or maybe you don’t, and the possible things to develop just come up popcorn-style. Either way you’re no longer so worried about it, maybe it seems like you have all the time in the world.
But, I suggest, the continued success of your product/project still relies on bringing that ruthlessness to evaluating business value, even when it’s less obvious that there are external constraints forcing it. The continued success of your product, and you and your teams’ sanity.
If you lose your focus on that, the product starts going all discombobulated. You can end up doing things that actually hurt business value. You can have stakeholders wondering why their pet feature wasn’t implemented, but someone else’s was, and turning it into a political battle, and realizing too late that you can’t really explain/justify the choices made. You can end up spending weeks on something you thought would only take a couple days, when really there was no reason to be doing it in the first place (or you would have quickly realized after a few days when the true scope became apparent) if you had been ruthless about business value. You can spend a lot of time “rearranging deck chairs,” which ultimately can be bad for the morale of both the development team and other stakeholders.
I actually hate working under time-pressure and resource-stress (who doesn’t?), but in fact the time-pressure and resource-stress of trying to get across the finish line provided some useful focus that resulted in a better product and better morale. (Towards the end of writing this, I found a blog post titled “Can we truly be agile in maintenance projects” which suggests this may not be a unique thought).
But I think the solution to keeping a focus on business value without these stressors is probably the same as it was with them: The agile practice of managing/grooming your “backlog” and “sprint planning”.
We actually have one benefit in an “already crossed the first finish line”, “maintenance and continued development” scenario: There is less pressure to un-agilely plot out everything for the next 6+ months (ie, to get across that first finish line). It should actually be a bit easier to do things “agilely”. (One of the insights of agile development, I think, is that all that really matters to the development team is what are we doing right now. This isn’t an absolute, sometimes you gotta know what’s coming down the line, or make long-term plans. But the end (or rather the beginning) of the day, one human can really only be doing one thing at a time, and what ultimately matters is choosing what that is).
If you keep that backlog management practice even in a “maintenance” phase, then it becomes obvious that you can’t do it without maintaining a focus on business value.
Personally, I don’t necessarily think it’s important to always have your entire backlog ordered (as some scrum “manuals” will insist). What’s important is that when you plan what you’re going to work on now (ie, the next “sprint”, whether that’s a day, a week, or a month), the things you put in there have been evaluated for business value (with the product owner having ultimate responsibility and authority for that). Which requires having enough of your backlog prioritized/ordered enough that you don’t need to always be looking at the entire backlog and re-litigating it before every sprint (cause that’s going to drive you crazy and suck all your time), but what practices you need to make that happen can be contextual.
If you keep a focus on “what are we doing now/next”, and keep your agile practice of determining this with a “ruthless” focus on maximizing business value (which requires being able to articulate the business value of what you choose; which requires continual pursuit of the contextual knowledge — user-testing; internal mission and strategy; internal ‘politics’) — even in the absence of high-stress deadlines and resource crunches — I think you can increase your likelihood of continuing to produce a great product, being able to explain/justify to stakeholders why you did X and not Y, and keeping the development team sane and their work rewarding.
Bibliographic Wilderness 