I'm sure you know how deadlines work:
- collect the requirements/expectations & grok through them (understand them)
- estimate the effort needed to deliver the outcome, quantify risks, "guesstimate" unknown unknowns, ...
- ... and "collide" what you've got with current commitments & team availability (to assemble a rough allocation plan)
- the result will be the estimated date for the moment when feature will be available to the end-users/clients
- strive to make it happen
No-brainer.
This mechanism didn't change much since the "waterfall era". Surprisingly (or not ...) deadlines still exist in the "agile world" - just the delivery is sliced into smaller "sprints" & the design/estimating happens more "on-the-way", based on finely chopped "user stories".
Everyone heard/read at least once that products are supposed to be built in an evolutionary & iterative way, nevertheless what our stakeholders care for is the final effect (& its ROI) - not the in-between, crippled sub-product that they would never let to be presented to anyone outside. Hence the deadlines (reintroduced) and ... it's sort of our (engineers') failure - very few of us have managed to show there's a better and fully reasonable way.
But there REALLY IS another way - I mean it - to deliver meaningful value in a very disciplined way: without estimations & deadlines. By using pools.
What's a "pool"?
A pool is an investment the organization decides to make to get value within a particular topic (e.g. product or even its part). This investment is expressed in particular team's/people's work effort within a period of time. Examples of pools:
- one month of the whole team's work
- five weeks of the squad's work
- ten days of particular two back-end developers' work
Hereby lies the key difference: instead of telling what kind of final effect you want first (and then estimate effort to get it done), you'll telling how much you'd like to spend (and then make the best effort to reap value out of the investment). We're turning the "optics" upside down.
What do you do with pools? You spend them. On the version trajectory built upon topic outline. Say what?! OK, more definitions are on their way:
An outline is a functional decomposition of topic (project / product improvement vision). It's an elephant sliced into parts that are:
- expressed with the ubiquitous language (so understandable by all the parties involved - no tekky-talk)
- as small as possible, WHILE they still have a fraction of value associated to them
Important! Pieces of outline are NOT user stories. They are new/upgraded capabilities - you can treat them as layers of onions, where each onion is about a self-contained functional chunk (grouped around certain domain concept(s)). E.g. a single user story can span across several capabilities: notifications, user management, notifications, ordering, pricing, ... - each of them is like an onion - it can be enriched with new, more sophisticated functionalities. Each such "upgrade" of a capability is a piece of the outline.
The purpose of this split is to be able to "compose" solutions with the elements of outline, by applying trade-offs, simplifications, synergies, smart optimizations.
At last, but not least: a version trajectory is a list of projections - how will the product look alike after applying carefully chosen elements of outline in a particular order (based on value & effort needed to deliver these elements). You probably already get the idea, but if you don't - search Google for "agile Mona Lisa".
This trajectory doesn't have to be carved in stone, it can be adjusted on the way - as long as the granularity is fine, ordering is based on both value & coherency of the version and subsequent versions are complete (can be "done" and released).
Spending pools
Team(s) work on the pool in the Kanban way - they deliver as much fine-grained work items as possible within the limits of the pool (as pool's size is the hard cap). Team manages the pool expenditure together with their Product Manager/Owner, adjusting the course in a way that maximizes the value out of the agreed investment (pool size).
Working with pools is the quintessence of Agility:
- "understandability" of items (expressing them in the ubiquitous language) from the outline boosts transparency
- fine-grained split assures that our product is technically in a releasable state nearly all the time
- no fixed plan provides the flexibility of choice - especially valuable when some of your initial assumptions have failed and a little pivot is required
- the concept of the pool (& its size) helps with prioritizing topics & investments in them - e.g. more important topics before less important ones or topic X getting twice as big pool as Y, because it is expected to deliver more value
Pools will work only if the WHOLE team of people working of a topic (incl. business stakeholders) ...
- ... has a good understanding of what they work on - not just on the level of slogans or UI mock-ups, but also how are the domain models expected to change (what kind of new capabilities are expected to be introduced/changed, etc.)
- ... acts as a real TEAM - focuses on delivery on what's agreed, provides fast & straightforward feedback, makes aware decisions about what's next in the line - to make sure it happens: they all need THE SAME KPIs and goals
- ... understands that perfection is NOT a way to go in iterative, evolutionary environment and explicit REJECTS IT (the "perfection" - I mean)
- ... has the autonomy to make decisions about how the pool is spent AND is accountable for those decisions & their outcomes
When pools won't work
The two biggest obstacles in successfully implementing pools (that I've ever encountered) are:
- wow-effect addiction
- refactoring mammoths
Both are about attitudes - the former usually about business stakeholders' one and the latter about the tech peeps' one.
I've already mentioned "wow-effect addiction" in one of the first paragraphs of this post - nothing less than the fully developed product is considered to be of any value.
"Refactoring mammoth" is an inability to slice technical work on product in a way different than: massive (>75% of effort) refactoring of everything in the same time (so nothing is really "done" until this phase is completed) followed by the phase of little tuning/polishing (<25% of effort) of particular featurettes that helps to turn them into the final, expected shape.
Both issues are effective showstoppers of the pool approach (and killers of any Agility). And TBH in 95% of cases both can be overcome, when played out smartly.
Advantages of pools
There are plenty.
- Short term, closed goals help to keep the focus high
- Such a split of work helps with the transparency (all parties know WHAT is being done, WHY is being done & by WHOM is being done)
- No estimations needed, just a rough "shot" for pool size (which is much easier, because you set up pool size by comparing topics' relative importance) - we don't waste time on activities that do not bring value themselves
- Uncertainty is OK - you don't have to have full knowledge since the very beginning, because you don't have to care how you spent the last 30% of your pool just yet
- Pools can be scrapped (if you see there's not enough value in prospect)
- OTOH - if there's still significant value to reap - just assign a new pool
Wrap up
No new Americas has been discovered within this post :) It's all about old, dusty, fundamental concepts of Agility - but the secret is that the wheel doesn't have to be re-invented, it just sometimes needs refreshed (or more explicit) framing. If "iterative" or "evolutionary" is still too vague to you (and your collaborators), maybe switching your thinking to "pools", "outlines" and "trajectories" will help getting all cogs in the proper position of your machinery.