Steadily delivering quality

This week it was revealed that car hire company Hertz has sued Accenture for US$32 million for failing to deliver either a functional website or mobile app during a 16-month digital transformation project.

While there is a lot that could (and will) be said about this. It’s quite remarkable that even now digital and software development projects are still being carried out using traditional ‘waterfall’ project management approaches with all the design and planning done up-front rather than using an agile, just-in-time approach.

Fixed or variable?

In every project there are four key elements:

  • Features (requirements)
  • Time
  • Resources (cost)
  • Quality

Whether these elements are regarded as fixed or variable is what distinguishes one project management methodology from another.


In so-called ‘traditional’ or ‘waterfall’ projects features are fixed.

Triangle diagram showing fixed features

Requirements are gathered, plans are drawn up and the project does not finish until the last feature has been delivered.

If the project goes off-track, more money and resources are thrown at the project and the deadline slips further and further away.

As projects get later, often quality also suffers, as this cartoon demonstrates:

Drawing of a horse showing one end in high quality and the other as though drawn in a hurry by a child

This is what happened to the Hertz/Accenture project. Started in August 2016, a new website and mobile app were meant to be launched in December 2017. The project was abandoned in May 2018. Nothing was usable; nothing was launched.


In contrast, an agile approach to project management fixes time, resources (cost) and quality. It is the features that are variable.

Agile diagram showing variable features

A minimum viable product (MVP) will be delivered quickly, tested with real users and iterated on to bring more features to market incrementally.

Time is fixed using fixed-length sprints. Resources are fixed using established teams who stay together for months. Quality is fixed by establishing good testing disciplines, agreeing on common practices, and establishing a solid definition of done.

There is an old military adage that even the best plan goes awry after the first contact with the enemy. So it is with projects: there ought to be an expectation that features will evolve and change as you learn more about the product during development, user testing and once those new features have been delivered to end users.

As our own agile journey continues, we would benefit from bearing in mind the eight principles of the AgilePM framework:

  1. Focus on business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise quality
  5. Build incrementally from firm foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate control

What next?

The Vision Tasks team has recently delivered v1.4 to SIT and ELS. This is a major milestone for the project and a huge confidence boost for the team. (Well done, Tasks team!) This is a fabulous foundation on which to build, incrementally.

Over the next few months, I’d like to see one of the focuses for the team to be working towards being able to deliver releasable features at the end of each sprint (even if they don’t immediately get put into production).

There is some work to be done first to get us to that point but that’s the goal: steadily delivering quality.

Originally published on my work internal blog.

Shu ha ri—three stages towards agile maturity

“Scrum has its roots in Japanese thought and practice”, Jeff Sutherland, the co-creator of Scrum, tells us in his book Scrum: the art of doing twice the work in half the time (Random House, 2014), p.38.

One of the ideas that Scrum has drawn on is the Japanese martial art concept of shu ha ri (or shuhari) which outlines three stages of learning towards mastery.

Over the last few years, I have found this a really useful model to bear in mind when working with teams as they embrace and grow towards agility.

Continue reading Shu ha ri—three stages towards agile maturity

The primary purpose of a development team is…

Before you read further, take a moment and answer the following question for yourself: what is the primary purpose of a development team?

Don’t worry, I’ll wait…

Okay, what was your answer? Is it to create working software? (Well, yes.) Is it to complete everything on the sprint backlog (Hmmm… kinda.) Is it Henry, the mild-mannered janitor? (Could b… No!)

Above all, the primary job of an agile development team is to build quality into the product.

That focus on quality is important because it informs us and shapes us in everything we do as a team, from planning through to delivery.

When I introduced agile to one team with whom I worked, it took me a long time to help them get beyond their misconception that agile meant quickly hack things together and shove it out the door. Release early and release often—yes; dirty hacks—no! Done well, agile should be more disciplined than other traditional methodologies and focus on quality.

The first principle of the agile manifesto reads, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The agile manifesto values “working software over comprehensive documentation”. Valuable software is working; working software relies on quality.

The fourth principle of DSDM/AgilePM is “never compromise quality”.

What small step could you take now to improve the quality of your work?

An overview of my planning and productivity system in 2019

Google Calendar, Microsoft OneNote and Todoist

My personal organisation system has evolved over the years in an iterative and rather agile approach.

This post outlines the major building blocks of my current system.

Continue reading An overview of my planning and productivity system in 2019

What are story points?

Photo by Danka & Peter on Unsplash

In his book Agile Estimating and Planning (Prentice Hall, 2006), Mike Cohn tells us that “story points are a unit of measure for estimating the overall size of a user story, feature, or other piece of work.” (p. 36)

Over the years, I have found that one of the trickiest agile concepts for people to understand is story points.

When it comes to estimating how long it will take to complete a chunk of work, agile adopts a very different approach to traditional project management which uses tools like Gantt charts where tasks are estimated in time (e.g. hours, days, weeks).

Humans are notoriously bad at estimating how long something will take. In 1979, Daniel Kahneman (author of the excellent Thinking Fast and Slow) and Amos Tversky proposed a theory they called ‘planning fallacy’. In short, they noted that when you estimate your own tasks you tend towards underestimating (displaying an optimism bias), and when you estimate the tasks of others you tend towards overestimating (displaying a pessimism bias).

Agile tries to get around this by estimating effort using story points rather than time. The reason is that many people can agree on relative effort without agreeing on absolutely time. Let me give an example.

Mountain of an example

Imagine you are interested in hill walking. You and a friend decide that you want to use story points to classify different hills and mountains according to the effort required to climb them.

But it’s not just about the physical effort required to walk to the top. You also want to take into account the complexity of the ascent (how easy is it to reach the starting point, any difficult terrain, will you need any specialist equipment, etc.) and any risks and uncertainty involved (changing weather, wind conditions, or sheer drops, for example).

The first hill you decide to climb the Eildon hills (1,385 ft) near Melrose in the Scottish Borders. It’s a strenuous but simple walk, you don’t need any specialist equipment and you could do it easily in a couple of hours, even on a rainy day. Weighing up the effort involved to climb it, the complexity of the climb and the risk and uncertainty that is presented, you decide to classify that hill as 1 story point.

The following week, you fancy a bit more of a challenge and so you decide to ‘bag’ your first Munro, a Scottish mountain over 3,000 ft. You choose to tackle The Cairnwell at Glenshee, at 3,061 ft. You’ve been told that it’s one of the easier Munros to conquer so the complexity isn’t much more than the Eildons. The risk and uncertainty also remain largely unchanged. The biggest difference is effort. All in all, it’s about twice the size of the Eildons so combining physical effort, complexity and risk you classify it as 2 story points.

Next you decide to tackle Scotland’s largest munro, and the tallest mountain in Great Britain. Ben Nevis (or Beinn Nibheis for the Gaelic speakers among us) stands at 4,411 feet above sea level. It’s around 1,400 feet taller than The Cairnwell, so perhaps you consider classifying this as a 3. But then you start to do more research. While Ben Path is the simplest route, the presence of running water, uneven rocks and loose scree makes it a more complex and risky ascent. You take into account the uncertainty of the weather; there is a risk of fog and snow. Then you read that there were 108 mountain rescue call-outs in 2018. As you are using the Fibonacci sequence for your classifications you settle on a 5 story points for Ben Nevis.

Story points are relative

One of the benefits of using story points to estimate the size of tasks is that it allows you to estimate them relative to one another.

What matters most is the ratio, not the numbers. We could have chosen to classify our hills as a 4, 8 and 20, or a 100, 200 and 500.

You may not be in a position to immediately know exactly how long (in minutes or hours) something will take to do, but it should always be easier to estimate whether it would take more or less effort than a similar task you have already completed.

As we’ve seen in the hillwalking example above, the total effort is a function of effort plus complexity, risk and uncertainty. Whether you are a seasoned mountain climber or a complete amateur, you could both agree that the munro would take twice as long to climb as the Eildon hill. What would be different for each party is the time taken to climb each.

For the keen amateur, it may take him six hours to climb and descend Ben Nevis; while the seasoned pro may do the same route in two hours. Same number of story points, different durations.

The same is true for software development teams. Two teams might both estimate a particular user story to be three story points but if team A has worked on this kind of task before and is comprised of experienced developers who have worked together for a year or more, they might complete it in a a few hours. Whereas the newly-formed team B, which has a few graduates and junior developers, may take a day and a half to push that story through to done.

Don’t compare teams

What is important, though, is to not compare at face-value the estimates of two teams.

“A nice feature of story points is that each team defines them as they see fit.” writes Mike Cohn in User Stories Applied (Addison-Wesley, 2004), p.87.

So, one team’s 3 may be another’s 8. The important thing is that are consistent. It doesn’t matter if you measure your office furniture using centimeters, inches or square Post-it notes, so long as you use that scale for all your measurements.


That is the beauty of using story points. Stories are estimated relative to one another, taking into account effort, complexity, risk and uncertainty but how long they take to finish will vary for different teams.

Ultimately, story points are about time but they are not about hours. It’s a subtle distinction but a very useful one.

Originally published on the Vision internal blog.