Can Scrum be used for projects with a fixed date contract? That question comes down to how much you care about the quality
of the software you are shipping. Why? Well, in the real-world software project contracts, two things are always
strictly specified – scope and date. However, the quality of the shipped software is usually left out.
There are two main reasons for leaving out the quality out of the contract. First, it is really hard to specify quality on
paper. Can it be measured by the number of the bugs, or by the severity of those bugs? Unless the bug is completely
blocking the usage of the software, bug severity is something that is prone to discussion, which is why quality is hard to specify in the contract strictly.
This is the reason why projects with fixed date often tend to fulfill the scope by the set deadline, but quality is the first
to suffer. So what does that have to do with using Scrum for fixed date contract projects? In short, Scrum
is about breaking development into short cycles and iterating development of the features which have the biggest
value to the project first, in order to achieve desired functionality and quality. Those who argue that you can
use Scrum to deliver projects with the fixed date contract suggest negotiating the scope instead of quality with
your client while doing those iterations.
What if the whole scope is really crucial for business? We can cite the famous
Pareto principle in favor of those who claim that we should cut the scope first, but truthfully
that principle can be applied to a project that has a vast amount of features. What if you need to deliver a
small invoicing system within two months? In real life, invoicing features don’t really function without vendors
features, and vice-versa. If you happen to be lucky to have a vast amount of features in your software project,
rock-star negotiators on your team and understanding clients, you might consider negotiating the scope cut. However,
that trick doesn't usually work twice. You could use Scrum then, but you really should not.
You can benefit tremendously by providing an estimate that is real, instead of an estimate that your clients want to hear.
So you are saying that I should not use Scrum for projects with a fixed date contract - what should I do then instead? How
can I reach maximum client happiness without overworking my developers? I say, take the best out of Scrum. One
of the great benefits of Scrum is improving the quality and getting feedback as soon as possible by delivering
MVPs to the clients. That is the principle that Scrum utilizes and nothing is stopping you from utilizing it
in fixed date project, regardless of what project management methodology you are using. Deliver an MVP to your
client as early and as often as you can. You should do so not just to ensure that you are building in the right
direction, but also to build up the trust with your clients. Nobody ever said “I don’t care to see the first
build of my product”.
Also, try using some techniques to break down the scope better, plan more precisely, and get to know your teams velocity
better. Estimation techniques like
Planning Poker or Relative mass valuation can also help you to understand the scope of the
fixed date contract. Do not be afraid to voice out concerns early, and place buffers just-in-case. Last, but
not the least, you can benefit tremendously by providing an estimate that is real, instead of an estimate that
your clients want to hear. Even if the competitors are giving what seems the better estimate on the paper, do
not be afraid to underpromise, but then work smart to overdeliver.