June 2017 – Tech leadership

Where do unrealistic schedules come from?

This situation is so common, it is by now something of an industry standard. There is almost no project that I have stepped into that had an appropriate amount of time scheduled for it.

You have to wonder why after all these years we still suck at allocating enough resources to get the project done in time.

In this entry, we will be looking at some of the common factors that lead to unrealistic schedules.

External deadlines

Development happens in a context. Unless it is a hobby project, you can be sure that whatever you are working on, someone else is depending on your work output for them to do their job.

A special case would be where the bid specifies the timeline in which the product must be built. In this case, submitting a longer timeline, even if justifiable may mean losing the project.

Since the project is still of interest to the team, the team takes it on knowing full well how tight the deadline is in the process displaying a mix of childish optimism and wishful thinking.

Best case estimates

Murphy warned us:

    Whatever can go wrong, will go wrong

Scrum and other agile techniques give us robust estimation tools. But even with those, we more often than not end up with a range, say 3 – 5 months.

Unless you don’t like promotions, who wants to go to the boss with the higher estimate?

Of course, the problem with the lower estimate is that it holds the implicit assumption that everything will go right.

This is a dangerous assumption, you take it for granted that you have the best tools, language, physical environment, skills etc. When something does eventually go wrong, you find yourself with an unrealistic schedule.

Feeling up to a challenge

For reasons that are beyond me. Some developers prefer working under insane conditions. Something about an all-nighter makes them feel like heroes.

Whether inspired by cut throat work environment or personal bias, teams in these kinds of environments will consistently underestimate how long the project will take.

Even if the pressure is acceptable in the short run, the effect on the team morale and product quality are bound to suffer. Better to have a reasonable schedule and spend any extra time beefing up the quality.

Belief that developers work better under pressure

Authors of the Design Sprint state:

    Times of need can be artificially manufactured by creating deadlines. Our brain doesn’t know the difference. When you create deadlines, your brain stops procrastinating and gives you what you need.

It is easy to extrapolate this kind of thinking to the entire project.

While you do need to pace yourself, you need to be very careful of the kinds of commitments that you make. In a previous entry Estimates, Targets and Commitments. We looked at the dangers of confusing the terms.

You don’t want to make a commitment to your client based on the belief that somehow the deadline will boost productivity if you must make such a commitment, let it be internal.

Scope creep

Inevitably, new ideas will come in. Change is a core part of the software development process.

The problem arises when new changes are introduced to the project but nothing is removed from the backlog. As new features are added, eventually the entirety of the work pushed the project to an unrealistic one.

We have looked at this problem in greater detail here Managing scope creep. The TL;DR is any new change is also a chance to renegotiate commitments.

Have you faced unrealistic schedules in your own practice? How did you handle it? Talk to me in the comment section below or on my twitter @jchex

Why you should do estimation in groups

More than any other activity, estimation of size or effort it will take to build a digital product is based on individuals. Even worse, the responsibility tends to rest on the team lead.

In the midst of the flurry of proposal writing, it may feel like a waste of time to bring in the development team to work on the estimates using a practice such as planning poker. Better use a shortcut and just call the most senior developer and have them give you the estimate.

In this entry, we will be looking at why this is a bad idea and why group estimates tend to fair better than individual estimates, no matter how senior the individual doing it.

The elephant in the room

An old Chinese parable explains this concept very well. Here is the story quoted verbatim:

    Once upon a time, there lived six blind men in a village. One day the villagers told them, "Hey, there is an elephant in the village today."
    They had no idea what an elephant is. They decided, "Even though we would not be able to see it, let us go and feel it anyway." All of them went where the elephant was. Everyone of them touched the elephant.
    "Oh, no! it is like a rope," said the second man who touched the tail.
    "Oh, no! it is like a thick branch of a tree," said the third man who touched the trunk of the elephant.
    "It is like a big hand fan" said the fourth man who touched the ear of the elephant.
    "It is like a huge wall," said the fifth man who touched the belly of the elephant.
    "It is like a solid pipe," Said the sixth man who touched the tusk of the elephant.
    They began to argue about the elephant and everyone of them insisted that he was right. It looked like they were getting agitated. A wise man was passing by and he saw this. He stopped and asked them, "What is the matter?" They said, "We cannot agree to what the elephant is like." Each one of them told what he thought the elephant was like. The wise man calmly explained to them, "All of you are right. The reason every one of you is telling it differently because each one of you touched the different part of the elephant. So, actually the elephant has all those features what you all said."

    Source: [jainworld](https://www.jainworld.com/literature/story25.htm)

The idea behind this story is that we all have different viewpoints. Until the software product is complete, it is mostly a jumbled mess. Everyone in the team sees only a small part of what the work would entail.

In short, you need the whole team to see the elephant.

Human folly

As a species, we named ourselves Homo Sapiens literally translates to wise man. We couldn’t have been any more wrong in this assessment.

Human reasoning is terribly flawed. The list of our biases is so long that not even a single volume would be able to contain it all. That is not to say they have not tried, see Predictably Irrational, Misbehaving and many other such titles.

Wikipedia has a list so long that it would fit a couple of articles and that is not considering their definitions.

In short, when an individual does the estimates. They will probably seek reasons why their estimate was right rather than getting to the right estimate.

Thankfully, we also evolved a way to combat our biases, arguments. Constructive arguments around the estimate will help everyone think more carefully about their estimate and thus raise the overall quality of the final estimate.

Deep understanding

In an article Minding matter, the astronomer Adam Frank says something very interesting

    When I was a young physics student I once asked a professor: ‘What’s an electron?’ His answer stunned me. ‘An electron,’ he said, ‘is that to which we attribute the properties of the electron’

He does go on to explain the statement. For the sake of this entry, it suffices to acknowledge that the reality of what the product will be is as much what the developers will make it, as it is what we think is an objective product out there.

If this is the case, then understanding the different viewpoints can help us get a far clearer picture of what the developers intend to build and thus a better estimate of the size and effort required.

The rule of five

I like the quote

    Always remember that you are absolutely unique. Just like everyone else.
    Margaret Mead

It reminds us that at the end of the day, our estimates will likely cluster. This is not folksy wisdom. It is a statistical fact. There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population.

Take this rule in comfort, it means that while there is a great benefit to having a group do the estimates, the group needs not be bigger than just 5 individuals.

Do you do estimation in groups in your own organisation? Talk to me in the comment section below or on my twitter @jchex

Sprint is over, now what?

You have just completed your development sprint, done the demo and the review, what next?

The easy answer is jumping into the next sprint. That is of course until the end of the year when reviews are up and you are asked to specify what you have been doing the whole year.

Showing working products is great, in fact, the agile manifesto clearly states:

Working software over comprehensive documentation

Note that they didn’t say No documentation!.

Even if they did, what seems very clear in your mind right now about how the days were used may not be so clear months from now.

Thus my recommendation is that you write a brief report for yourself. It does not need to be official. You can even just call it skipper’s log.

Below are some suggestions on what to include in the report.

Notable events

Not everything that happens in a sprint will be seen in a demo. Perhaps Rico, your new developer, mastered SQL or your team was acknowledged during all hands and other search achievements.

If you do this consistently enough, you will have your team’s story, one that perhaps you can celebrate at your end of the year party, use to review salaries or make decisions on how and what to invest in the team.

Sprint dates

Of course, the start and end dates of the sprint are obvious, how could they not be? Still, the past has a way of blending into what seems like one long day. In this cases, it helps to know that the Sprint commenced on 5th June and ended 15th June and that within this period there happened to be one public holiday or a team mate’s birthday.

This information may give you insights in future planning sessions, specifically how blocked of days for development play out in practice.

Team velocity

Thankfully, most project management tools aimed at software teams will automatically compute this for you. If yours doesn’t. It may be worth it to do the computation yourself.

Velocity = Total story points done in this sprint
Average Velocity = Total story points complete/Total sprints done

You can then chose to plot this information in a burndown chart.

You may want to consider printing out the burndown chart and hanging it on your team wall if you have one.

Retrospective actionable

Your retrospective will likely come up with good practices for the team to implement in the future. While this information is already captured in the retrospective document, I consider this information so important that a little bit of redundancy is allowed. In short, have it in your skipper’s log as well.

This will allow you to quickly reflect on what you thought at the time was important to improve on and thus see how things have evolved since then.

Sprint summary

This would be a subjective account of how the sprint was. With all the talk about objectivity in our industry, telling you to record your subjective experience sounds rather counter productive.

Still, I have found that AHA moments can come from reflecting on your state of mind in action.

What do you, as an individual do at the end of the sprint? Talk to me in the comment section below or on my twitter @jchex