Skip to main content

https://governmenttechnology.blog.gov.uk/2014/03/18/business-planning-in-an-agile-world/

Business planning in an agile world

Posted by: , Posted on: - Categories: Technology Transformation

The Office of the Chief Technology Officer recently held a business planning away day.  What for?  Read on …

A photo of five men sitting around a table in a breakout session.

Business planning is about understanding where we are, where we are going, and how we’re going to get there. Effective business planning considers what obstacles we have to overcome along the way and how we prove - to ourselves and to others - that we’ve got there.

Bringing all this information together allows us to plan effectively and focus on what the team needs to deliver its vision. This is just the first session in an ongoing process, it’s not just done to help set budgets and milestones, instead it continues to evolve to support emerging projects, priorities and changing user needs.

Agile? Planning? Surely not!

Agile as a concept is a framework with a set of principles that put users and the team first. The framework and these principles can be used to get anything done from managing a help desk function to delivering software, or managing a sales pipeline.

One of the big misconceptions about agile is that it’s only about delivering projects. Although many ‘tools’ in a delivery manager’s ‘toolkit’ are about delivering and continuous improvement throughout the delivery, that trivialises the role agile should play in organisations.

So, should we approach business and milestone planning in the same way we would any agile project? The answer is, quite simply, “yes”!

Understanding needs

GDS design principles state that we start with needs and a planning session is no different. We need to look at what the drivers are for the outputs of the planning, what our hopes and fears about the process are, and identify what success looks like.

Let’s start with how we defined the purpose of our business planning away day:

  • celebrate what we’ve achieved so far and what obstacles we removed along the way
  • identify unresolved obstacles that need attention
  • articulate the vision for the programme as a whole and for each business area
  • identify goals and fears relating to that vision
  • clarify any specific commitments we have made to people
  • brainstorm milestones that will help us deliver those goals
  • promote more discussion, sharing and understanding between the teams
  • use the data collected from the teams to prioritise, commit milestones and plan delivery

Simple agendas

Keeping things simple is key. We wanted to be able answer the questions: Where are we now? Where are we going? How do we get there? We took a typical agile approach, streamlined it to workshop key questions from our purpose statement, and added a retrospective at the beginning to provide the context of where we have come from.

We acknowledged that this was the start of the planning process, and were primarily focused on capturing as much data as we could from the five teams within the Office of the CTO. We reinforced that there would be follow-up workshops with each team to drill into more detail and agree on what we want to commit to for the next year. We were clear that all fears should be highlighted and shared in the broader group so we could focus attention on resolving them.

Business planning diagram, Office of the Chief Technology Officer

Top down vs bottom up

While scaling agile practices to the GDS portfolio, we learned some key lessons. One of these, and central to the approach we took in our business planning away day, is that the team is the unit of delivery.

The only way that this session was going to be truly meaningful was to involve the entire team.

Principles from the Agile Manifesto articulate this well, so the most relevant ones are paraphrased here:

  • give your team the environment and support they need and trust them to get on with it
  • allow the best content to emerge from self-organising teams
  • face-to-face interaction is the best way to communicate
  • reflect, adapt and change

The benefit to having the whole team involved in this process is massive. The team are acutely aware of the challenges and obstacles they face, so rather than being told what to do and how to do it, they contribute their own ideas about how to overcome them. The result of this process is joint (individual and team) ownership of the goals, objectives and challenges.

Input from senior management at this session is crucial. We set aside time for our CTO, Liam Maxwell, to articulate his high-level vision and themes for the coming year. We then asked each team lead to come up with a one-line vision statement for their teams. This statement was one that the teams would refer to throughout the sessions while thinking about goals and milestones for the year.

Giving people the time to do this properly and providing an environment in which everyone is comfortable contributing is key to building a unified team who are confident in their roles - making them much more likely to find success.

Lessons learnt

  • depending on the size of your programme or teams, having multiple facilitators will ensure that break-out sessions are supported, allowing everyone in the break-out to contribute rather than worry about watching the clock
  • your teams may be at different stages of thinking/planning based on work they’ve already done or the kind of work they do. Ensure you’ve got several different types of activities in the event that teams finish a workshop early.
  • know your team and your leads - tailor the process and the workshops to the individuals within the team

Summary

  • this isn’t revolutionary, but it is often neglected
  • get back to basics
  • facilitate discussion and sharing
  • step out of the day-to-day
  • celebrate what you’ve achieved
  • be honest about fears and blockers
  • share!
  • accept that things are going to change and that this is ok

Next steps

This workshop was only the beginning of the process. As with any successful project or process, we need to iterate and refine what we’ve done.

If you have questions or comments, please drop Nathan a line: nathan.swift@digital.cabinet-office.gov.uk

Follow Nathan on Twitter, join the conversation @GDSTeam.

Sharing and comments

Share this page