In Scrum, Beware of the Re-Write Project

I work with a lot of companies to help them to improve their development processes and to either adopt Scrum or improve how they’re currently doing Scrum.  Lately, I’ve noticed that a fair number of companies run into problems with a certain kind of project: The Rewrite Project.

On this kind of project, the company has an existing application and, for whatever reason, they’ve decided to re-write it.  It starts out ok but somehow it turns into a little bit of a train wreck – no one knows when it’s going to be done, there’s a massive amount of technical debt (aka. work that’s not completely done), and people are starting to worry about the budget .  You’d think that this kind of project would be straightforward because 1) the organization has a deep understanding of the business problem, 2) the existing version proves that the business problem is solvable and 3) they usually have an existing team who either wrote and/or maintains the existing application.  There’s a lot of knowledge there and these are not incompetent organizations – they managed to write this application and keep it running.  So why are they getting crushed by this project?

I think they’re stumbling because their knowledge lulls the management team and the development team into a false sense of understanding what they’re trying to do and that it’s going to be easy to develop.  In short, it’s software development hubris.  They think it’s easy and that they have the requirements nailed and because they feel they don’t have much uncertainty and then their process discipline – how well they’re doing Scrum – suffers.

If this Scrum-centric organization were tasked with writing a completely new application, following the incremental delivery of the Scrum process would be a no-brainer for them.  Create the wish list of features (the Product Backlog), work with management (the Product Owner) to prioritize the features on the Backlog by business value, then start breaking the work down into iterations (Sprints) and start developing.  It’s obvious to them.  You can’t do everything at once, and some features are more valuable than others so work on small, manageable chunks of the application and deliver completely finished features in the order than that business thinks is valuable.

On a rewrite project, you’ll frequently hear the Product Owner say “we don’t need a backlog – just go look at the existing application and build that.”  So, there’s a definite temptation for the Product Owner to mentally check out.  Then on the development team side of the house, they’re going to think that they understand the application already and either 1) don’t estimate or adequately de-compose the work and/or 2) come up with insanely overly optimistic time estimates.  Put these chunks of Scrum dysfunction together and bad things happen quickly.

The way to break the curse is to change how you’re thinking about the project.  Think of it as writing a similar but new application rather than “rewriting”.  Remember that the original version is filled with hundreds of little and not-so-little dissatisfiers that you’re trying to fix in the new version.  So, whenever you hear something like “build this screen exactly like it is in version 1 except change X, Y, and Z” or “make this subsystem work just like before except make the database better” remember that you don’t understand it like you would a feature in the old version anymore.

When you’re working on a project like this, keep in mind that there’s a lot more uncertainty in the requirements than you think.  Also, remember to keep, maintain, and prioritize a Product Backlog.  Most importantly, watch out for signs that you’re neglecting your software development process.