Scope creep. Virtually every software project suffers from it. Development teams start out with elegant and simple ideas. They toss them around amongst themselves and get excited about the prospect of delivering great software. They engage more people in the effort such as business stakeholders, power users, and senior managers. As they do, features get piled on — scope creep begins to spread like an infection.
Before long, what started out as a simple, elegant idea is now a complex, hodge-podge of loosely related features and functions. It happens for a wide variety of reasons. Though most commonly, it results from lack of vision and leadership. Unfortunately, vision and leadership can’t be taught in a training class or pulled from a text-book. If your project lacks them, you’ll need to do the best you can with what you have.
The good news is you can still build great software systems by relentlessly focusing on scope control. Start by delivering a strong message to the business community about the benefits of reducing scope. They need to hear the scope-control message in business terms. By reducing scope, they’ll get:
- Increased Value: How do you increase value? Deliver sooner. How do you deliver sooner? Reduce scope.
- On-time Delivery: How do you deliver on-time? Stay focused. How do you stay focused? Reduce scope.
- Improved User Experience: How can you improve the user experience? Put more effort into UX. How can you put more effort into UX? Reduce scope.
- Better Quality: How can you improve quality? Test more. How can you test more? Reduce scope.
- Lower Cost: How do you reduce cost? Build smaller systems. How can you build smaller systems? Reduce scope.
- Reduced Complexity: How do reduce complexity? Narrow the solution space. How can you narrow the solution space? Reduce scope.
- More Accurate Estimates: How can you improve your estimates? Take on smaller chunks of work. How? Reduce scope.
Do you see a pattern here? Smaller is better.
I know some will argue that, at times, business problems are so complex that the software has to be equally big and complex to solve them. While there’s some truth in the assertion that some problems require complex solutions, there are simpler ways to deliver those solutions. Start by decomposing the solution space into multiple components — loosely-coupled.
For example, use add-ons or plug-ins so that users who need additional complexity can install components while those who don’t won’t. The add-on components can be delivered separately by independent agile development teams allowing each team to stay focused.
Also, make the application configurable either via config files or a database. Let the end users decide how they want the software to look and behave. Focus on building flexible, rules-based systems not specific features. More rule types can be added over time — after initial delivery dates are hit.
Spend less time planning, estimating and arguing. Spend more time building and delivering by keeping scope under control.