Software products love agile software development. Rather than designing the entire solution up front, we grow our system through small iterations and frequent feedback.
While we sometimes need more structured project work, the product-style approach is often a much more natural fit. The hard distinction between project and product is clear.
But there is a third kind—a grey area. There is that hybrid form where we launch mini-projects in the context of a larger product. We start these to create a bigger change. Something that will take us longer than the next increment before we can reap the benefits. We might not want to capture feedback on this mini-project until it's finished.
A typical example is a redesign of an API. Let's assume our API design is all over the place, and we want to consolidate it to make it more readable.
It's like a project because there's a fixed scope- we have a list of all the endpoints we want to change. It's also one of those scenarios where a single work item doesn't create value. Rewriting one endpoint in GraphQL makes the situation worse! Now there are two styles to consider. To reap the benefits, it's all or nothing.
But unlike a project, there is no project team. We expect the regular product team to build it. There's also no budget; it's part of the team's operational cost. And finally, while there might be an indication of a timeline, there usually is no written plan. It's yet another load of work thrown on the backlog pile.
I call these mini-projects “initiatives”, and once you start looking, you’ll see them everywhere. An initiative is any endeavor that needs more than a single timebox before putting it in customers' hands.
Without a well-thought-out management approach, the fate of initiatives is predictable. Developers will throw themselves at the API redesign until something more urgent comes up. And before you know it, a year has passed, and you’re still supporting two types of API. It never gets done.
Every architectural change. Every attempt to pay back technical debt. Every big design change. They’re all initiatives that won’t get done in a product-style approach.
Here’s how to make sure they do get the necessary attention.
Spell it out
Projects need a clear plan, an old-school iron triangle. That means writing out the work breakdown structure, estimating the work items, and mapping them on a timeline. Start such an initiative by defining the mini-project. Who is it for? What are we trying to achieve?
I find it helps when we can give the initiative a clear name. If you need to upgrade a bunch of apps to the latest Android API, don't call it the "mobile apps" initiative. Before you know it, every mobile bug and half-baked feature idea will be tacked on to this project. Scope creep is as real in initiatives as it is in real projects! Call it the "Android API upgrade" initiative instead.
Limit waste
In Lean manufacturing, inventory is considered one of "the seven wastes" as work products are collected without delivering value. Long-lived feature branches are their software equivalent. We're building a lot of stuff without putting it in the hands of actual users. That stuff gathers dust in our virtual warehouse.
Although sometimes necessary, initiatives create inventory. We need to ensure that what gets collected gets shipped. The best way to prevent a stockpile of unfinished work is to limit the team's number of concurrent initiatives to one.
We can do a redesign of the mobile apps, but we can't also port the code to Flutter at the same time. Only start a new initiative after the previous one is done.
Apply iterative buffer planning
We don't want to treat our mini-project like a side hustle. Like all work, an initiative deserves the team's full attention and belongs on the roadmap.
We also don't want to block out months of project time. Our product still needs love, and the demand for operational work doesn't stop because we decided to start an initiative. We can't let bugs and customer support pile up while we build our project.
If we scope our mini-project well and limit the number of concurrent initiatives, we can apply iterative buffer planning. Let's say we estimate about six weeks of work. We can break that up into three two-week timeboxes. We follow the same pattern as Focus Blocks and place those time boxes on the roadmap, interlaced with Recovery Blocks. It makes sense to add a longer recovery block at the end to handle project feedback and slippage.
Looking at this roadmap, the cost of the initiative becomes clear: for the coming months, the team won't be delivering any other feature. It's a realistic look at the price of such a project.
While we technically could address other problems by interlacing unrelated focus blocks, I’ve learned that it’s best to double down on an initiative once it’s started. If we keep postponing initiative work in favor of feature work, our inventory gets stale. It’s better to get it over with.
Software products are never pure products. We sometimes want to launch bigger blocks of work that don't require intermediate feedback. Rather than blocking one big iteration of project work for months on end, break it up and apply iterative buffer planning.
If we make the effort to define these mini-projects well, our teams are capable of making those big leaps and sticking the landing.
That is an interesting approach. I like the idea of motivation-driven development of small things becoming full features once.
Similarities with baby-step-approach and strangler fig. However, the aspect of developer motivation is unique.
I think you could argue that any product work is also made of very small projects. But your take is a good one, of those slightly bigger yet not quite a big project...