Using Agile on a rebuild or redesign project

I’ve used Agile on a large number of projects and one challenge that I’ve noticed on quite a few occasions is that of recreating something that already exists.

That ‘something’ might be an organisation’s website which needs to be upgraded to a newer CMS, or a more recent technology. It could be a change of supplier. It could be a combination of those things.

Why is this such a challenge?

There are a number of potential pitfalls on redesign, rebuild or upgrade projects, the most common among which is neglecting to come up with a compelling vision for the product.

A product vision is a statement of intent that sets the agenda for a Scrum team. All their subsequent work will be based on it. In the words of Ken Schwaber: “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.”

Often in a redesign/rebuild project the organisation won’t take the time to fully understand where value is to be generated and end up with a vision like “Recreate everything we’ve got and make improvements where you can.”

This causes problems in a number of ways.


Obviously a vision like this is hard for a team to buy into. It doesn’t articulate the value that the team is seeking – what’s the value in recreating something that already exists? If there’s no difference in value between the features that already exist and the ones you’re about to build, what’s the benefit in building them?

Since Agile/Scrum is a value-centric framework, a vision like this doesn’t really do the job.


The benefit in being able to accept change is also lost with such a vision. Framing your thinking in terms of the pre-existing locks a team into the same mind-set that the creators of the original product were working from.

Presumably the organisation, market and world have changed since then (or why bother rebuilding at all?) but by providing a weak vision which is based on the old product you’re not enabling your team to react to those changes.


Finally, by neglecting to provide a compelling vision – the framework on which the team will base all its intermediate goals – you run the risk of demoralising the team and turning them off Agile/Scrum altogether.

Why does it happen?

Most of the time it’s not a lack of imagination but fear that drives a “recreate what we’ve got” brief. Stakeholders are understandably risk-averse and don’t want to take the chance that what they’ll end up with is a step-backwards in terms of the value it provides to the organisation. The thinking is that by recreating, with a few extras, you fix a baseline value that you can’t drop below.

It’s an understandable position then, but it’s also one which fails to articulate the bigger strategic aims that need to be aimed for and met by the project. The fear that drives product visions like this has to be addressed if you’re to avoid a project where you’ll spend some of your time not actually delivering value.

How do we avoid it?

These are my top recommendations for generating maximum value on a project where you’re recreating something that already exists:

  • As a starting point a strong vision should be identified e.g. “Create an engaging, interactive website that brings supporters closer to our cause, increases donations and represents our brand”
  • An Agile discovery process should still happen. This might involve specific engagement with stakeholders to find out which bits of the current product they don’t really need and what new features would make a real difference to them.
  • User stories about technology or which are internal centric should be rewritten in terms of the user wherever this is possible.

Lastly, if recreation of everything really is essential to the project then it would be wise to explore setting a bigger vision with the first release, or two releases, focused on the redelivery. Subsequent releases can then focus on working towards the larger aims of the project, and adding genuine value, rather than just tinkering with vaguely defined ‘improvements’.

What’s your experience?

That’s my two pence worth. Have you worked on a project where you’ve been using Agile to recreate an existing product? I’d love to hear about your experiences (and any additional tips) so please do share them below.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. […] campaigns and websites, recently held an event for charity and non-profit digital teams about how Agile can help make digital and comms teams more effective. Jon Clarke, Director of Innovation at Space […]

  2. Garrett says:

    This article is fantastic to say the least.

    I don’t have much experience in agile but I’m making a transition to the agile method for future projects for many reasons but a couple to note.

    It is becoming clear that a traditional approach to a web project such as information architecture->design->development->deployment is a huge waste of time before you know what you’ve built actually works. Focusing on smaller chunks at a time can only lead to a finer tuned product. It has to, right?

    It also seems like it would create a better relationship between you and your client. Through iterations, you’ll learn so much more about your client’s business and become more valuable to your client with that knowledge – It seems like a better model for client retention. Not to mention that I think a client would be happier to be up and running quicker.


    When you deploy at the end of each sprint, are you always measuring user behavior for a specific period of time after its release before the next release? With agile, its my understanding that its a “rapid release” process but how long should you measure user behavior before validating what you’ve done is working and moving on to the next sprint?

    I’m confused how agile can be used on large-scale redesigns. Specifically, sites that have thousands of hours invested into their content creation – content that doesn’t necessarily solve business problems. The first release of the minimum viable product needs to include all of that content so you don’t take a huge SEO hit right? I guess I’m confused what an initial deployment or first release would look like on a site with thousands of pages of content already there. Does that make sense?

  3. Jim says:

    Hey Garrett,

    Thanks for your comments. We certainly see clients grow in confidence with Agile once they start seeing things being delivered.

    With regards to your questions…

    When you deploy depends on your team’s definition of done – and shipping may not be every sprint (to production). Feedback loops from users can vary a lot based on many things (size of organisation, tools in place etc). Lot’s of teams have feedback loops during the UX process, user testing feedback loops and then also data driven feedback loops (e.g. MVT testing).

    All of these are valid – but ultimately it’s up to the product owner to decide how best to use the data they have to drive product development. This is a tough job and I think perhaps is one of the reasons data science is becoming increasingly important – the ability to make sense of all the data we have can be a challenge.

    With regards to a major redesign there are a variety of options. You could migrate the content and maintain much of the URL structure and then address the content improvements incrementally – if creative is the main driver.

    If information architecture is the main driver of the project you might be able to address this in the existing platform.

    Assuming it’s a new IA, new design, new platform then your effort needs to do in to a smart delivery plan, good SEO advice and planning redirects carefully.

    Technically you might be able to use a reverse proxy to run the site across two technology platforms allowing an incremental migration.

    I hope this helps.

Sign up for the Manifesto newsletter and exclusive event invites