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.

Scrum ceremonies shouldn’t be ceremonial

I’ve been taking part in various types of Agile meeting for over three years, but I’ve only recently noticed the phrase “Scrum ceremonies” used to describe them. I’m not sure I’m entirely comfortable with it.

I'm a Town Crier

I’m a Town Crier

I’m a Town Crier. I attend public events on behalf of my local council, ring a bell and shout announcements very loudly. I do this wearing white tights, a silly pointy hat and a woollen coat that is far too warm for most of the summer events they ask me to attend. Why is this relevant? Because the role is purely ceremonial. Google’s definition of “ceremonial” says that it involves “only nominal authority or power”.

This doesn’t sound like the agile ceremonies that I’ve been facilitating. Our retrospectives certainly lead to change for the better, and when we do decide to have planning meetings or backlog grooming sessions then we use the team’s autonomy to decide what work should be prioritised and how we want to do it. Our stand-ups are vital for removing impediments and finding ways to move the stories on. The power our meetings give us is anything other than “nominal”.

Let’s consider the word “ceremony” itself. The definitions provided by Google variously describe it as something formal, ritualistic or following a “traditional or prescribed form”.

Does following “tradition” sound very agile? Is scrum intended to be a prescribed set of rules, or a suggested framework for teams to mould into a process that works for them?

My team at Ocado hasn’t followed a prescribed form for any of the four suggested scrum ceremonies. We have story-focused stand-up meetings twice each day, allowing for earlier identification of any blockers, resolution of problems and better visibility of stories. Our retrospectives have rotating facilitators who get to do their own thing, although we have decided upon a regular opening exercise to maintain some consistency. Failing to adapt these meetings for your situation is likely to lead to team members becoming bored. This will affect the value you get from these meetings. Rather than blindly follow the suggested formula, you should change and adapt your meetings until they provide value for your team.

If you find that a particular agile ceremony isn’t providing your team with enough value, even after you’ve modified it as much as possible, it’s fine to ditch it – as long as you find a way of reaching the intended goal. After moving to a Kanban board, my team didn’t see the need for regular planning sessions and sprint reviews. Instead, we plan stories in small groups at the point when we bring them onto the board. This only demands the time of people who are interested in providing input to that particular story, which can then be undertaken immediately with the planning process fresh in our minds. We don’t hold fixed review meetings, but we demo the finished user story to our Product Owner as soon as its finished and schedule a demo with the stakeholders at a time that suits them.

Equally, the four scrum ceremonies aren’t the be all and end all. Add further meetings where you see potential value. For example, we use the Toyota improvement kata to maintain continuous improvement.

When you’re sat in your next planning meeting, sprint review, retrospective or standing around your team board take a moment to consider what value you’re gaining. Can you make it more powerful and less ceremonial?

Kanban at home (aka “Fridge Kanban”)

Fridge Kanban

Fridge Kanban

My home life is quite chaotic. With three children, a long commute and generally making ourselves busy with visits to relatives and exciting places, finding time to do useful things at home is difficult. During the rare weekends we have nothing planned, my wife and I often build up lists of things to do – only to look at those lists on a Sunday evening and feel frustrated that nothing has been done.

I have begun to realise that the problems we face at home are similar to those that we often see in the workplace; difficulties in communication, collaboration and prioritisation. My wife always thinks that I “ignore” her list, but I always feel as though I never stop working – usually on things that I know must be done before the end of the weekend, like washing school uniforms.

Last weekend, I wondered if I might be able to apply concepts from work to solve these issues. I introduced my wife to Kanban.

We started by clearing a space on the fridge. Effective communication requires visibility – knowledge of what’s being worked on and why. The photos, crayon drawings of chickens and butterflies and the school lunch menus and newsletters had to go. Once we’d done this, I wrote up all of the items on my wife’s “TODO” list onto post-it notes and added some things of my own. I spread these out around the fridge, randomly. The chaotic nature we were working in was perhaps characterised by the contents of one of the sticky notes: “Find our printer”.

Next, we ordered these post-it notes on a two-axis grid: Important vs Urgent.

Important vs urgent

Important vs urgent

This was inspired by Eisenhower’s Decision Principle – the idea that some things which are urgent are actually unimportant and can be ignored. The theory argues that when you are continually working on things which are both urgent and important then you are working in a state of “chaos”. This is something I recognise. The theory suggests that you should work through these things first, until you reach a point where you can almost entirely concentrate on the “important-but-not-urgent” things. Once you reach this state you should ideally try to prevent important things from becoming urgent. Things which seem urgent but aren’t important are merely distractions, whilst things which are neither are procrastination.

Once we’d arranged the post-it notes we numbered them in order, starting at the top-right and working our way diagonally to the bottom left.

We then set up another set of axes: Ease vs Usefulness. You might be used to referring to usefulness as “value” in the workplace.

Ease vs Usefulness

Ease vs Usefulness

The idea this time was to try and identify things which were “low-hanging fruit”; things which would add value very quickly. Collapsing the empty boxes stacked in our dining room wasn’t particularly urgent or important compared to some of our other tasks, but it wouldn’t take long and would clear lots of space for doing other tasks. In my team at work, we’ve also discovered that lots of small wins is better for morale than working one one long (albeit rewarding) task for an extended period of time.

Again, we numbered these tasks from top-right to bottom-left.

I noticed that, as you might find in sprint planning or estimation sessions at work, the act of prioritising these tasks in a collaborative manner helped us to communicate to each other why we thought individual tasks were important. We knew what we needed to do, why we were doing it and what outcome we’d achieve by finishing the task.

We then drew up three very basic Kanban headings: “Ready”, “Doing”, “Done”. We added up the numbers on each of the post-it notes and ordered the tasks in the “Ready” column.

Kanban board

Kanban board

You might notice that we didn’t set WIP (work in progress) limits on the columns. We took in the whole list, and we limited WIP in “Doing” by having avatars (fridge magnets) showing which task each of us was working on. This meant that, at most, we could be working on two tasks at a time (one each), or we would be working collaboratively on a single task.

At first, the whole process seemed like overkill. Ultimately, it helped a lot. We didn’t get everything finished, but it was an ambitious list. Because of our sorting mechanism, we managed to complete a lot of important/urgent tasks we’d been putting off for a long time, as well as a lot of tasks which delivered a lot of value to our home life. I definitely think we’d use this process again.

While we were working on our kanban board, something interesting happened. Our five year old saw us writing on sticky notes and wanted to get involved. My wife found her some mini post-it notes and she set up her own kanban board. Once we’d set the board up, she wrote out most of the tasks herself and started working through them.

Children's Kanban

Children’s Kanban

To my astonishment, later on that evening she called her grandma and – entirely of her own volition – explained what Kanban is. So if you’re ever having trouble explaining Kanban to a team for the first time, remind them that my five year old can do it!

Unfortunately, we never did find the printer…

© 2017 Agile Aspirations

Theme by Anders NorénUp ↑