:::: MENU ::::

The Complexity Retrospective

Many projects go awry due to excessive complexity; and its always worth evaluating whether your team is approaching things in the simplest way that can work; especially when the deadlines begin to loom.

I recently lead a retrospective with my team focusing on complexity across all the areas of our project, using the a handful of techniques from “Agile Retrospectives – making good teams great” (a must have for every agile team).

As suggested, we structured the hour long retrospective into 5 parts:

  1. Setting the stage
  2. Gather data
  3. Generate Insights
  4. Decide what to do
  5. Close / Action plan

The purpose of “Setting the stage” is to get everyone engaged, and thinking about the same theme. To do this I reminded people of the actions we had set ourselves from the last retrospective, and then asked each person to complete the sentence “If we were a military commando, and our mission was last retrospective’s actions, we would be _______”

Awarded medals
Ready for another mission
Court marshalled

I then told the team that in this retrospective we would be considering complexity, and whether we had too much, or just the right amount in each of the areas of our project.

To gather data, I drew a complexity radar, with each spoke a different area of complexity. I began by suggesting a couple of generic spoke names (Data model, Workflow), and then got the team to suggest the other areas. Using dot voting, everyone voted as to where they felt we ranked on each spoke, with closer to the centre being just right, and further away being overly complex. Joining the clustered dots produced the following radar map:

To generate insights we used the 5 whys excersize. I asked people to break into groups of 2, preferably cross discipline, and assigned each group 2 of the high ranking spokes. They were then tasked with asking each other “why is <spoke area> complex”, and “why is <answer>?” and so on, until 5 why’s had been asked. The answer to the 5th why was considered the root cause of the complexity, and recorded on a card. As the root causes cards came in, I grouped them, and when everyone was done, read the root cause groups out.

To decide what to do we constructed 2 more histograms, one considering the risk of the root cause, and the other difficulty to address the root cause. I then ask each person to vote which of the 2 root causes had had the highest impact & and which was the least difficult to address. This produced the following histograms.

In conclusion, we then combined the impact & difficulty histograms into the following map

My intention was that the final exercise would make it simple to choose the actions to take forward for the next sprint (basically chose the low hanging fruit – the easiest things to address which had the biggest risk reduction); but there wasn’t a clear winner shown on the graph.  Generating actions took a bit more discussion.

We found that this format was a fun and effective way to address the complexity problem.

Hopefully you’ll find running something similar with your own team helpful!

100% code coverage is only part of the QA story

Luke Francl of Tumblon has a nice summary with backing research showing how unit testing is only part of the QA story.

Its important to realise that developers by nature will only test the happy path; hence its likely that those diabolical edge cases will remain untested by a developer.

Another important factor is that most bugs come from missing features or requirements; and its impossible to unit test what isn’t there.

See more at http://railspikes.com/2008/7/11/testing-is-overrated; specifically Luke’s create Venn diagram showing how different types of testing (unit, user, code review etc) uncover different types of defects.

This isn’t to say that unit testing isn’t worthwhile; it just frees your testers up to concentrate on the unexpected, non-logical things that users are sure to try use your software for :)

Fixed price bidding vs the Cone of Uncertainty

Software estimation’s “Code of Uncertainty” suggests that before the requirements & user interface design is completed on a software project, time to complete the project can vary by up to 16x.

(Source: http://www.construx.com/Page.aspx?hid=1648)

So, before you have pinned down the exact requirements, the actual time to compete the project could take up to 16 times longer than your first estimate. Only after you have pinned down the user interface should you expect your estimates to be within 25% of the actual time to complete the project (an error % that can be managed). Note that this data assumes an experienced team, good estimators and NO additional requirements introduced late in the project (and good luck to you finding a project like that!)

Given this research what are the chances of a fixed price bid coming in on time or on budget?  Virtually zero.

And what is the first thing to slip under schedule pressure – quality.

So, our theory implies – if you go with a fixed price bid for any significant piece of work, before the user interface has been designed, then:

  1. The work delivered will be late (somewhere between 4 & 16 times the original estimate)
  2. Work delivered closer to the delivery date will be of low quality.

Is this true?

What have your experiences been?

What is the definition of Done?

 Scott Hanselman has a pretty interesting discussion with Scrum co-creator Ken Schwaber around the concept of when is a story Done.


Ken raising some interesting points, most notable that a well defined concept of Done, understood by all members of the project is a cornerstone of a good scrum process.  Without it, you can guarentee that you are building up technical debt; and your software won’t be in a releasable state once you have “Done” all the features, which kind of defeats the point of release planning!

So, what is your definition of done?

  • All acceptance cases / test scenarios pass?
  • Unit tests pass?
  • Performance tests pass?
  • Customers have used and approved the feature?

When to make technical stories?

During initial sprint planning, stories correspond to user features, and typically follow a

As a [user type]
I can [some action]
So that [some benefit]


Its important to keep the stories focused on features, rather than on tasks; because we need the users / product owner to be able to decide which stories to add or remove.  (A user cannot decide which tasks to add or remove, because the dependancies aren’t obvious).

However, during development of a particular story, you will often come across an area of the code that needs to be refactored.  A classic example is the case of removal of duplication; where as the design has evolved we discover additional areas of common functionality.

It can be tempting to attempt to work this refactoring into the current story, and if the refactoring is relatively small, this is a good idea.

However, in many cases the refactoring is too large to do without increasing the complexity of the story so much that it might not get finished in the current sprint.

This is the time to create a new “technical story”, which encompasses the refactoring (and perhaps any related work).

Its important that this block of work becomes a story to increase its visibility to the team, and to the product owner.  I’ve found that other team members always have useful input (hey, area Y of the team needs that too), and the product owner gets to prioritise the refactoring along with other stories.

This also makes plain to all the stakeholders why technical debt is increasing – if too many of these technical stories have been neglected in favour of new features.

The Simplest thing that could Possibly work

Jay has a good discussion concerning the design dilemma we often face considering the “simplest thing that could possible work”. Is it appropriate to implement a simple half baked solution that we know we will throw away as requirements become more defined? Or should we start out with a more complex pattern that will give us more flexibility?


Jay concludes that you can’t decide which pattern will give you the right flexibility until you have more requirements. So, rather than potentially implement the wrong complex solution, just treat the temporary solution as part of the learning process.

I agree. Like optimising, you need to know the precise requirements before you can choose the right pattern.

Throw away code isn’t wasted; rather its used like scrap paper in the learning process.

Story points = Complexity points / relative size

One of the ideas many people seem to struggle with in Agile projects is that of Story Points.

In an agile project, the time to implement a story (a feature), is deliberately estimated in a weird unit called story points, rather than in number of hours / days.

The most important thing to remember is that story points do NOT equal units of time.  Initially you will naturally find yourself trying to convert story points to days, or estimating in days or hours, and then trying to convert that to story points.

RESIST this temptation!  There is a method behind the madness.

  • Research has shown that people are better at estimating relative sizes (A – C is twice as far as A – B, Basket X is about 1/3 the weight of Basket Y) than coming up with absolute estimates (A to B is 15km, Basket X is 7.5kg)
  • Days are a very subjective unit of measure.  Depending on other commitments, your ideal days are very different from mine.
  • Estimating relative size is much quicker; and you need less information to get started (you don’t actually have to know how long anything will actually take, just the relative comparisons between different stories)

With a new project its impossible to know how quickly features will be produced.  There are just too many variables – learning of the domain & toolset, agreement within the team, stabilizing of work patterns.

What you do is complete a couple of iterations, and then measure how many story points you delivered on average.  This then becomes your velocity, which you can use to derive an estimated completion range based on the story points.

Note that with this technique your story points are still valid; as they are just measures of relative size/complexity.  The only time you really need to re-estimate story points is when you got the relative size of a story wrong – perhaps it turns out to be much easier to send emails than you thought, or much harder to draw graphs.

Draconian parking fines, by Camden Council

The quest to make our world a little greener is a worthy challenge, putting one in opposition with seemingly everyone in our modern society.

Case in point – I attended the Geek Kyoto conference in Camden a few weeks back, and rather than drive home on the Friday and then back into London on the Saterday (a round trip of 80 miles), I elected to spend the night in a London hotel. Finding parking overnight was, shall we say, trying, and wildly expensive.

Eventually I found a parking, for which you had to pay between 08:30 & 13:30, and paid the required £10 (!) to park for the first 2 hours. I carefully place the parking reciept on my dashboard, confident of being a law abiding citizen (Observe the clear sign across the road)

When I returned to move the car in 2 hours (maximum parking 2 hours), I was shocked to see that I had been ticketed a whopping £120 for my citizenly efforts.  The bay I was in is sign posted as a residents only bay.  How ASBOish of me; how could I have missed the residents only sign – its clearly displayed behind a tree!  (Look, just above the silver car parked behind me)

Egad – I managed to pay £10 for the pivilege of being fined £120.  So much for attempting to reduce my CO2 footprint by driving less!

I’m appealing; lets see what the Camden Council have to say…