Thursday, 4 June 2020

Estimates v Priorities

Why Do You NEED That Estimate?

I have previously written, and talked, about my discomfort whenever I, or a team I am involved in, is asked to provide estimates. My reasons for discomfort have previously been chiefly:
  • How will this estimate be used? In my experience, no matter how much you emphasise that this is the best guess you can come up with today and your guess will become steadily more accurate, the date you guessed right at the start ends up becoming a pseudo contract to be used in a blame storm later about why we (a) under delivered or (b) padded our estimate. Whilst I accept that the culture of the organisation will dictate how an estimate is used, my point is that it is important to understand whether your "estimate" might (or is likely to) evolve into a "commitment". If you think it is likely that this will happen, push back about being asked to estimate.
  • Why does the business thinks it needs an estimate in the first place? I have rarely seen a powerful argument as to why an accurate estimate is more valuable than breaking the backlog into its smallest valuable units and then doing them in order of (potentially constantly adjusting) priority.
I think there is a good additional point to be made here (thanks to my colleagues Chris Bimson and Matt Belcher for pointing this out when reading my draft). Before even considering the above questions it may well pay to ask "what is the question that the estimate might help to answer?" This is entirely consistent with one of my mantras which is "tell me the problem to which this is the proposed solution". In this case an estimate is, of course, part of some solution domain, so it follows that the person requesting it must have some higher level problem which they think an estimate will help to answer. It could be that there is a better answer to that question, whatever it is, which would make the request for an estimate go away. In a healthy culture I would at least expect the person requesting the estimate to engage in this conversation.

The Iron Triangle

In project management we often talk about the Iron Triangle. In the original version, it was assumed that quality was constant and any change in one of three constraints, time, cost and scope necessitates a change in the others. In other words you have a fixed "budget" across the related constraints. 

The version I usually refer to for software delivery says that given a fixed throughput (a constant team capacity) and an unvarying level of quality, you can either fix the scope or the required time for the work (assuming some kind of accurate capacity planning technique), but you cannot fix both. This is, of course, the problem that many deliveries encounter when they fix scope in advance and attempt to force a development team to "commit" to a delivery date. The Iron Triangle tells us that this can't be possible.

The CAP Theorem

An equally well known triangular constraint based theorem is the CAP theorem. This theorem states that it is impossible for a distributed data store to provide more than two of these three guarantees:
  • Consistency (every read receives the most recent write or an error)
  • Availability (every request receives a non-error response but not necessarily the most up to date data)
  • Partition Tolerance (the system continues to operate despite an arbitrary number of dropped or delayed messages between nodes)
Given that every modern database must guarantee partition tolerance (because today's cloud infrastructure cannot guarantee that partitions won't happen), the CAP theorem in modern databases can be reduced to an acceptance that any data store can guarantee consistency or availability but not both.

Unplanned Work

Unplanned work happens all the time to all sorts of people and teams and is the enemy of accurate forecasting. Some people in some roles have some reasonably well understood and repeatable methodology for forecasting a sensible level of unplanned work, in which case they may call it a "contingency" plan. Often, building projects will add a fixed percentage for unplanned work and they call it a contingency.

Of course, no amount of contingency or forecasting of unplanned work can substitute for the real solution to unplanned work which is to make your environment more predictable so that you do much less of it.

Why Might you Plan Ahead?

I prefer this question to "why do you need that estimate?" If I have to ask a business owner, "why do you need that estimate?" it means that somebody has asked me for an estimate. Often the reply comes back that "we need certainty over planning" or something similar. Leaving aside the obvious desire to shoot this argument down using 5 Whys ("why do you need certainty over planning?" is usually far enough for anybody to stumble over their own dogma), I will assume that there is a legitimate reason to want to have certainty over planning. 

A desire to have some kind of certainty over planning implies that they backlog represents a relatively small number of large things that are considered to return large chunks of value only when they are complete. Such items are often called "features" or "epics".

Why Might you Always do the Most Important Thing Next?

In some circumstances it is legitimate to ask, when you have capacity to take on more work, what is the most important thing for me to do now? If the most important thing to do can change, and every item on your list of work can be assumed to be independent of every other piece of work and deliver some kind of independent value, then it makes little sense to plan things beyond asking "what is the most important thing for me to do now?"

A Conjecture

Drawing inspiration from the Iron Triangle and the CAP theorem and noting the similarity between a system involving three constraints (one being fixed) I have constructed the following conjecture:

Assuming that the capacity of a delivery team responsible for delivering items in a single backlog remains unchanged, you can either manage your backlog to optimise for doing the most important thing, or you can optimise it for accuracy of prediction of delivery dates. Any given backlog being serviced by a single team of unvarying capacity cannot be optimised for both the most important thing and accuracy of prediction.

Optimising for the Most Important Thing

You must accept that unplanned work at any point could change the definition of the most important thing, potentially at very short notice. 

If you optimise for doing the most important thing at any given point you can only give any sensible delivery date for something that is in progress. Anything else, even if it is at the front of the queue, is at risk of being deprioritised and relegated down the queue. So the best you can ever say is, "this is currently at the front of the queue, if nothing changes priority it will be live in X days", if it is any further down the queue you will have to make a judgement based on your experience of the level of unplanned work that your team will expect and give a confidence interval of delivery dates to the asker of the question.

Optimising for Accuracy of Prediction

How can I optimise for accuracy of prediction? Scrum, in its purest (and arguably most annoying) form, seeks to optimise for predictive accuracy, at least within a "sprint". The idea is that you have a good idea of your team's throughput for a given period (often 2 weeks) called a "sprint" and you "commit" to delivering that amount of work in the current period. But herein lies the catch. After declaring your sprint "commitment", Scrum says you cannot change it. Thus, you must not allow changes in priority, and you cannot allow your team to carry out unplanned (and by its nature unpredictable) work. 

Of course, Scrum predicates some fixed interval of planning a sprint which seems to me to be linked to old fashioned notions of fixed releases at predictable intervals. I would suggest that if you are following Scrum, you should consider shortening your sprints continually until they are a single item in duration. At that point you have moved from Scrum to Kanban with no loss of predictability, provided that no unplanned work will be taken on.


You must make a choice between speed of delivery of the most important item in your backlog or predictability of longer term delivery dates.

As a corollary to the above, if your team is expected to undertake unplanned work, you can never accurately estimate delivery dates.

Wednesday, 4 March 2020

Running a Futurespective

What is a Futurespective?

Most people will nowadays understand, at least broadly, what a retrospective meeting (usually abbreviated to retro) is all about. There are many different flavours of retro, and having worked for ThoughtWorks for 5 years, I met a fair few, but essentially you are looking at a period of work and working out what you did well, what you could have done better and what you might be able to do in order to improve your work in the future. But what is a futurespective?

The Goal

The goal of a futurespecitive is to imagine a future state, one would hope a desirable one, in order to then discuss what things can be done to help us to get there. So instead of saying "what did we get wrong?" which got us to where we are (which is usually where retros end up) we are saying "in order to get to where we would want to be, would do we need to do"? So in this way a futurespective is more goal oriented than a retro can ever be.

Time Frame

It is also worth noting that the time frame under discussion is usually much bigger for a futurespective than for a retro. A retro will generally focus on a period of weeks (sometimes we even talk about a sprint retro, which narrows down to the previous sprint, usually two weeks) or possibly months. At ThoughtWorks we sometimes did stuff like "milestone retros" during long running engagements, or "project retros" if the project in question was a much shorter thing. In a futurespective the focus tends to be much more strategic and therefore the question is likely to be along the lines of "imaging a year from now.... what would we need to do...?"

Different Techniques

I've been involved in a few different types of futurespective. Depending on the audience and the motivation for the workshop, you may choose a different technique. I've been involved in discussions framed around "What would good like a year from now for ThoughtWorks at this company", I've also been involved in "Imagine a year from now, the program we are kicking off is a success, what does that look like?" Right now, I'm talking about the second type of question. I try not to think about the first question in isolation, preferring a well aligned partnership with our clients.

News Headline

Our client has engaged us to talk about Software Modernisation of a particular system that is causing problems. My concern all week has been that we need to make sure that we anchor any modernisation goals within a framework of business value that is understood, articulated and shared. All too often I've seen technology-led change fail because the business value is not well understood outside of the technology group.

The technique that I facilitated today was the "news headline" technique. I asked the group to imagine a year from now that the program has already been delivering on its aims. What might some newspaper (or industry organ) have on its front page to report the remarkable success of our client in the previous year? I asked them in groups, to collaborate to produce a front page with a headline, 3 or 4 bullet points that expand on the headline, perhaps including a quote from "an industry insider" or an executive of this company and maybe a picture. We left them at it for a timeboxed period of 20 minutes. It was important to ensure that the people in each group reflected a cross section of the competences within the room. For example, the two business stakeholders, the two architects and the two product owners were split.

The Discussion

At the end of the 20 minutes we had two nice front pages (on A3 paper) reporting on this ideal future state. I'd love to share the photos here but they all had the client name on them so I can't share the photos without breaking client confidentiality. The discussion we had enabled us to pull out 6 bullet points that describe the aspirational future state from a high level viewpoint that we used to inform the subsequent discussions around the work that we should do and how we should go about doing it.


Essentially, (and with some redaction to preserve confidentiality) we learned the following things from this exercise:
  • (our client wants to be) responsive to change and therefore improve its time to market
  • (our client wants to be able to) deal directly with its end users rather than through intermediaries
    • So they need to make it more easy to buy their stuff
    • The clients will save intermediary fees
    • (our client) will need to somehow provide directly the capability that the intermediary organisations have been offering to their customers
  • (our client wants to be able to) approach more partners and therefore needs to make its internal functions more scalable to achieve the capacity to make this possible
  • (our client wants to) compete with some massive players in its business space, this is currently not possible for several reasons which I can't go into here
  • (our client wants) to have a ubiquitous internal language to describe its product function so that it is possible to share understanding better both internally and externally

Next Steps

The outputs are useful to us on a few dimensions. Firstly this is helping us to frame what we may do in terms that mean something to the business. I need to be able to go to an executive stakeholder in a few weeks' time with a vision and a strategy that says "we should do this technology stuff in order to enable this business goal that has been identified".

Secondly, this exercise narrowed the scope of the subsequent discussion over what areas of improvement might be relevant. It helps us say "why would we want to improve that area of your estate when changing it won't contribute to these higher level goals?"

Thirdly, the workshop was fun, it aligned people in the room, and it gives us some cool photographs to use in our presentation back to the client next week when we talk about what we learnt, what we recommend and how we can help them to achieve it.

Monday, 24 February 2020

The Selfish Meme - A Conjecture

The Selfish Gene

The Selfish Gene was first published in 1976. Written by Richard Dawkins, probably now more famous, or at least more controversial, for his 2006 work, The God Delusion, its central theme is the notion that animals and plants are no more than "survival machines" manipulated by Genes to behave in a way that maximises the gene's chance to persist into subsequent generations. Clearly, individual animals and plants cannot be immortal, but genes can be. Certainly, genes persist far longer than individual survival machines.

Gene Alleles

Gene alleles are pairs of genes that compete with each other to persist into another generation. They drive behaviours that are somehow mutually exclusive to one another. The example given in The Selfish Gene is that of a gene that causes aggressive behaviour in animals that fight their own species for resources v a gene that causes passive behaviour in the confrontations in the same species.

Dawkins and Memes

In The Selfish Gene, Richard Dawkins coined a new word. This word is "Meme". His original definition is (I'm paraphrasing) "an idea, behaviour or style that spreads from person to person within a culture". Chapter 11 is entitled "Memes - the new replicators". In this chapter Dawkins describes how memes can be thought of as defining culture to an extent. In this sense, he is using culture to mean the culture of a society. Different cultures around the world and throughout human history have evolved a way to pass knowledge from one generation to the next such that the culture persists even though the individuals within the culture clearly do not.

Modern Memes

Most people probably now think of a meme as a thing, designed to be amusing in some way, that circulates, possibly "going viral", around the Internet. Some of my favourites would be Disaster Girl, XZibit - Yo Dawg (see one I made below) and the classic scene from Downfall. This last one is a sub-genre of meme where you put subtitles on some scene which are hopefully amusing in some way but are clearly not the originally intended dialog.

My XZibit - Yo Dawg Effort

Apparently XZibit is some kind of musician, a rapper I believe. He also was the presenter on a TV program, which I never watched, called "Pimp My Ride". It is from that program that I understand the Yo Dawg meme originates (I'm happy to stand corrected if I'm wrong, Know Your Meme doesn't talk about the origins of the meme, just the recursive structure). What I love about this meme is that "correct" use of it demands a recursive usage. I didn't immediately appreciate this and was told by a colleague that my use was incorrect and it had to include some kind of recursion. At the time, we were working on a Clojure implementation for our client. Imagine my joy then, when a few weeks later, I found out that the Clojure defMacro, which I had assumed was a keyword, was in fact itself a macro. I saw my opportunity to correctly use the Yo Dawg template and came up with something like this (my original is lost in the ether somewhere, so this is my best effort at a reproduction):

The Beginning of Infinity

David Deutsch's "The Beginning of Infinity" was first published in 2011. It is a study of epistemology. This isn't what I expected when I bought the book (I was expecting something about quantum physics or quantum computing and I never read the blurb), but it was still one of the best books I've ever read. Deutsch puts across an interesting conjecture. Running with the Dawkins idea that memes can define culture he argues that the rigid rules of the Spartan culture, passed from generation to generation as memes, eventually placed too many constraints on its ability to innovate. Thus, the Athenian culture, with its memes around learning and progress, was eventually able to finally conquer and all but destroy the Spartan culture. 

Transformation and Culture

So taking the two ideas together, Dawkins idea that memes can define culture, and Deutsch's idea that these memes can eventually be counter productive or damaging, led me to wonder if organisations in which I have consulted can have their culture classified or defined by their memes. If that is so, then perhaps by introducing competing memes (alleles) and somehow altering the value that the memes confer to its vectors, could I have a model for driving positive change?


I don't have a conclusion yet. I've been working on this idea and experimenting with clients that I've worked with. I don't yet have enough data points to draw strong conclusions but it has been fun and I've written a talk about the subject which I'll be presenting for the first time at Aginext in March this year. I was also asked to write an article for InfoQ on the subject. As soon as that goes live I will post a link to it from here.