The Planned Attention framework v1
I started the Planned Attention newsletter to answer a question that had been simmering in the background for over a decade.
I was a fan of the agile software development movement, and the start of my career coincided with its rise in popularity. My teachers at college were all of the UML/Gantt charts persuasion. My employers were all a bit more flexible. It was a time of change.
For those early years of my career, I was a Scrum acolyte. I believed that missing a retro was a capital offense. That thinking more than two weeks ahead was futile.
Over the years, I fell out of love with the "Agile movement". By 2010, it had little to do with technical excellence and had turned into a management-sans-management circus. Scrum Masters were project managers without an iron triangle. Agile meant waterfall without taking the time for analysis—the ultimate exercise in futility.
I noticed stakeholders asking for time frames and developers refusing to give them that.
In the back of my mind, I always knew, "When will it be done?" was a valid question. It was the question. It took experience, age, and a little bit of wisdom to accept that planning was vital to software development.
There is very little literature about long-term planning for agile software development. There are a myriad of blog posts and conference talks claiming it's impossible. There are frameworks with now-next-later and story points to make sure no one can really plan. There was no book about how to plan long-term when applying agile software development.
When I started Planned Attention, the goal was to structure my thoughts. I wanted to write a practical guide that was easy to implement.
After almost 2 years, such a guide is emerging. It's not done yet, but it's getting close.
Today, I would like to give an overview of the state of that early framework. Those who have been following this newsletter for a while will have seen this mature. Those who are new might pick up a thing or two.
The main ideas are not big concepts or vague methodologies. There is no need for consultants and no certification schemes. There is no "you must be doing it wrong". The framework today consists of two types of timebox, one recurring meeting and one shared document. It's as lightweight as it comes.
Iterative buffer planning
The main concept to understand is that we can't use estimates for long-term planning. Long-term plans require a different approach. Instead of planning sprint after sprint, we divide our team's attention into periods of intense focus, followed by a buffer.
I call this Iterative Buffer Planning, and it works magic for long-term planning.
Focus blocks
The period of intense focus is a timebox called a Focus Block. Rather than starting with a sprint commitment and hoping to get all the work done, we start the block by asking "What is the best solution to the current problem we can build in the allocated time?". We might not be able to estimate how long it will take to build a feature in the far away future. But, we can definitely decide how much effort we want to allocate to a problem. The solution that we can build in two days will look radically different than the one we allocate three weeks to.
We build software products by addressing one problem at a time. The focus block is a planning tool and a productivity booster — it’s the antidote to context switching.
Recovery block
The main reason teams are bad at long-term planning is because they underestimate the cost of operational work. Teams need to spend between 25% and 50% on maintaining existing features and keeping the lights on. Yet we always plan as if we'll work only on new features. The Recovery Block is the buffer after each focus block. It's the timebox dedicated to operational work.
By adding such a buffer after each focus block, we carve out time for operational work while preventing the domino effect of carrying over tickets to the next sprint.
Support Swarms
One type of operational work that often derails our best plans is customer support. While most maintenance tasks are not urgent, customer support issues are rather flammable. Neglect them for too long, and you've got a fire to put out. But dropping everything to help customers creates a constant stream of context switches, which kills our focus. Support Swarming Sessions are recurring time blocks at the end of certain days where the entire team will handle support. They are the number one tool to prevent fires.
Actionable roadmaps
The roadmap is the highest-level view of the plan, and it's our main communication tool between teams, peers, and stakeholders. I find most companies have PowerPoint roadmaps that are disconnected from the work floor. The type of roadmap I have in mind is actionable. It allows us to play What If? scenarios and see the impact on other teams and stakeholders. When someone wants to expedite a new feature, we can show them the impact of that decision. "That would mean postponing the Customer Zone feature to next year. Do we want this?"
This kind of stakeholder Jiu-Jitsu allows us to tame the stream of ideas.
The Planned Attention framework is lightweight and can be applied to most small, self-organizing teams with almost immediate results. But it's not mature yet. A few questions still remain.
How to capture internal feedback? How to handle design- or analysis-heavy products? How to plan really large bets?
That's more than enough material to explore further.
But for now, having tested this in the wild, I love what I’m seeing.