When it comes to progress, there are only two points where we can objectively (well, with high enough confidence) know where we are - 0% and 100%. Anything in between is just guesswork. And people have made very elaborate guesswork tools and systems over the years. Big tools, great methods. But none of that has taken away the fundamental problem - it’s still just guesswork.

The problem with most guesswork is that it’s based only on what we know or can think of. The most significant risks are typically the ones that catch us by surprise. So while some amount of guessing is useful, going too far is sometimes even dangerous (but at least usually futile and waste of time). And trust me, I’ve done my share of those guessworks :). I used to love MS Project.

But, since we can only know 0% and 100%, we should focus on our attention to those numbers. 0% is easy - we haven’t done anything yet. But in waterfall, we start everything (with requirements) very early. We invest some into everything, then invest some more (planning), and invest even more (desing, then coding), before getting to the point where we can evaluate whether it all works or makes sense to our customers. So if we want to know as much of 0% as possible, we should not any work on most of the stuff.

The list already says more than 54 words. There's 55. But they imply much more than their measly number. Let's put a little depth into the 5 critical pitfalls.

Lacking Definition of Done

Scrum is silent on technical practices, simply because it's a work management framework and agnostic to the context. But that doesn't mean the the technical level doesn't matter. Imagine putting Kimi Räikkönen to drive a Lada, will he perform well in a race?

For a Scrum to really take off and work, the team has to at least be able to complete a working version of the product at the end of the Sprint. That's the absolute minimum. It should be better than that, really. Ideally, at the end of every single small modification. The working increment is a confirmation that whatever the team tried to do is working and enables us to actually eliminate the technical risk associated with that change. The smaller the timeframe, the smaller the risk.

The traditional project approach has three core roles - the Customer, the Project Manager, and the Project Team. Similarly, Scrum has three roles - the Product Owner (PO), the Development Team, and the ScrumMaster.

It’s easy to see that the Customer and the Product Owner map rather nicely, since both have the money and the business need. Also the Project Team and the Development Team map nicely, since they are the people who have the skills to create the product needed by the business. 

The last one is a bit trickier. It’s easy to think that they map nicely, too. But they really map only in the goal of that role - both roles want the project to succeed. But other than that, they are the two opposite sides of the “project leadership coin”.