What Theresa May’s speech can teach Agile folk about deadlines

In June of this year I saw Dr Andy Carmichael talk about Irrefutable Demand at Agile in the City (London). The main take-away from that talk was that “irrefutable demand” often isn’t. Demands from stakeholders that seem absolutely concrete with absolutely no wriggle-room are often in fact negotiable in some way – particularly with respect to deadlines and scope.

Theresa May

British Prime Minister, Theresa May

This thinking was echoed within talks I’ve heard Allan Kelly give recently (including at Agile Cambridge), as well as a workshop by Özlem Yüce that I attended today. Allan said that deadlines are elastic; they can be stretched depending upon other things you might value, and the impact of that “stretching”. Özlem’s Cost of Delay workshop showed how to quantify this impact. Is a deadline set internally or externally? What is the impact on value if it is delivered a month early? What is the impact on value if delivered a month late? Even seemingly irrefutable regulatory deadlines can be analysed according to the impact of not meeting the deadline, the risk involved, etc – although the irrefutability is obviously rather lower than a deadline chosen by a stakeholder to spur a team along.

On my way home, I heard the news about The Prime Minister’s ill-fated speech, delivered on the final day of the Conservative Party Conference.  The speech was notable for a few reasons: a “prankster” who breached security, some faults with the signage on-stage and a terrible cough and sore throat that made the speech particularly excruciating to watch.

It was this last point – the cough – that puzzled me the most. News reports claim that Theresa May had been suffering from a cold all week. So why did she give the speech under these circumstances?

I began to wonder if the demand – in this case, the demand to make a speech at the conference – was an irrefutable deadline. Something timetabled in that she could not avoid. Or was the demand, like most demand described by Andy, Allan and Özlem, in some way refutable.

Could Theresa May have changed the timing of her speech? Probably not. It was a closing speech at the conference, sot couldn’t have been pushed back any later. Could it have been moved earlier? That might’ve been worse if she was recovering from illness.

But then, did the PM need to give a speech at all? She’s under fire from her own party, but in retrospect I’m fairly certain that “no speech” would have been better than the “disaster speech”. In the same way that a good Product Owner or Software Engineer should be upfront about the challenges they think they might encounter when undertaking a piece of work, perhaps she should have simply explained that she was unwell.

There were alternative options. She could have released details of the new policies included in her speech, perhaps announced by an up-and-coming backbench MP who would pose little threat to her position as leader. She could have delayed the speech, holding a separate event later in the week at another location. But no. She delivered the speech, and it was seen as a calamity.

I assume that she thought abandoning the speech would have made people angry or upset. I also suppose that she hadn’t really considered moving it, because the expectations and timing of the closing conference speech are fairly irrefutable.

It would be far easier to criticise if we hadn’t all, at some point or another, agreed to a demand out of fear. Far easier to criticise if we hadn’t ever agreed because of our ill-judged desire to keep someone happy. Far easier to criticise if we hadn’t agreed to a deadline due to an almost certainly incorrect assumption that the demand was completely fixed and non-negotiable. Far easier to criticise if we hadn’t all, at some point in our lives, coughed our way through something instead of trying to find a better way.

Image: Creative Commons. DOD photo by U.S. Air Force Staff Sgt. Jette Carr.

Reading list: Limiting WIP in the Kitchen Sink

Thanks to those of you who attended my SwanseaCon or Agile Cambridge talks in September 2017. As promised, here are some resources that will help you to explore this topic in more depth.

WIP and Flow

Don Reinertsen has written an excellent book, The Principles of Product Development Flow, which explores the topic in great technical detail. His work takes a scientific approach to the subject – something evident in this talk that he gave at Lean Kanban Central Europe in 2012. It’s well worth watching! Both the book and the talk take things well beyond Little’s Law.

There’s two other books I can’t recommend enough – both written in a “novel” format, which is – well, umm, “novel”. The first is The Phoenix Project, a story about applying Kanban to IT Operations. The second is The Goal, which is an older book about a fictional factory applying Lean principles, introducing an idea called The Theory of Constraints.

Resources mentioned during the talk

But remember – if you’re just looking for a place to start and don’t have lots of time to read around this subject then it’s fine to just start measuring throughput and cycle time, applying WIP limits to your process and seeing how you can tweak these to optimise your process for better flow.

If you’d like to find out more about how we do things at Ocado Technology, drop me a line or ping me on twitter. Alternatively, come and see for yourself! We’re hiring!

Bumps ahead: what broken roads can teach us about our backlogs

Where I live the roads are truly shocking. I live in the countryside, in an area where the land used to be under the sea. The ground is very soft and the soil is very rich. This is great for growing most of the vegetables that make it onto our dinner plates, but not so great for holding up a road.

"Damaged road surface" sign

Is it acceptable to put up this sign instead of fixing the problem?

This means that the local authorities have quite a task on their hands to try and keep on top of highway maintenance. In some places they seem to have given up. Then the council came up with a plan. They installed a sign warning motorists of a “Damaged Road Surface”. There. It’s our problem now. Every time I saw one of these signs I’d scoff and shout “THAT’S NOT A FIX!” I’d wonder what the comparable action would be in terms of Software Engineering. “Warning: this code has unpredictable output!”

The whole thing is totally ridiculous. Or so I thought, until I started thinking about our backlog.

Prior to a backlog refinement session we held last week, our backlog had about 140 items on it. By the end of the meeting the backlog was still over one hundred items. Since our throughput as a team is no more than ten stories per month, this was setting ourselves up for about a year of work. More, since some of those stories still seemed quite “epic”.

I’ve long said that keeping more than about six months’ worth of work isn’t helpful. I think that if you add something to your backlog that you don’t intend to do within six months then you are effectively lying to the customer/stakeholder if you don’t tell them “no, we won’t have time”. Once you’ve added it to the backlog the customer expects that you’ll get around to it. If you’d simply said no in the first place then you manage their expectations and, in the best case, they might find an alternative way to achieve the same outcome.

I can’t help but think that this might have happened with the roads where I live. My guess is that the department at the council responsible for resurfacing the roads decided that they didn’t have the time, money or resources to complete the work “soon”. By being honest about this, they have given a signal for someone in the local authority to decide upon an alternative option in the meantime: warn drivers so that they can slow down. Had there been an expectation that the road would be fixed “soon” then this extra sign would not have been put into place.

An unhelpful “Damaged Road Surface” sign

What does this sign tell the stakeholder?

Obviously, saying “no” to your customer or stakeholder very often can lead to undesirable behaviour.

In our case, it seems as though we may have trained our stakeholders not to ask for new things to be done as they already know we are at capacity. We recently encountered a situation where someone had tried to implement an alternative approach to solving a problem, but they hadn’t spoken to us first. It turned out – a long way down the line – that they could not do what they wanted to do. We could have told them this up-front, without the wasted effort they had invested in the project so far.

Another road sign nearby is supposed to convey the same message. It simply shows an exclamation mark (!) in a red triangle. There is no text providing more context. It’s a sign that tells the motorist something, but not enough for it to be useful. In fact, it’s terrible.

I feel a bit like we encountered a problem akin to the second sign. The stakeholder has tried to work around the issue of our busy schedule, only to find themselves without a product that achieves the desired effect.

We should “Say No” more often, but when we do we have to make sure that we continue to hear ideas from our stakeholders and give them advice on the best approach.

Programming in the fast lane: coding at 230mph

In the United Kingdom new drivers are taught an important procedure for handling tricky situations like turning at junctions or changing lanes.

Always remember to check your mirrors - especially when travelling quickly!

These “learner drivers” are instructed to follow the initialism “MSPSL”. It stands for: “Mirrors, Signal, Position, Speed, Look”. To expand it a bit further, this involves: checking your mirrors; signalling your intent; adopting the appropriate road position; slowing down to an appropriate speed; and keep looking and observing everything around you.

By the time a driver passes their driving test they will probably have forgotten “MSPSL” and will have instead learned to perform the sequence of actions as if it were just natural. Travelling at a steady 30mph down a residential street, drivers will remember to check their mirrors before turning at a junction. It would be dangerous not to.

How does the danger of not checking your mirrors at 30mph compare with other speeds we drive at? Would you consider it more or less dangerous to change lanes at 70mph on a busy motorway without checking your mirrors?

In 2006, Valtteri Bottas broke the Formula 1 speed record during the Mexican Grand Prix. His car reached speeds in excess of 230mph (370kmh). Racing along at these speeds, with the heightened threat of other cars trying to whizz by, it would be utterly unthinkable for Bottas not to be checking all around him… and doing so with even more care than that person who is casually driving through town at just 30mph.

With all of this in mind, we should ask ourselves why – as Software Developers – we often feel an inclination to abandon our usual operating procedures when coding like a Formula 1 driver.

All too often we see teams who are up against a tight deadline or fixing a production issue dropping their usual standards of Agile process, Test-Driven Development (TDD), Pair Programming and Clean Coding practices. We spend a lot of time honing these skills when business is usual, but the moments where we find ourselves in difficult or high-pressured situations are the ones where we stick to them the least. The sad irony is, that’s the time when we need them the most.

Lunchbox batch sizes: what is a batch size, anyway?

Every weekday I make two identical packed-lunches for my two youngest children. Each one contains a sandwich, a cereal bar of some sort, some cheese, a yoghurt, a banana, a satsuma (or perhaps some grapes) and sometimes even a bag of crisps. The lunches are the same, but their lunchboxes are different shapes and sizes.


Photo: flickr/joeymanley (creative commons)

I tend to make the sandwiches first. Then I wrap them. Then I pack them into the lunchboxes, before packing everything around them. First the bananas, then the satsumas, then the smaller things… two-at-a-time until I’m all done.

While doing this the other day I cast my mind back to a passage in Eric Ries’ “Lean Startup“, in which he argues that small batch sizes are more efficient. Ries gives the example of putting many letters into many envelopes. People tend to do them in large batches – first the folding, then the envelope stuffing, then sticking down the envelopes, addressing them and finally affixing the postage stamp. He claimed that experiments have shown it is much faster, although counter-intuitive, to do the entire process one envelope at a time. One argument he gave was that it allowed you to make changes early on if you discover that – for example – the letters don’t fit into the envelopes.

So what does this mean for my kids’ lunchboxes? What is a “batch”? Following Ries’ example I guess I should make each lunchbox in its entirety as one logical component. But then, I’ve been involved in many debates about what really constitutes a “batch”. Rather than each entire lunch being a “batch”, could the individual “item types” I put into the lunchbox actually be the “batches”. Why does it matter? I know how to make the lunches, and everything tends to go quite well.

Then it dawned upon me. It really doesn’t matter. Not in this case, anyway. In Ries’ example he refers to the letters not fitting into the envelopes, and making changes. There. That’s it! It’s about feedback! I’ve made the same lunches loads of times. I think that now the greater benefit comes from not context-switching away from making the sandwiches to do something else. Before, when I was getting used to the lunchboxes being different sizes and shapes, it was probably more of an issue.

It doesn’t matter what you consider to be a “batch”, as long as the thing you’re working on allows you to receive useful feedback regularly. Don’t focus simply upon reducing any old “batch size” you come across in your work. Instead, focus upon identifying where the feedback is delivered in your work. That’s the batches you should care about. Only then can you modify your process to ensure that you minimise the feedback cycle in the most effective way.

Convergent evolution of agile practices

Biologists talk of a concept called “convergent evolution”. It’s the idea that two different species, completely unrelated to one another, can develop similar characteristics without ever interbreeding. When these characteristics are developed independently through the process of Natural Selection it proves that there is a clear advantage to the species involved to possess such a characteristic.

A bird

A bird.

A bat

Not a bird.

Birds fly. So do many other animals, but they didn’t discuss it beforehand. Through trial and error, both birds and bats developed flight as a way to avoid predators and improve their own hunting skills.

I have noticed the same within agile teams.

A while back I led a project to establish some team “KPIs”. Without any prior research into the matter our team came up with four key areas we wanted to measure. These were “Team Health”, “Technical Quality”, “Business Value” and “Stakeholder Engagement/Perception”.

Not long after this I was listening to a podcast (probably This Agile Life – highly recommended) and one of the hosts was talking about setting up a new team. Almost in passing he said that they’d set up four basic metrics: a measure of code quality, some team happiness score, throughput and a net promoter score for the team from their clients. This sounded familiar! I’ve since heard at least one other team talking about measuring very similar things… and yet we came up with these ideas independently of one another.

A while back my team – working from a Kanban board – found that we had an unrepresented stage in our work between finishing development and actually completing the story. This stage included things like integration with other teams, deployments to production and even gathering feedback from the customer. This led us to either prematurely (and wrongly) call a story “Done” or become blocked from taking on other work. On our board we added a column between the end of our process and “Done”. We would put stories here while we waited to make sure that they were complete. What would we call this column? After some discussion, we decided to call it “VALIDATION”.

Last night I attended a meetup with Agile Northants. I overheard the speaker, Mike Burrows, talking to another attendee about a similar problem to ours. Mike said, “I’ve seen a lot of teams solve this by adding another column at the end of their board called ‘validation'”. Needless to say, Mike (nor any of those other teams) had ever seen our board. Again, we came up with the same idea independently. I can think of many other situations where this is the case.

What this seems to suggest is that there is perhaps a “best practice” that we should follow, and that working all of this stuff out team-by-team is a huge waste of time.

But then, maybe it’s the process of working it out for ourselves that’s important. Sure – flying might be a hugely advantageous characteristic, but not all animals fly. If the elephants had simply read the book “The Dummies Guide to Being a Great Animal” then they might have decided to have wings, but that wouldn’t work out so well for them. I guess we should identify the problem we’re having and develop the most appropriate solution for ourselves, even if that looks very similar to what everyone else is doing.

Problems or solutions: The doctor will see you now

I’ve been thinking about the difference between software teams who build things they are told to deliver by the rest of the business and teams who ask their stakeholders for problems and provide solutions.

Doctor consultation

Photo: ILO in Asia and the Pacific on Flickr (Creative Commons)

Imagine you’ve gone to see your doctor. You’ve had your name called, knocked on the door of her office and been invited in. She waves her hand to indicate that you should take a seat and asks how she can help. “I’d like you to prescribe some antibiotics,” you reply. The doctor is unsure. She frowns, before asking you why you think you need antibiotics. You explain the apparent medical catastrophe you’re currently facing. “I see,” says the doctor guardedly, “and why do you think you need antibiotics?” You describe the research you’d carried out on your symptoms, found some potential solutions and someone in a popular online forum had suggested antibiotics as the cure.

The doctor goes on to explain that antibiotics won’t solve your problem. In fact, they should generally be avoided if at all possible. She suggests a range of possible solutions. Some will be more effective, but will have side-effects. Others will have fewer side-effects, but will take longer to make you better. You immediately rule out one of the proposed treatments because you’ve tried it before and it made you feel more unwell. You make a decision and the doctor warns you that you won’t notice any effect for a while. In the meantime, since you are in some discomfort, she advises you to take some interim medication to improve the situation a little bit. One will provide a lot of relief but may delay the impact of the full treatment. The other will only help a bit, but it won’t delay your recovery at all. You make a decision and go on your way.

How would you have felt had the doctor simply prescribed the antibiotics without question? Would this have made you better? Might this have had a harmful effect on everyone else through over-use of antibiotics? What if the different options hadn’t been presented along with the risks involved?

Software Engineers should act as professionals, no less than a doctor should. We shouldn’t have a “patient” come to us with a solution and blindly implement it for them. The most important question in the doctor/patient relationship described above is the very first one; “How can I help you?”. As Engineers we’re there to help our stakeholders, not be entirely subservient to their requests. We should encourage these stakeholders to come to us with problems rather than solutions. When they approach us with a “solution”, it’s part of our job to question, to investigate and to provide suggestions, provide a professional judgement of the risks entailed and suggest some short-term remedies that can help make people’s lives better.

How MVP housed my rabbit

I recently housed my pet rabbit after remembering about MVP. Yes, “Minimum Viable Product” concepts made our DIY rabbit house project reach completion faster than expected. But how?

MVP rabbit house

Our rabbit house – complete with a door on the run, but still without painted windows.

We were given a pet rabbit. Its owners had bought a cat and decided it would be unfair on the bunny to make him stay. We had an empty hutch lying around from the days when we had a rabbit previously. It was a big hutch – the biggest we could afford and larger than those sold by most pet shops – and there was a run permanently attached.

Although the hutch was large and far exceeded legal requirements, we realised that we still fell far short of the guidelines issued by animal welfare charities. Our Leporidae needed a bigger house. So we set about building one.

This was the plan: replace the hutch with a children’s “wendy house” and build a walk-in, permanently attached run. We bought the shed online and assembled it. We bought the metal meshed wire, the wood, the screws, a staple gun, etc, and set about to work on the run. We built panels for the front, back and two sides and attached the wire mesh. We would then assemble these to make the run.

At this point we needed to build the door for the run. I had a go, but being a Software Engineer rather than a master carpenter it turned out that the whole thing was slightly off-square and I simply couldn’t get the door to fit. What’s more, the door I did manage to build fell to pieces. It was a disaster.

The half-built run sat in the garden for over a month. Nothing happened. When I eventually returned to the project I still couldn’t get the door to work. We realised that my father-in-law would be able to help us with this, but he’d visited on a number of occasions and hadn’t got around to looking at it.

As I was about to give up my wife asked me “Do we need the door?”. “Pardon?”. “Do we need the door?”. We thought about it for a while. We didn’t expect the run to get too messy as the rabbit would have plenty of space, so it wouldn’t need cleaning as regularly as the indoor section. The indoor section had its own door. We could feed the rabbit indoors and we can access the water bottle from the outside of the run. No… we probably didn’t need the door! What would we do instead? My wife suggested simply using cable ties to attach the wire mesh where the door would eventually go.

I then remembered that we hadn’t painted the wendy house, and that was a super fiddly bit because painting around the windows takes a long time. “Is that a problem?”, asked my wife. It was. Once we’d attached the run there would be parts we couldn’t access. But then, the windows weren’t one of them! We could paint the walls but not the windows or door! I got to work as soon as I could.

By the end of the day we had a rabbit house. The outside of the wendy house was painted, bar the windows and door. The run wasn’t accessible, but it didn’t need to be just yet. It didn’t matter. Our rabbit could move straight into her new, larger house! Had we tried to ensure that the run was absolutely perfect then we may have struggled along with this project for many more weeks or months. By establishing the MVP for the rabbit house we were able to get something in place much sooner.

You’re probably wondering one more thing: What happened to the temporary door? The next time my father-in-law visited the first job he did was make a door. After seeing that the run was in-use he realised how useful the door would be and made sure that it was completed. I doubt this wouldn’t have happened without using MVP approaches to get the run finished.

It seems that iterative improvement is sped-up by real-world feedback. Either way, we had a very happy bunny.

Safe spaces outside of retrospectives

A former colleague (Guy) recently published a blog post encouraging teams to carry out regular “retrospectives”. Even though our team already carries out weekly retrospectives, it got me thinking about what our retrospectives deliver.

My team uses a technique called "Things to discuss" in order to resolve problems quickly

My team uses a technique called “Things to discuss” in order to resolve problems quickly

In his blog post, Guy lists four potential benefits of a retrospective. I broadly agree with him. He views the benefits to the team as:

  1. It allows them to talk about their feelings in a safe space (Social Connection/Relatedness)
  2. It allows them to make small changes to their processes, to try to make their delivery better (Mastery/Competence)
  3. It allows them to feel in control (Autonomy)
  4. It allows them to step back and see what they’ve achieved (Purpose/Competence)

I feel as though our retrospectives achieve all of the above, but I largely view them as “training wheels” for integrating these aspects into our day-to-day work.

I think that a “safe space” means no fear of conflict (or the consequences of it) and a discussion in which people don’t hide their views but accept and consider those of others. If your retrospectives create a “safe space” for debate, constructive criticism and discussion then this facilitates making process changes.

My view is that the ultimate goal is to make try to make every interaction within the team so “safe” that these issues can be brought up at the source. A team mate telling you to “your conversation is distracting me from my work” is great immediate feedback. In an “unsafe” space this might make a team member feel chastised, but if there is a great deal of “trust” within the team then it becomes valuable feedback which you can immediately act upon, or disagree with (perhaps that conversation was extremely important and urgent).

Our team used to have a meeting called “3 things to discuss”. It was a team norming exercise to try and resolve issues and make team decisions about things like collaboration techniques, code reviews, etc. If someone wanted to talk about something they would write it on a reserved space on the board and once it hit three we would book in a meeting. After a while we thought that this meeting was cumbersome so we made it “Things to discuss” and address them at the end of our stand ups. We have two stand ups a day.

This means that the maximum amount of time it takes for the team to discuss an issue and potentially put in place an experiment to resolve it is four hours. The benefit of the space on our team board is that the process makes the things written there “safe”. But what if we could resolve these issues immediately, even outside of this process

Our team currently has some concerns about how our stand-ups operate. They can take a long time, which is a problem when they are so frequent. Although we’re reasonably good at giving detail of what we’re working on, we can be much better. We could make our non-story work more visible and we could provide better justification for time spent away from stories. Some of these issues were raised as part of “Things to discuss”, while others came up in a retrospective.

I wonder whether or not we need to wait until the next retrospective to talk as a team about whether or not we feel that these issues are being resolved. The retrospective is a “safe” space, but if we agree that other discussions should be seen as “safe” and have trust within the team then we should feel able to reflect on these problems as they arise.

It’s all about trust (and a game!)

In my last blog post I mentioned that I’m a Town Crier. Why? Well, apart from the fact that it was a nice analogy that explained my thoughts behind the word “ceremonial”, I thought it was also a good opportunity to improve trust. Let me explain…

Chickens (you'll see why) | Matt Davis - Flickr - Creative Commons

Chickens (you’ll see why) | Matt Davis – Flickr – Creative Commons

The “absence of trust” is the first of the five dysfunctions listed in Patrick Lencioni’s “Five dysfunctions of a team“. When talking about trust, Lencioni is clear that he’s not talking about standing around at off-site conferences falling backwards into the arms of a nervous colleague. It’s about being vulnerable.

If team members make themselves vulnerable to each other then this fosters a culture of trust. You know that your fellow team members will be there for you, that they’ll do the things that they’ve promised to do and that they will act according to what the team considers to be acceptable behaviour.

Once you’ve established this level of trust, you’re more open to taking risks. It helps you to overcome the second dysfunction, a “fear of conflict”, because you can trust that other team members won’t turn conflict situations against you. Trust makes it okay to disagree.

I’m lucky to be in a team that has great trust. When undertaking exercises where there is an option to remain anonymous (such as providing feedback), team members are choosing to identify themselves to one another increasingly often. Our retrospectives are very relaxed and extremely productive. I sometimes find it hard to understand how other teams don’t share this same level of openness with one another.

A trust game

In “Five dysfunctions of a team”, Lencioni suggests that a good way of overcoming a lack of trust is for team members to reveal something inconsequential from their personal lives to their colleagues.

I’ve decided that most of the exercises that try to fit this theme are extremely boring. People are often asked to reveal certain information to other members of the team, such as “how many siblings do you have?”. I think that this is a step in the right direction, but if you want people to be on-board with an exercise like this one then you need to make it fun. It needs to be a game. It needs to be memorable.

Thinking about this problem, I recalled a game we played at work some time ago. It wasn’t in the context of improving trust, but it was perfect.

Choose a facilitator. Everyone else splits into two teams of a roughly equal size. Each person writes on an index card some fact about themselves. It should ideally be interesting or amusing but at the very least should be something that other people are unlikely to already know. The two teams gather up their index cards and hand them to the facilitator, who keeps them in two separate piles.

The facilitator now selects cards, alternating between each teams’ pile. The facilitator reads aloud the words on the card and it’s the job of the opposing team to try and guess who wrote that card. Teams win a point if they get it right, or lose a point if they get it wrong. At the end of the game the team with the most points wins!

Aside from trying to win, there’s another element of fun in this game. The things people write on the cards are truly memorable. I probably last played this at my company over 18 months ago, but we can still remember what most of the cards said:

  • One person keeps chickens
  • Someone else nearly set a house on fire when younger
  • Our head of department didn’t eat a banana until the age of 23

Teams will be more engaged in this game than they will be in discussing trivial details from their childhood, but won’t be asked to reveal anything too personal. It’s a marvellous first step towards revealing more personal details, stories and insights. That leads to greater vulnerability, greater vulnerability leads to greater trust and greater trust leads to greater teams.

If you want to know more about the Five Dysfunctions of a Team, Patrick Lencioni gave a great talk at London’s Royal Albert Hall in 2013.

© 2017 Agile Aspirations

Theme by Anders NorénUp ↑