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.

Buy-in

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.

Agility

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.

Morale

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.