Bad Estimates and Broken Confidence

We missed our deadline, we jeopardised the business’s strategy, and all confidence in our abilities from the rest of the company was lost. How would you recover a situation like that?

Whilst the tech job market is good in London, the team I was working on during that project were absolutely committed to turning things around. And justifiably so. As we started to make progress it was very rewarding.

To get things on track, all we had to do was stop committing project delivery suicide.

Limit WIP

The more work in progress (WIP) the more reason for task-switching and loss of focus. Developers usually need to be able to focus on ideally just one task at-a-time. When there is lots of WIP it usually makes everything take longer due to the cumulative effects of distractions.

As a result of too much WIP we had many incomplete features. The website had lots of crippling bugs — not least that it looked broken. The business thought it was a mess, and could see no signs of progress.

One developer had over 150 tickets assigned to them in Jira. Over 40% of these had been started — project delivery suicide.

We brought down the WIP to 2 or 3 items per-developer, clustered around a single feature. We also told the business that priorities can only change on a daily basis: “If you want developers to work on something else you first have to wait until they finish their current ticket, and you also have to wait until the start of the next day”. With a late, messy project, the business fully appreciated this — there was no friction at all.

Improved visualisation helped us to monitor and adjust WIP.Visualise Process

When you can see the work flowing through the system, when you can see what is about to be worked on next, people can coordinate themselves much better.

If one developer has a task that may need two people to work together, this can be planned during the morning catch-up. If the business want to see what features will be coming next or gauge the rate of development, visualisation gives them a basic ability to do this.

We used the simple “Agile” boards in Jira for visualisation. It was a big improvement over the previous process where each team member would shout out a list of ticket numbers, which meant nothing to half the people in the room.Avoid Hourly Estimates

Estimates got this project into a mess. Every single ticket in Jira, for months of work, had an estimate in hours assigned to it. The project delivery dates were based inflexibly on these hours — project delivery suicide.

Apart from being a big waste of time wrapped up in a complete lie, such precision fails to allow for non-dev time occurrences: bugs, rework, sickness, changes to requirements etc.

Should we expect the business to not want to make slight changes when they start to see a working version of their requirements? I don’t think so. I want to help people make great products, and there needs to be some level of flexibility.

Aside from the unknowns, there are some things we do know — developer estimates are totally inaccurate. This is well-publicised. We even have Hofstadters’s Law.

As soon as we stopped using hourly estimates and told the business — “at the moment, we just don’t know — it could take upto two months extra”, suddenly their whole attitude changed. They mentioned key strategic deadlines, and insisted we cut scope dramatically.

By being honest about the risks associated with estimates at the start of the project, we could have ensured we delivered optimal business value by the fixed deadline. Instead we had to scavenge what we could from all the in-progress work.Waterfall Gets You There Quicker…LOL

As you bring more features into scope, the risk to deadlines grows steeper and steeper. If you have many features in progress at the same time and expect everything to come together just before the deadline — project delivery suicide.

There’s nothing radical here. Waterfall’s limitations are well known. Unfortunately our initial delivery strategy incorporated most of them.

On this particular project there were some old heads in positions of influence who ultimately made the calls. As much as they didn’t learn from past projects, they probably didn’t learn from the failure of this one. As a development team we need to do a better job of accentuating the risks with big-bang waterfall development.Get to a Releasable Version ASAP

To get this project back on track we revised our strategy — we wanted to get to a releasable version of the product as early as possible. This way we could give the business an opportunity to release something, even if it lacked the full scope of features.

With a releasable version there is always a way out — there is always a chance to take what you have at that moment and put something good enough in front of users. With lots of unfinished features all in-progress, the stress mounts and life becomes very uncomfortable because you can’t release anything. Meanwhile the business are going nuts wondering what the hell you are doing with their money.Increase Predictability and Accentuate Progress

To gain confidence back from the business we needed to make our estimates more accurate. We also needed to show progress of the project, just so they can see things coming together. We wanted to make them feel even just the slightest tingle of positivity when they thought about the project.

We decided that we could improve predictability by taking as much risk out of the project as possible. So we tackled all of the big challenging issues that were harder to estimate. Unknown external integrations, unused libraries, and cross-browser compatibility were in this category (but only if they were part of the simplest releasable version).

We also wanted to show progress by working on the small things that make a big difference — tweaks to visual appearance or removing little bugs from core functionality. To achieve this we always worked on a few quick-wins each day to balance out work on the big risky features.Big Improvements After Week 1

After one week of our new strategy the product manager was clearly happy. Probably because he could spend less time looking for a new job and more with his family and friends.

The PM was happy because we got the site looking presentable, we got the core functionality in reasonable shape, and we even got in a few quick wins — such as working hyperlinks. All of these gave the perception that we were making progress and we knew what we were doing.

The trend continued past week 1 as well.

Once we stopped committing project delivery suicide, once we had a strategy, and once we had focus, we were rewarded with a positive working relationship with the business.