In some corners, “agile planning” would be considered an oxymoron. That’s because, back in the day, an organization might map out what it was going to do over the next year, and do it. This sort of planning was done centrally by the managers once a year at a fixed time. Then agile came along. And agile was about reorganizing around small, self-managing teams that autonomously decide their priorities and where to allocate their resources.
Some people took this to mean that being agile is tossing all your plans out the window and going where the wind takes you. And some companies have taken to working like this, wasting valuable time and energy moving from iteration to iteration with no long-term view of where they’re going.
Sure, these teams are sometimes successful in delivering valuable, in-the-moment solutions to customer problems, and may well be successful at this for a short time. However, with software projects in particular, a lack of long-term planning can lead to ill-conceived and poorly written code, which in turn will cause maintenance costs to go up when other devs have to come fix it in the future. More broadly, delivering in-the-moment solutions without any overarching goals or vision can lead an entire organization to grow up around, and be dependent on, a product that may not have a big-enough market to keep the organization going.
What does the Agile Manifesto say?
One of the most common misconceptions about agile is that agile = no planning. Let’s look at what the Agile Manifesto says:
Responding to change over following a plan
Note the word “over”. Over does not mean “instead of”. It simply means that responding to change takes priority over planning.
Plus, following its list of “this over that”, the Agile Manifesto goes on to say:
That is, while there is value in the items on the right, we value the items on the left more.
So, it’s acknowledging that there’s still value in following a plan.
To be honest, it’s understandable why planning plummeted out of fashion. Back in the early and mid-20th century, long-term planning by executives was easier because the world was predictable. But towards the end of the century it stopped being so, with relentless technological change disrupting industry after industry, causing centralized, long-term planning to become organizations’ undoing.
However, becoming more agile in the face of fast-changing processes and environments was never supposed to mean: plans are pointless, stop making them. It was supposed to mean: change how you make them.
George R. R. Martin vs JK Rowling
Let’s use George R. R. Martin as an example. He is in literary terms a classic “pantser”. What this means is he flies by the seat of his pants when he writes. He doesn’t plan; rather he makes his stories up as he goes along. Clearly one of the big reasons The Winds of Winter still eludes us ten years on from the release of A Dance with Dragons is that George has lost control of the narrative. He went in with no plan and now he’s up to his eyeballs in a million tangents.
The other type of writer is a plotter, like JK Rowling and John Grisham. The type that makes a detailed plan of an entire novel, sometimes chapter by chapter, with a pretty firm idea of what’s going to happen to their characters by the end. This, of course, comes with its own drawbacks. Characters can become pawns of the plot, and contrivances can ensue, because the writer may be forcing certain things to happen to ensure the story goes in a particular direction.
So, you might say that the best approach to writing a novel is a mix of the two. Go in with a loose plan of your character’s arc, key plot points, and how everything comes to a head. But leave enough room for the character to develop in a few different directions, or for certain plot points to change naturally and authentically.
This is basically what agile planning is. It’s not an oxymoron at all. It’s a different, more flexible kind of planning.
Agile planning = adaptive planning
Agile planning is not a rigid structure. It’s a progressive one. You’re making a plan that’s detailed enough to be useful but loose enough to be adapted as needs and circumstances change. Agile planning involves planning for change, i.e. putting a framework in place for responding to contingencies and coping with them.
In practical terms, Clifton Gilley, formerly ‘The Clever PM’, describes agile planning as follows:
Rather than working at the feature/functionality level, agile planning needs to operate at the thematic or vision level — setting goals based on areas of functionality or of market need, and not on specifically defined functional deliverables.
So, you’re not specifying features and giving them fixed delivery dates like you would if you were doing traditional product planning. But you do know what you want your customers to be able to do, even if you don’t have the exact feature that enables them to do it nailed down. There’s still a long-term vision that everybody’s working towards.
And because the long-term plan is loose and vision-led, it means the actual planning of tasks can – and should – be done as late as you can get away with. You’re not trying to come up with every low-level task involved on a 6-month project before you get started. Agile work plans evolve and crystallize as the project develops, giving you maximum flexibility to accommodate new knowledge, and reducing wasted time and costs.
In his article, Planning Doesn’t Have to Be the Enemy of Agile, Alessandro Di Fiore gives the example of Dutch financial services firm ING Bank. ING Bank reorganized its 3,500-strong workforce into lots of agile ‘squads’, all able to define their work and make business decisions quickly. These squads are part of ‘tribes’, a collection of squads working on related areas. Each tribe creates a quarterly document outlining tribe-level objectives and key results, which gets discussed at an alignment meeting made up of tribe leads. The goal of this meeting is to find out if the tribes’ work is contributing to the company’s strategic goals. And then there are meetings that take place within a tribe, made up of representatives from each squad, to agree on how the company’s strategic goals are going to be achieved and ensure alignment of the squads within the tribe.
Di Fiore says that the ING Bank example shows how the planning process is still absolutely essential to an agile company; it simply takes a different form. It is about multidisciplinary teams planning their work autonomously in alignment with a flexible overarching company plan that all those teams contribute to.
Agile planning in Jira
Though designed as a tool for agile teams, there’s no designated planning facility in Jira. You could argue that Atlassian didn’t think about this because they made the same mistake about planning as many still do, i.e. agile teams don’t do it, they just get on and code.
Of course, most agile teams do plan. They simply have to do their planning outside of Jira. If they’re in an office, they might use sticky notes and a whiteboard. If they’re remote, as most teams increasingly are, they might use Confluence or a brainstorming/planning add-on. Then there’s always the problem of translating people’s ideas into tasks in Jira once a plan is formed, something that usually has to be done manually and takes a bunch of time.
So, agile planning in Jira isn’t the easiest or smoothest of undertakings. This is why we will soon be adding the Atlassian add-on, Agile Planning for Jira, to Old Street Solutions’ product suite. This app dramatically improves planning capabilities in Jira and eliminates all post-meeting data entry. Essentially, it allows you to brainstorm, create Jira issues, and plan sprints and releases on a free-form board, powered by drag and drop and synced with your Jira instance.
We’re currently looking for volunteers to trial Agile Planning for Jira and give us their feedback. So if you’re yearning for more freedom when planning, please get in touch!
Christopher is a self-confessed nerd who’d probably take the cake on Mastermind if Star Trek: Voyager was his specialist subject. He writes fiction about time travel, conspiracies and aliens; loves roller coasters, hiking and Christmas; and hates carpet, rom-coms and anything with chilli in it. He’s written extensively for technology companies and Atlassian partners and specializes in translating complicated technical concepts, specs and jargon into readable, benefits-driven copy that casual readers will understand.