Early Delivery of Usable Software
This week, on two separate occasions, I was reminded once again about the value of delivering usable software early on in a project.
Developer A had an uncomfortable meeting with an internal stakeholder. The stakeholder had found out that one of the planned, non-functional requirements was not going to be fulfilled due to architectural constraints. This architectural problem was not a surprise for our developer. In fact, he had warned the same stakeholder about these constraints already last year.
What was surprising for the developer was the fact that this non-functional requirement was such an important issue for the stakeholder. You would have thought that if this requirement was truly important, the stakeholder would have said something when the developer warned him that this requirement isn't probably going to make it to the final product.
Developer A is currently worried that the whole project is going to get axed because of this unfulfilled requirement. His team might have to go back to the drawing board after months of work.
At another company, developer B had just delivered her project to the client. While the developer and client were happy about reaching the end of the project, they weren't so happy about the fact that they had done so by going over budget and missing the initial deadline.
The initial time estimate for the project was six weeks. After the first two weeks of development, the team realized they are actually building the wrong features. They had to trash all the code and start from scratch.
Imagine cutting one third of your budget without reducing the scope. Even after getting some additional help and putting in extra hours, the team couldn't save the project.
The developer and client saw the project as a case study in poor planning. However, I cannot help but see this project as a success story.
Yes, there was a big misunderstanding of end user needs that could have been avoided with more open communication. But at the same time, this misunderstanding was discovered very early on in the process.
Two weeks is a lot when your budget is six weeks. But two weeks is also the standard length of a development sprint. Imagine not noticing a critical misunderstanding sprint after sprint, month after month, until you finally let the users take your product out for a spin only to immediately come back to you with complaints and disappointment.
It's too easy to keep your stakeholders waiting to get their hands on the thing you're building. We often focus on "building the thing right" and finalizing individual features before we let anyone test out the software in an actual setting. We do this to avoid unnecessary criticism towards unfinished features and confusing our stakeholders. But at the same time, we take a risk of not discovering major misunderstandings about our requirements. Developer B and her client were able to avoid a much bigger cost overrun by giving users something after the first two weeks of development.
It is true that sometimes it's not possible to deliver usable software after two weeks. However, I think most of us can agree that often we don't question ourselves enough when we say something is not possible or feasible. If we would really want to deliver something usable within a shorter span of time, we would probably start coming up with alternative, more creative ideas for achieving that goal.
Another argument against early delivery of usable software is that it might be more efficient for teams to finish one feature at a time or focus on building a strong foundation in terms of designs, infrastructure, and background systems. However, this approach will also increase the risk of costly misunderstandings.
You take a gamble when you don't ship anything usable early on in your project. If the risk of possible misunderstandings doesn't manifest itself, you should probably consider yourself lucky—not a master at planning.