Making prognoses are hard. There is no exception on this in IT. There are many ways and methodologies which they try to set some sort of framework up in order to do one but crucial thing: correct project / task assessments whether in terms of time or costs.

By definition, there is no person who knows the future but without trying to set some sort of deadlines and costs prognose, no business would be possible in this world. Let’s take a look why it’s so hard, why most advice doesn’t work and what we can do about this.

{.image-two-thirds-width-size}

IT projects and tasks are unique

IT projects are unique. There is no 2 the same software developers, no 2 the same problems in most projects, no 2 the same business situations wwithin wich we have to develop the project. Uniqueness of IT projects makes most prognostic tools useless. Most IT projects are 0-1 products. There may be some similarily sounding products but not the same. No methodology is believed to be ‘bullet proof’, there are no ‘opinated’ solutions which withstand all IT development factors.

It’s kind of different comparing it to ‘mass produced products’ where all details are known, design is made upfront, you cook the batch and send it to the customer within 2 weeks. Many of products have subcomponents but most of them are standarized and you can order them from multiple providers from any factory you wish to have. In IT there are no standards, no guidelines, no opinated providors on which you can always rely.

IT projects are different, more like R&D scientific projects. You set the goal, you are most likely the first person who tries it in this way, no guidelines and no guarantee to succeed. You may ‘complete’ the project with conclusion that you made it but the solution is not viable for application on the real customer market.

How many businesses are willing to accept such a risk and survive negative consequences if the project fails? Not many of them.

Lies, damned lies, statistics

In the beginnings of software engineering methodologies, wise people tried to use some statistical tools for assessment as it’s done in most life-science. However, IT is the case wher it fails miserably. When projects are unique, how do you want to apply statistics on them? You can count multiple factors in IT which may influence the project but how do you want to make buckets for them to make a histogram, average, median of results? Abundance of possible factors well defined or not makes IT projects virtually not possible for describing them in terms of statistics.

Random events

Life is a source of countless random events. While we cannot exclude them from equation, we still have to take them into an account due to possibility of their extreme negative financial consequences. That’s why, after all, insurance angencies have been created. However, how can we protect ourselves from that risk, when we cannot predict them with statistical tools? It’s hard to make it correctly and thus nobody have ever came up with making an insurance agency from IT failures. Though, I wouldn’t complain about it if somebody did so.

Existing solutions and why most of them don’t work

Having in mind all possible pitfalls, problems and difficulties, people have had to come up with some methodology how to deal with IT projects. Otherwise, it wouldn’t be possible to conduct that business. In this chapter, I will discuss some of existing ways to do it.

Scrum poker

Scrum poker relies purely on so called ‘wisdom of the crowd’. While it may work in real world, usually corporate conditions make it not possible due to various reasons. The idea is pretty basic - you gave the task description and people vote how many ‘story points’ not workdays (abstract unit of complexity what may mean all and nothing). Then by taking average, median or whatever else measure you want to get a perfect task assessment. How is it supposed to work? Most people don’t know, almost none of them asks about it. There were much wiser people who invented this way of doing things, for sure. It reminds me pretty much throwing dice. An ancient method of predicting future by putting ourselves in hands of ‘higher forces’. We have fun of ancient people reading about their practices before going on war but are even better in this matter? With all technology we have, mathematics, physics, sociology the only solution we have is to play a poker or throw a dice.

Fibonacci scale

Fibonacci scale in scrum poker is the most extraordinary thing used in software engineering methodologies which being at least ‘not proven’, nobody questions it all but uses it.

The basic idea is based on a mythical so called ‘golden ratio’ or ‘divine ratio’ - it’s believed to exist almost everywhere in the world. Fibonacci series is a good aproximation of that ratio (neighbouring elements ratio). Thus, logically or not, if it exists everywhere, it should apply also to IT projects assessment. That’s obvious, isn’t it? Not for me but well it’s widely believed and cited ‘truth’. Who am I to question it?

Delphi methods

Delphi method is called sometimes ‘expect method’. It reminds the delphi oracle instance as people ask ‘higher order’ to provide deeper insigher. However, as said, experts tend to fail so many times that there is little proof if such methods are really better than a group of diverse crowd in opinions.

Can we do something about this?

Retrospections

This chapter will cover the topic of retrospection meetings used in many methodologies:

• why it’s the most misunderstood thing in scrum,
• why it doesn’t work,
• and why finally it may work.

In most situations I faced, it was focused more on measuring developer team’s mood than checking why our task assessment differ from projections. No, it would force people to start looking for possible faults, mistakes, wrong assumptions what is unacceptable in era of not bothering people. You need to be kind, team player, not to put blames on somebody and destroy good atmosphere of team collaboration spirit.

However, I am strongly convinced we have to drop it. There are many sociological aspects which make task asssessment even harder. I would start from the following ones:

• no analysing before what needs to be done in details (except very obvious cases),
• influence of team to lower task complexity,
• hurra optimism of junior developers,
• task assessment based only on development phase. Not including things like:
  • code reviews,
  • clearing acceptance critierias out during scrum sprint,
  • random events,
  • vacations,
  • absence of senior developers,
• not assessing dependencies,
• assessing non atomic tasks.

I mentioned only the most important of them but they are crucial. Influence of team on lowering assessment, destroys pretty much of all ‘wisdom of crowds’. People who stand out from average need to be ‘prove’ their judgement but even very senior experts and gurus are not able to do it. They say, they ‘sense’ it intuitionally and still most of them are wrong.

Wisdom of crowd

There is a theory that you can extract knowledge from a group of divers enough crowd. To be able to use that, there are certain conditions to fulfill it. We cannot force people to prove their opinion / statement. Nobody can because most people even though they know something from experience, they cannot proove it scientifically. It’s strange but that’s why how it seems to be working. We can only rely on people’s intuition and surprisingly it seems to work as people take actions based on experience, in good faith and on their own benefit. We cannot measure it statistically but most people will choose the correct action based on past actions and examples. Most situations, actions, decisions are not new. We do them on the daily basis. However, the decisions we do, are usually limited in scope of size and time.

https://www.amazon.com/Wisdom-Crowds-James-Surowiecki-ebook/dp/B000FCKC3I

What we can assess and what not

Having in mind all things we discussed before, conclusively we can assess only small things what happen in a short time but not the ones which are big and what happen in a far future. That’s why people break big tasks on smaller ones. Let’s discuss howe we should do it.

• tasks should as small as possible but not smaller than it’s comfortable for developer,
• tasks should be atomic,
• tasks shouldn’t have dependencies,
• tasks should be possible to do them parallely (thus atomic with no dependencies),

When tasks are atomic, with no dependencies and crystal clear we can easier assess when they will most likely be done as their will be smaller in scope.

When we cannot decide on task assessment, it means that it’s not clear enough so it needs to be analysed (as a 1-2 days task) by senior developer in depth what exactly needs to be done here. Only afterwards we can try reassess this task once again.

Summary

As we explored all possible solutions and pitfalls, we see now that there is no good way to do it. However, we do know what to avoid, too. I can’t say what’s better - knowledge how to do or knowledge how not to do, but at least we can choose some small steps in the well defined direction. Whether we succeed or fail, that’s a good question.

Also, we can always resort ourselves to the old solution used by our ancenstors going on war. Let’s cast dice. After all as it’s said fortune prefers the bold ones.