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.
In Scrum, Beware of the Re-Write Project
What did you think about this post?
Share with your network
Comments (4)
When you're doing nothing but just rebuilding the existing application, Agile does not have much to offer for this type of project. Requirements are clear upfront and offering part of the value early to customers makes no sense because they already have the old application with it's shortcomings but with all required functionality. I can imagine PO's losing interest because from a business perspective, it's boring! I'd at least consider a waterfall approach here.
When you take the opportunity to add new stuff, remove functionality that is of little value, etc..., it makes sense to use Scrum. In that case, I agree that treating the project as any "normal" project would be the way to go then!
I agree but would question the decision in the first place to just build it like it was without improvement. This is probably the right decision if it's in an organization not yet investing in agile or the business hasn't bought into agile yet.
However, any project would reap the benefits of inspecting and adapting, or working on riskiest features first, or adding some improvements along the way. Also, what about managing uncertainty? Quite often such projects are in outdated technology with few documented requirements. Add some spaghetti code and lack of comments and now you're looking at a complete mystery.
You may start this project and find out one month in that your six month estimate may double if you have to replicate every feature of the old one. Waterfall doeant handle this very well.
Agreed. I'm not promoting waterfall here. Just saying that if all technology and requirements are certain, a defined process would work. But even then, agile will have certain advantages.
I've been on several of these projects and the phrase that sends a shiver down my spine is "As-is functionality". You have an old codebase that has become difficult to work with, but has had years or decades of feature development. I've learned that challenging the impulse to "build all the features we have, but better" is an important guard against death-march projects replicating features that were not even used the first time...