Weeknotes #92

Roger on 11/05/2018

What happened this week…

  • Reviewed the Stock Adjustments Interface Design Document.
  • Attended the GDPR webinar.
  • Discussed options for Online Shop interfaces into AX.
  • Attended the RMSP New Goods product set-up demo.
  • Did user testing with the new Online Shop designs.
  • Planned a Customer Journey Mapping session for Selling Defibs.
  • Reviewed Magento 2 functional requirements.
  • Added new cards to the Online Shop.
  • Finalised the new Supporter range proposal.
  • Met with a Defibrillators supplier.
  • Worked with the Survival Team on a chatbot for Restart A Heart Day.

Read this week…

Doing next week…

  • Finalising the first batch of designs for the new Online Shop.
  • Meeting with a Defibrillator supplier.
  • Reviewing the menu structure for the new Online Shop.
  • Preparing a prototype for the Selling Defibs proposition.
  • Discussing having Publications on the Online Shop.
  • Preparing for the Ecommerce meetings with the Warehouse Team.

Interesting stat of the week…

  • Comparing the last twelve months to the previous twelve months, the number of transactions on Mobile has increased 61% compared to 33% average across all device types, the revenue has increased 67% compared to 45% for all devices, and conversion rate has increased 20% compared to the average of 13%.

In the not too distant future….

  • Planning for Christmas cards.

Quality quantity discussions rather than iron triangles

Roger 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

Roger 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

Roger 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…

Roger 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.

Charities have to choose unsolvable problems

Roger on 05/05/2018

The biggest risk to a charity is solving the problem they set out to solve. If they solved it there would no longer be any reason to exist. So the aim for a charity is not to solve its chosen problem but just to make progress towards a solution. This is why charities have to choose unsolvable problems.

Certainty and uncertainty in value and duration

Roger 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.

Prioritising parking spaces

Roger on 05/05/2018

In an office with more people than parking spaces, we needed a fair way of choosing who should get one.

There are various ways we could have done but the best solution was priority based on length of service, so the longer you’ve worked at the office the higher up the list you go.

There are two reasons this is such a good solution:

  1. Length of service is a fact, and choosing who gets a parking space based on fact rather than opinion has clarity and transparency, and is easy to understand. And it turns parking into a benefit of long service.
  2. It means the older team members who are more in need of a parking space get one without getting into uncomfortable discussions about health, medical conditions, or who is most in need.

Even everyday things like allocating parking spaces require a method of prioritisation.

Finding the right way to prioritise is vital. Using facts is great. Making it clear and easy to understand for the people involved is important. Gaining additional benefits as a result of the method is a good thing to achieve too.