Agile Planning Done Right


It’s a term that you are sure to hear from nearly every one of the technology partners that we work with. While a few claim that they are fully Agile, many others will tell you that they work in a hybrid way.

Typically, in my experience, the majority of our partners will combine a Waterfall discovery process and full, end-to-end specification, with an iterative Agile development. But there is more to Agile than simply developing and releasing in bursts. While you may be nervous starting a project without defining all your needs in detail, Agile is not a methodology that lacks a plan. In fact, a cycle of planning and re-planning is baked into the method.

Agile is not a methodology that lacks a plan

Where’s my specification?

Yes, it’s true…

When working in a fully Agile project you will not be given a detailed specification. Instead, after the discovery process you will receive a number of high-level Features. These features will describe the functionality required but not at the same level of detail as a ‘Waterfall’ specification. The full project team, both partner and client, will then meet to agree the Feature roadmap, assign effort (budget), and agree the ‘minimum viable product’ – the smallest, most high-value, functionality that you require for your business-as-usual at go live.

This approach is not disadvantageous; it is highly collaborative, with the partner able to comment on the likely complexity of the work required to support your needs, with you providing insight into your business priorities, and the highest value functional items, to agree a delivery roadmap. The process cannot work without this symbiotic relationship between partner and client.

And, importantly, this relationship continues throughout the development sprints.

Agile (Adjective); Able to move quickly and easily

A detailed specification provides reassurance; everything you think you need is written down and you have signed it off. But what if things change? The Discovery process missed something? Or, when Sprint 3 starts, the partner suddenly realises that the requirements are more complex than first assumed. All these items result in change requests, additional cost, and additional time. With little opportunity for you to understand or discuss them or investigate alternative approaches.

Because an Agile methodology continues to define the detailed requirements (user stories) throughout the development process, there continues to be a very close and collaborative relationship between you the client and the partner. This means that you can change, adapt, and reprioritise your requirements as the business changes. It enables discussion around the full range of potential solutions to a business need, whether a fully automated technical solution, or a change to your business processes, as you see and learn about your new systems, and it means that the project can flex within the budget available.

It’s a Sprint, not a Marathon

Each development Sprint is preceded by a dedicated planning session where the whole project team, including the partner’s business analysts and developers, will meet to discuss the users stories, the effort (and therefore the budget) required to deliver them and their value to the business. The backlog of undelivered user stories can be stack ranked (prioritised) and many user stories parked before development effort is spent on them.

This continuous cycle of discovery, user story prioritisation and planning for each and every Sprint empowers you as the client; it allows you to understand the impact on the project budget of each and every deliverable, and make better decisions based on the cost versus value of every item. This level of transparency and collaboration throughout the development, I believe, can often be missing from a hybrid approach leading to higher costs and an extended timeline.


There are many myths about the Agile Methodology, and it is certainly a very different project experience for a client. The lack of an upfront, detailed specification, however, does not mean that Agile lacks a plan. In fact, when Agile is done right the opposite is true, but with more opportunity to flex, change and adapt as the project progresses, and your business changes.

Is an MVP implementation the right approach for me and my digital project?

With the emergence of Agile as the preferred methodology for most software implementation projects in the non-profit sector, one of the more common early discussions we have with clients who are planning a digital project is now around Minimum Viable Product (MVP). Specifically, the questions we get asked focus on “what is it?”, “what does it mean in practice?”, and “is it right for me?”.

What is MVP?

Before we get in to the detail of the discussion, let’s first reflect on what MVP is meant to be, by taking the purist definition:

A minimum viable product (MVP) is a development technique in which a new product or website is developed with sufficient features to satisfy early adopters. The final, complete set of features is only designed and developed after considering feedback from the product’s initial users.

That definition is clear and valid, but it is purist and very difficult to apply in most of our projects, specifically because most of our projects involve the replacement of an existing system upon which a number of business functions and users rely. So could we simply replace “satisfy early adopters” with “prevent any degradation in service”, meaning that the new product or solution only has to enable us to do what the current solution does at the time of MVP launch?

There’s certainly an approach there which could be more widely applicable, in respect of the first half of the definition, but what about the second half, which speaks more to the purpose of the model. We have to have enough of an MVP release to enable us to assess the strengths, and weaknesses, of the solution, such that we can learn valuable lessons which will influence and impact the future releases.

Within that, the solution itself has to be flexible enough that we can adapt to the lessons we learn from MVP, not just in future releases but potentially also in retro-fitting features into the MVP implementation. What’s more, we have to be confident enough in the technology and partner to invest in the MVP release with a fair degree of uncertainty around the composition and nature (and cost) of future releases.

This is starting to sound quite challenging now, to fully understand and to put into practice.  It is though very much on trend to be promoting the model, so we need to think more specifically about how this could benefit the projects we’re initiating. Arguably then, it’s at this point that we need to put the purist definition back in the textbook and focus on the real-world benefits and disadvantages for our projects. The points below are those we discuss with our clients, in a more pragmatic vein, noting they are discussion points…!

What does it mean in practice?

Potential advantages of an MVP approach
  • You may be able to define a smaller, shorter initial implementation, which will carry less risk and involve a reduced initial investment in time and resources
  • You may be able to use MVP as a leader to prove that you can deliver successful projects
  • You will learn a lot from the project as a whole:
    • About the tech how it works, what it’s capable of
    • About the partner
    • About yourselves, your culture, your appetite for, and attitude towards, to change
  • You can identify champions and those who want to develop within your organisation
  • You should get a big data (and/or content) migration hurdle out of the way (as you’re replacing your current solution)
  • The scope can be adapted over time (but this comes with health warnings!)
  • You’ll be able to review business processes incrementally
  • You could go live with a ‘skinny’ but successful MVP and go on to build out a better informed, and de-risked, complete solution
Perceived drawbacks of the model
  • Your project may be seen in some quarters as a once in a lifetime change, which will exhaust you, so it needs to be one-pass generational change and a small MVP won’t cut it.
  • Your funders and senior stakeholders may be underwhelmed at the prospect of an MVP which only replaces current functionality despite them signing off a significant investment.
  • You may create a bun fight for what’s in scope.
  • Some stakeholders will resist and question “Will there ever be a Phase Two?”: you’ll need to give clear assurances.
  • You do still need to fund and resource the full project.
  • The demands you’ll place on your resources will go on for longer.
  • You need to be able to make resource available to run your MVP release as your live system, plus retain a project team for Phase Two – with a particular crunch around key resources, and your project team

Suppose it doesn’t go so well, MVP extends, everyone gets tired, the money runs out…

All of these points are valid for discussion and need to be carefully considered, in your context

By analysing the points above and seeing which weigh strongest on you and your organisation, you’ll start to get a good sense of the ultimate question…

Is it right for me? Or how do I know if it’s right for me?

In light of the pro’s and con’s above, it’s important to asses them against the criteria below:

  • People and the demands you’ll place on them
  • Culture can your organisation cope with the nature of incremental change
  • Budget can your budget be flexible and long-lasting enough
  • Discipline do you and your team have the discipline to manage scope

To succeed with an MVP approach you need a clear vision of the scope of your MVP and subsequent Phases, also based on what you need when.

In the eternal love triangle of time vs scope vs budget, we find that an MVP model works best where Time is the driving factor in the initial project. This is especially effective where you have hard timelines, driven by external constraints

Consider what capacity you have to deploy workarounds after the MVP release, from both a capacity and also user buy-in perspective.

Critically consider what resources you have available to deliver multiple releases, and to transition them into new ways of working whilst working on the next release.

Finally, test out the technology partner you’re working with: is MVP a core part of their model or is it opportunistic? If they’re promoting MVP because it’s on trend as opposed ot being baked into their method then it’s best avoided.

At the end of the day of course, MVP isn’t a new and radical concept.

The principle of defining phased implementations of new technology, as opposed to “big bang” launches, has been around for decades and remains a strong option for anyone. It’s become the current trend on the back of Agile’s current pre-eminence, but you don’t have to adopt a full Agile model to benefit from some components, so maybe that’s the takeaway.

When planning your implementation, break the deliverables out into potential phases and see if that’s viable for you. Can you replace elements of your current technology landscape incrementally, maintaining business-as-usual, without degrading services, and without having to invest significant additional funds to re-work integrations through the phases.

If you can, if you can resource it, and if culturally you buy in to the concept, then consider whether it’s more beneficial for you than one big implementation, including the considerations listed in this article in your decision making.

As a final “if”; if a phased model works for you and your technology partner, you can come back round to the original question, knowing what your drivers are for a phased implementation. Consider how close you are to the MVP minimalism of launching iterations of “what you need, when” with the primary purpose of learning from each iteration and using that feedback to influence the next phase, including building out full feature sets.

By then you’ll have worked out whether you’re going for big bang or a phased approach; whether you’re going for a phased approach or an MVP model; and whether the last point is just semantics!


For more insight into what it takes to implement new digital solutions, join our free-to-non-profits Training Programme “How to deliver successful projects”. The whole course is based on our in-depth knowledge of change programmes and project delivery, including Module 5 “Delivering a successful system implementation