In Joseph Heller’s novel Catch-22, the main character, a U.S. Army Air Forces B-25 bombardier John Yossarian, appeared in an absurd situation. To return home, he had to fly a definite number of combat missions. But every time he had flown enough missions to go home, the commanders increased the number of flights required, so John’s military service seemed to last forever.
Team found itself in a similar situation when we had to deal with constant scope creeps during a project of refactoring a legacy mobile application. We kept working on the app, but the project’s end seemed to never come. Even though these memories are a bit painful to recall, we would like to share with you our story, so you can learn how to avoid scope creeps with your own software development project.
The client’s app was outdated and required a lot of refactoring
As it often happens in horror stories, there was no hint of disaster coming. A customer just turned up with a request to refactor the code of his mobile app product.
The mobile application had to enable users to post creative photos of their favorite places like cafes, bars, spa resorts, events, and similar in exchange for rewards they can redeem to buy products and services at these places. In turn, businesses are able to market themselves through social networking and influencer channels, thereby creating additional streams of revenue.
Our mobile developers got a general task to refactor the app’s code where necessary and rewrite parts that were working poorly. Everything seemed to be clear and easy. But that’s where we were wrong.
No plan, no specific software requirements, no exact expectations resulted in an endless work on the application. After every single update of the code, the customer came up with new requirements as he revealed more problems with their legacy app. As a result, the project had exceeded its initial budget, while the end wasn’t even on the horizon.
Now, it definitely seems like the story is about to reach its tragic finale and we’re going to talk about how we threw the towel.
How we managed to escape the scope creep catastrophe and ace the project
Even though the project faced numerous changes in scope, it wasn’t too late to fix everything with proper project management. Luckily, we have talented project managers on board, so here’s what was done thanks to their help:
Writing software requirements specification
We wrote a detailed software requirement specification (SRS) to determine what specific business and technical goals the application should achieve after the code refactoring. By writing down all the requirements, our team got a vision of how to fix the outdated app entirely and what phases it had to pass through to become a fully functional product.
What’s more important, the SRS helped our team divide the entire project into individual milestones, including bug fixing and code deployment. We introduced the SRS and the project plan to the customer, so they could see the amount of work to be done and set their expectations accordingly.
In such a way, we were able to inform the client about every stage of the project. At the same time, our mobile developers got a clear direction of what they need to do for each phase.
Planning the project’s scope in sprints
Sprints are the most fundamental principle of Agile development. Project manager divided the entire project into sprints with definite scopes of work that should be done. We discussed each sprint with the client to get their approval.
Sprints helped us avoid continuous changes of the scope. When the customer wanted to make the changes on the sprint that was already closed or in progress, we notified them that it would be a change request that would be processed separately as it didn’t belong to the scope we had agreed upon before.
Thanks to planning the project in sprints, the customer got a clear understanding of how their change requests impact the application and the project’s resources. The project became truly agile, as the development team progressed with refactoring step by step and processed any change requests without interrupting the work on the primary tasks.
Communicating the goals, expectations, and hurdles with all stakeholders
George Bernard Shaw once said: “The single biggest problem with communication is the illusion that it has taken place”. And that’s exactly our case: we believed our team and the client understood each other well enough to start the app refactoring.
After getting the project on the right track, communicating all the plans, barriers, and changes between the customer and development team was essential. Our project manager heroically took the responsibility to keep both parties informed.
For example, when the development team reported that a particular functionality couldn’t work, the project manager explained it to the customer and described alternative solutions proposed by our mobile app developers. When the customer requested another change, the development team was informed what should be fixed and how.
On a side note, we would like to pay a tribute to our project manager for communicating the customer’s business goals and the contract’s agreement we were obliged to follow. In that way, the development team was able to see the project beyond the context of tech tasks, which helped them avoid wasting time on asking numerous questions and clarifications.
