What can we do about Workshop Remorse?

Admin on 21/07/2018

Workshop remorse

A workshop is arranged with the goal of solving a particular problem. Let’s say the problem is that the pages in a section of a website have become messy and need to be reorganised to improve the usability for visitors. The workshop uses a card sorting exercise to rearrange the existing pages and create a new structure. Everyone in the workshop accepts it and agrees the next steps.

Then… a few days after the workshop, some worries start to creep in. Things like, what if the changes affect our page search rankings, what if the changes make it harder for my customers to do what I want them to do, what if my manager doesn’t like the changes I agreed to.

That’s workshop remorse.

So then the emails start, emails that communicate those doubts and create little speed bumps. Shared among the group those worries multiply, and quickly people start to think of reasons why not to do what was they agreed at the workshop. The speed bumps grow into road blocks and everyone agrees that it would be better to wait some for seemingly connected thing to happen before we go back to solving this problem.

That’s the impact of workshop remorse.

How can we tackle it?

Every workshop should be about creating a space that has psychological safety for those involved. They should feel safe to say things they wouldn’t normally allow themselves to.

Maybe a part of a workshop should be spent talking about fears, concerns, barriers, internal agendas and organisational politics to bring this remorse to the forefront before it happens. Talk about it and tackle it.

Let’s see if by making the organisational politics visible we can challenge it. There’s no blame, we are all victims of our organisational culture and all implicit in creating it, so let’s be open about it.

Let’s see if by admitting our fears and worries we can overcome them and take control of them rather than allowing them to impact the work we want to do. It’s fine to have fears, we’re all human.

Let’s see if by talking about internal agendas we can reach some shared objectives that help everyone achieve. It’s not a zero sum game. One person doesn’t have to lose in order for another to win. We can all win if we work together.

What could we do?

We could hold a ‘Confessions time’ as part of the workshop. Maybe people would feel like it’s ok to open up.

Someone who has been workshops like this before might say: “I’m concerned that we’ll do this exercise but it’ll take so long for us to make any positive changes that we’ll all lose our enthusiasm and it’ll feel like wasted effort.”

The person running the workshop might say: “My worry is that you all won’t trust in the process and will want to feel in control of what we produce rather than allowing what users want to guide us.”

One of the less confident people in the group might say: “I’m worried that my part of business will be under-represented and I won’t achieve what I’m supposed to.”

And so everyone starts to understand how everyone else is feeling.

Then we can get on with the card sorting, because actually the workshop isn’t really about organising pages on a website, it’s really about having a safe and inspiring place to work, it’s about how we can improve the organisation one step at a time, its’ about people working together to create something awesome.

No deadlines

Admin on 14/07/2018

Scrum works for cross-functional teams of specialists that only work on one thing at a time and have everything they need within the team to complete the work.

Scrum has the #NoEstimates movement that says slicing work small enough enables teams to incrementally deliver value without requiring any kind of estimation.

But Scrum doesn’t work for multi-functional teams of generalists that work on lots of different things at the same time and have to work with other parts of the business to accomplish their goals.

I’d like to propose #NoDeadlines for modern agile teams not using Scrum and working in ways that mean the work they are doing requires collaboration with other people and teams who also have other work and different priorities, and which is often out of the teams control.

#NoDeadlines recognises that it’s impossible to accurately predict when work will be completed if it is dependent on people that aren’t part of the core team doing the work. The more people and teams involved, and the more things those teams are working on, the more impossible it becomes to accurately predict when any piece of work will be completed.

Commitment to deadlines should only be made if everything that is required to meet that deadline is within the control of the person making the commitment. If any element of the work requires input from someone who isn’t part of the team doing the work, isn’t asked to commit to the same deadline, has other priorities, works to a different schedule, or suffers no consequences from not meeting the deadline, then deadlines should not be set.

Deadlines set in these kinds of situations are at best completely arbitrary and at worst pure fantasy. Communicating fantasy deadlines to other parts of the business undermine the team when those deadlines aren’t achieved because the team needed input from other people who weren’t committed to the work in the same way.

Not setting deadlines takes the pressure off of teams from chasing unrealistic fantasy deadlines that they don’t have control over and provides psychological safety to experiment rapidly and focus on delivering value to the customers when that value is ready.

Buying and merchandising teams have always been Agile

Admin on 02/07/2018

For a Buying and Merchandising Team performing quite a traditional function for a business that is moving towards a more Agile approach, the uncertainty around impending changes could be a cause for concern. But they shouldn’t be. I think Buying and Merchandising Teams are already working in quite agile ways.

Accepting change

Merchandisers will start a year with a target for how much they think a product will sell, which they use to buy the right quantity of stock. They’ll create a plan based on last year’s sales information to suggest how much will sell, when and where (which shops), but

Merchandisers inspect the sales and adapt the replenishment of stock to shops to maximise the sales potential.

Small batches

A merchandiser could send all the stock they have out to shops at the beginning of the season, but instead, through analysis of sales patterns they break the stock down into small batches and distribute it to shops for when they need it.

Merchandisers slice the available stock into small batches.

Fast feedback

New products are introduced in a disciplined way. They are bought in smaller initial quantities, trialled in a small number of shops, and watched carefully to see how they perform. These initial reactions are then used to plan further roll-out of the product to more shops, or discontinue the product.

Merchandisers get fast feedback from customers and use it to inform how to distribute stock to shops.

Backwards looks like the right way round

Admin on 13/06/2018

Backwards looks like the right way round

A director emails two managers about building something new to solve an existing problem.

The first manager says:

  • Let’s have a meeting.
  • We’ll have to get more resource.
  • We’ll need to understand the requirements.
  • I’ll write a Proof of Concept Document.

The second manager says:

  • Let’s build it.
  • We’ll get customers using it.
  • We’ll learn loads about what customers actually want.

The first manager is solving organisational problems. The second manager is solving customer problems.

In a large, traditional organisation, the first manager looks like the one who’s doing it the right way. The second manager is a heretic who isn’t ‘thinking strategically’ and is considered to be doing it the wrong way. But it’s backwards. Delivering value to the customers and starting to learn about their problems as soon as possible should be what’s important. That’s the right way round.

National Defibrillator Database: How to do it wrong and how to do it right

Admin on 14/05/2018

The problem

When a person suffers a sudden cardiac arrest every second until they receive a shock from a defibrillator drastically decreases the chances of them making a recovery. Getting a defibrillator to the patient quickly is literally a matter of life and death.

There are lots of defibrillators out there (although no where near enough to really be effective in a sudden cardiac arrest that could happen to anyone anywhere at any time) but no one knows where. The retailers who sold defibrillators know where some are, the fourteen different ambulance services know where some are, and a few other organisations such as charities know where some are. But just knowing where the defibrillators are isn’t enough. To be useful you also need to know if the defibrillator is available at any given time and whether it has been maintained.

And no one knows all of this, so no one is able to provide full and up to date information about all of the defibrillators across the UK for use by Ambulance Services and the general public when responding to a sudden cardiac arrest.

That’s the problem, what gets in the way of a solution?

The barriers

The barriers to achieving this aim come down to two main factors; it’s a disparate space with lots of organisations doing different things, and many of those organisations rely on individuals who have lots of other work to before they get around to entering details about a new defibrillator in a place they’ve never even heard of.

There are fourteen Ambulance Services across the UK, retailers and suppliers, charities, and thousands of parish councils, sports centres, shops and offices that all have a piece of the picture about defibrillator availability and no way of sharing their information.

The second major barrier is that currently creating even the smallest piece of the picture is almost entirely manual. It requires individuals who are already busy with their day job at the parish council, sports centre, shop or office to check the defibrillator, record the information, and send it somewhere. And then it requires other individuals to receive that data and manually enter it into a database.

Building for the past (or how to do it wrong)

If we were trying to solve this problem in the 1980’s we’d definitely build a centralised database, controlled by a single organisation, that requires other parties to send their data to be added to this central system. We’d try to get all those parties to ‘collaborate’ with the central authority (which of course many of them wouldn’t want to do as they have a vested interest in not sharing data to make their solution the one that succeeds), and we’d spend lots of time and money building something that is out of date before it even launches.

If everyone who has tried to solve this problem in the same way, and no one has managed a solution yet, maybe they’re trying to solve the wrong problem. Maybe the problem isn’t about trying to get people to cooperate to get all the data in one place, maybe the problem is about getting all the data to all the people so they can do what they want with it.

Building for the future ( or how to do it right)

Decentralise, distribute, and digitise is the future thinking approach. Use Blockchain technology to identify each unique defibrillator device at manufacturing source, record the logistics steps in the blockchain, record the location of where the defibrillator and it’s availability, record regular system checks (without the need for manual inspection), record the usage of the device in emergency situations.

Recording all this data about defibrillators in this way meets the Multichain criteria for choosing blockchain over a relational database: ‘Blockchain works for databases that are shared by multiple writers, who don’t entirely trust each other, and who modify that database directly, and there is some interaction between the transactions created by these writers, and an authoritative final transaction log on whose contents all nodes provably agree is required’.

Blockchain technology has proven use in the fashion industry for ensuring the authenticity of garments. If it works for a shirt it’ll work even better for a defibrillator that has a unique identifier and a proven and vital need to make location and usage data available to other organisations.

So, rather than trying to get fourteen ambulance services, numerous suppliers and retailers, and thousands of defibrillator owners to all share their data on a regular basis to update a single central system that none of them have any stake in, the blockchain approach allows for device to share it’s data to a decentralised ledger and make that data available to all the contributors, so if any of them choose to maintain their own centralised database of defibrillator locations they can pull that data and more from the blockchain, ensuring that all lists are always as up to date as possible.

If the aim is to make more available more data about defibrillators, then this approach achieves that in a way that the old approach could never do.

Quality quantity discussions rather than iron triangles

Admin on 07/05/2018

Waterfall says Resource and Scope should be fixed and Time is the variable for delivering projects. Agile (or maybe Scrum) says Resource and Time is fixed and Scope is variable.

Nothing is fixed

Fixing resource is kind of nonsense when by ‘resource’ we mean people. People take days off, have good days and bad days, get more done on some days than others, so resource is constantly moving in both quantity and quality. In reality nothing is fixed.

Scope = quality

When we talk about Scope we’re really talking about the quality of the solution delivered. Sometimes, if the quality of solution required is too great for the fixed length of time then the quality (scope) is reduced to fit the fixed length of time.

Time = quantity

When we talk about fixing Time, such as in a two week sprint, we are really talking about the quantity of output, the amount of work that gets done.

Quality / quantity

This is why the Scope / Time discussion is really a quality / quantity discussion. If you reduce the Time available to work on a solution you have to reduce the Scope of what will be delivered. You can have it in one day and the solution will be good, or you can have it in one week and the solution will be better, or you can have it in a month and the solution will be the best. Sometimes ‘good’ is good enough, and sometimes ‘good’ is all you have time for, but by fixing Time (and so fixing quantity) you limit the ability to deliver the best solutions.

Perhaps allowing the team to decide what quality of solution needs to be delivered, and how long that solution will take to build sets them up to do great work rather than doing just what they can fit into an arbitrary length of time.

Good, better, best solutions

Admin on 06/05/2018

In retail, people often talk about a product and its position in the market as either ‘good’, ‘better’ or ‘best’.

Heinz position their baked beans as the best. HP might decide not to invest the considerable resources it would require to challenge Heinz’s positioning and instead position their baked beans as ‘better’. The supermarket own brand baked beans would be positioned as ‘good’. (Supermarkets also very successfully introduced a ‘basic’ level to this hierarchy and I can remember as a student being able to buy a tin of baked beans for 9p).

This hierarchy of perceived value can be applied to building solutions to a problem. There could be a good solution, a better solution, and the best solution. The higher up the hierarchy the solution is the more costly, complex, time-consuming it’s likely to be, but it delivers more value than the lower solutions.

Knowing what a ‘good’, ‘better’ and ‘best’ solution looks like helps with plotting the future of the solutions. A good solution might be enough for now but a better solution will be required within a year.

Good, better, best… but never perfect

Admin on 06/05/2018

Baked beans can be good, or better than good, or the best, but never perfect. Are perfect baked beans an impossibility?

Solutions can be good, or better than good, or the best, but never perfect. Can the perfect solution exist?

From a Zen point-of-view, ‘perfect’ is a fixed, dead state, unable to grow, evolve, or improve, so the solution may be perfect right now but as life and the world moves on it becomes out of date and no longer perfect.

So the perfect solution would need to evolve into different solutions to meet different needs at different times. It’s complexity increases as it evolves, and that complexity comes with a cost that makes the perfect solution unviable.

Maybe ‘good’ is good enough.

Transparency because…

Admin on 06/05/2018

…stuff gets lost in hand over.
…sharing work creates faster feedback.
…communicating openly builds trust.
…responsibility and accountability are everyone’s responsibility.
…planning is easier when done in context.
…opportunities for convergence are essential.
…generalists learn together.
…course corrections happen faster.
…team culture should be nailed to the wall.
…decision making involves everyone.
…knowledge is power, and everyone should have the power.

Certainty and uncertainty in value and duration

Admin on 05/05/2018

John Cutler tweeted about how he approaches forecasting with a team, and shared a Google Doc explaining the method.

Certainty and uncertainty in value and duration

One the second page was this:

Certainty and uncertainty in value and duration

This is important. It made me realise that initiatives can / should be considered / assesses / prioritised / forecasted on how certain or uncertain the value they will deliver is, and how certain or uncertain the duration is. Initiatives of unknown duration and unknown value are high risk compared to those of known value and known duration.

So, we need to have a reliable method for forecasting cycle time (not estimating effort time) to arrive at a known duration, and for establishing value (including cost of delay) as a known quantity.

Making these method of prioritisation explicit, reliable and robust is vital for across the organisation (not just within the digital department or within the scrum team) in order to be part of the mind shift towards delivering value continuously.