The Importance of Scope (and How To Ship It!)
One of the lessons I’ve been mulling about the past few weeks is the importance of scope when delivering software.
Delivery of software can be thought of as a balancing act between three buckets:
- Time – this is the schedule and how much time you have to complete the work.
- Money – this includes everything from spending on more resources, better resources, tooling support, and so on
- Requirements – this defines what you’re building
These are the three basic buckets that constrain the scope of what can be done and they react to each other in different ways. If there are more requirements or the requirements are inflexible, then it necessitates more time or money or both. If both requirements and time are inflexible, then more money will be required to achieve the goals within those limits. If money is constrained (less resources), then you must allow more time to deliver the requirements or trim the requirements.
Having been in consulting and in software development, each project has different priorities on which is more important and these priorities drive the sizing, cost, and pace of the project.
But in software development, I think one thing that I think many folks — even experienced individuals — get wrong is the fixation and inflexibility on requirements. I think that requirements are really much more fluid in software development projects as compared to contract-driven consulting projects. The reason is simple: in software development, the assumption is that there will always be another version and there will always be another point release; this is exactly what roadmaps are for.
Plan a solid roadmap and if you don’t get a particular feature or capability in this release, you and your customers should have a good idea of which release it will be in down the road.
Some tend to lose sight of this and think that all features must be shipped in a constrained timeline. I think this is a losing proposition that forces a team to compromise on quality by artificially forcing requirements into a release when the reality is that there are often really critical features that must be delivered and there are nice to have features that would be great if they could be delivered. Teams and leaders without discipline and a focus on the criteria of success will have a difficult time discerning the two and lump nice-to-haves right alongside the critical work items. This is a recipe for failed projects, missed deadlines, and poor quality.
The reality is that software rarely comes out fully baked unless you’re NASA launching a space mission worth billions of dollars and you only get one shot; most teams are not under such otherworldly constraints. There will always be something that could be better or easier to use or some missing feature discovered along the way or some new idea. The trick for teams that succeed is being about to create boundaries on what is needed now.
Apple shipped 7 versions of iOS before adding support for third party keyboards and NFC.
NPR’s first mobile site was terrible (I don’t have a screenshot of it, unfortunately), but at least they shipped it and their audience could use it and now they’ve evolved it to be a clean, responsive web site.
Here’s what the an early version of Facebook looked like:
Courtesy of Wikipedia
And Amazon:
Back when it was just a bookstore
Microsoft shipped Azure without support for virtual machines until 2013.
But what if instead of new features, we’re talking about bugs or design flaw? There is an important calculus at play here and I think that one way to think about it is like this: if there is a bug or design flaw that is preventing increased growth in userbase or revenue, then that takes precedent over any other bug or design flaw that is in the shipped system. Think about it this way: if you ship four versions of the software with the bug or design flaw, chances are, you can probably ship a fifth without addressing it (of course, this is not always the case, especially if the flaw is related to security). But if a bug or design flaw is stopping adoption or holding back revenue, then that flaw automatically becomes the most critical focus for a release.
The point is that in software product development, more often than not, the winning strategy isn’t to get it perfect (as much as Steve Jobs would have you believe that he got it perfect each time, the fact that there was a next release meant that it was intrinsically not perfect — there was always something to improve or add); it’s to get it out and ship it and acknowledge that there will be a future release to add features or other improvements. This really allows the team to focus on what’s critical now and get it out the door and on time.
To that end, roadmaps are important as a communication tool and a lever for controlling scope because it gives customers visibility and a sense of certainty that while feature X is missing in this release, in 3 months, it’ll be in the next point release. It’s important because it helps manage the requirements bucket; without a roadmap, the tendency of the team and customers — in my observations — will be to assume that every requirement is critical. It’s a purely psychological notion because the lack of the roadmap makes it difficult to allow the team to offload some ideas and lesser requirements so that the team can focus on the requirements that are truly necessary to ship it. Without the concrete notion of The Next Release, the feeling will be that everything must be crammed into this release.
Ultimately, I think that for software development teams to successfully ship software — given the typical constraints of time, money, and requirements — it’s important to be able to take a critical eye to the requirements and really be able to categorize and define the scope of what is critical versus what is nice to have. A clear roadmap is an important tool to help teams organize work and thoughts as well as communicate intent to customers.
