Welcome to the first in my lightning blog series. This series is for the ideas and observations we all make during our daily lives and rarely share or have time to explore them.
THE RULE OF THREES, OR THE RULE OF THIRDS.
The rule of threes is an observation I made while trying to save energy and money by examining and swapping light bulbs and the mode of generating the emitted light.
Sounds great and very intellectual but as usually happens you do something and then upon reflection realise there appeared to be a pattern. I actually was just trying to swap over to the newer 6 Watt LED bulbs, I had recently found in my local supermarket, to save money because my energy bills are creeping up there and starting to hurt (mother of invention).
I had swapped all the lights in my house with these 6 Watt LEDs, except for the two main lights in my kitchen and the dinning area. The reason these two lights hadn’t been swapped over, was that they were 18 Watt Fluorescent tubes. Well, finally the day came and I had decided it was time to do the swap. When I began to remove the fixtures, I noticed that they were not the original fixtures but had themselves been replacements for the type of light that was there previously. The original light fixtures were actually lamp holders, just like the type of fixture I was installing, great less touch up work.
Then it struct me, when the house was built the dominant form of lighting was incandescent bulbs. Incandescent bulbs ranged usually from 100 Watts to 60 Watts in your typical single light fixture for a room. Yes they made smaller bulbs 40 Watts and even as low as 20 Watts, but these were usually the bulbs used for bedside lamps or in chandeliers. The most likely scenario was that the original lamp holder would have held a 60 Watt bulb due to the small room size.
So what we had was a situation where if they had put a smaller bulb than 60 Watts the room would be poorly lite, however at the time, the more cost effective technology of fluorescent lighting would have meant a 20 Watt florescent tube would have given more light than the 60 Watt incandescent for a third of the cost. In fact the florescent tube would have probably given out the equivalent light from a 75 Watt bulb or more.
Now the fluorescent tube I was replacing was in fact, a newer more efficient 18 Watt florescent tube. Yet it struck me that I was now installing a 6 Watt bulb that was one third the wattage of the one I was removing. I also realised that the fluorescent must have been replacing a bulb at least three time the wattage as itself.
The rule of threes or thirds was born.
So did this mean that only when something became three times better or more efficient or used a third of the energy or effort, that we actually muster enough motivation or pressure to change?
Can the rule of threes be seen in other areas or even help us to decide when retooling or changing the way we work is most beneficial?
Like I said observations and ideas only in the Lightning Blogs. Food for thought and I hope the rule of threes or thirds may help in some way to guide you in your decision making.
Yes I know wattages do not equal Lumens but for simplicity, I didn’t go into that.
From Wikipedia : The luminous efficacy of a typical incandescent bulb is 16 lumens per watt, compared with 60 lm/W for a compact fluorescent bulb or 150 lm/W for some white LED lamps.
PS. Careful how you pronounce, The Rule of Thirds, it could be misunderstood as something else.
Plans are great!
- They help us focus and align to a goal
- They demonstrate that we know what we are doing
- They help us to break up work into manageable chunks so that we can deliver in stages or divide the work up between teams
What if the goal is to achieve innovation or find new ideas?
Let’s take the 3 points above and see how they might be detrimental when we are dealing with complexity as defined in the Cynefin Framework.
Focus and alignment
When we focus we can miss things. Try staring at something nearby now – focus on its attributes and why it is there. Notice that while you are focussed, other things become less noticeable in our peripheral vision, hearing and other senses.
In an ordered environment, where things are knowable and there is a high amount of certainty, focus is a wonderful thing.
In an unordered environment of complexity or chaos it can destroy us in the worst case – and in the best case it will limit our ability to find new ideas and interesting things. We still need to have an idea of what we are looking for, setting some constraints or boundaries – but it is not a laser-like focus.
We know what we are doing
People who use traditional planning methods in complex environments do not know what they are doing. The planning needed in complexity is how to manage constraints, how to identify ‘good’ and ‘bad’ patterns and how to amplify or dampen them respectively. Risk and opportunity management methods are much more appropriate in complex environments and traditional planning is great in ordered domains.
A person who knows what they are doing will use both types of planning/management, mixing and matching as they go.
Unfortunately, people are traditionally rewarded for showing how they executed to a plan and achieved an outcome. In this light, the outcomes achieved in a complex environment can only be described after they have happened. So it can look like random luck and is not generally well rewarded unless the outcome was an astonishing breakthrough or innovation of some sort. In these cases we will backfill the story in a retrospectively coherent way so that it seems the achievement was planned that way all along.
Divide up the work
Absolutely the best way to do something in the ordered domains. Break it up, build each part and then assemble it at the end.
When we try to do this in a complex environment we spend a lot of effort trying to get certainty. We also highly constrain the outcome to only that which we imagine is possible at that point in time.
So not only do we spend too much, we also sub-optimise our opportunities.
The better option is to explore the needs using test and learn approaches. Techniques for exploring the ‘fuzzy front end’ from design thinking work well as does prototyping, experimentation, articulation of assumptions and then validation or invalidation of them.
This is where we say that failure is good – let me explain that because many people have issues with such a statement.
When we are in a complex environment we do not know and cannot predict what will happen when we do action ‘XYZ’ and there are many actions that we could do. In order to find out what works and where the boundaries might be, we conduct experiments to see if there are stable and repeatable patterns. The experiments that work are what we are seeking and the ones that fail are outside of what we are seeking. Only by conducting experiments that fail can we be confident that we have found the edges of the space that we are exploring. If we don’t get failures, then we have not gone far enough and have missed opportunities for new ideas that might work.
So safe-to-fail experiments are important and the above helps to explain why we should be designing experiments that we expect to succeed and ones that we expect to fail – when do this we are guessing where the boundaries exist and the experiments confirm those boundaries.
These 3 examples demonstrate that our traditional planning and focus methods are really only suited to the ordered domains in the Cynefin Framework and that seemingly ‘opposite’ approaches are more effective in the complex domain.
We need more innovation and new ideas – we will not get them using standard planning and focus methods.
Plans are great – when we have certainty and predictability (and not when we want new ideas).
If you take only one thing away from reading this post – it is a caution to be very careful with taking only one thing away from any interaction.
We are evolved to filter information so that we only need to focus on things that are important to us – that’s why painters can put a few brush-strokes on a canvas and we can interpret it as a person walking on the beach in the distance.
When we have a conversation with someone, we imagine that they understand everything that we say in the way that we intended for it to be meant. The only thing that we can be certain of, in fact, is that the person will have interpreted what we said in the way that made sense to them. Of course what makes sense to the other person might or might not be aligned with what we actually intended.
One time, I came away from a conversation wondering why the person had started to debate the pros and cons of scrum when I had been meeting with them about something else. On reflection, I realised that my job title at the time contained the word ‘Agile’ so that person thought that I was only speaking about scrum teams and the delivery process. It was likely that the other person had a very different definition of agile – mine is a very broad one and includes Lean, Cynefin, Design Thinking and many other useful ideas and approaches. Others might define agile as ‘scrum’ and not much more for all sorts of reasons. This means that the other person was filtering my part of the conversation through a ‘Kim is here to talk about scrum’ lens which led to a complete misinterpretation of what I was asking about.
How does this relate to the title of the post ‘Sound Bites’?
We in the Lean and Agile communities have discussed and investigated many concepts and are in the habit of using short descriptions for very complex ideas. Within the community, I can say something like ‘I like to use the Cynefin Framework to help me determine which approaches are compatible with the system that I am working with’ and lots of people would understand what I meant to say. But I have spent a lot of time reading about these ideas, attending conferences, speaking with experts and trying them out so the following terms are loaded with deep meaning;
- Cynefin Framework
These terms are at risk of becoming ‘sound bites’ – the main thing that an audience hears and therefore believes is the main message. They could then try and apply one of the concepts, or an extrapolation of these ideas and end up with a completely unexpected result.
This is not the first time ‘sound bites’ have happened in our human history. For example, Bob Emeliani wrote a great post recently about Frederick Winslow Taylor and how people partially applied his Principles of Scientific Management and ended up with a sub-optimal result.
What can we do about the problem with ‘sound bites’?
We need tailor our conversations to our audience. In a group of deep experts, it is fine for us to use our shorthand terms and jargon – but in a mixed group or with non-experts, it is as if we are teachers providing all the answers to students and not teaching them how to learn – so our words are ripe for misinterpretation.
Now that you have read this post and therefore interpreted it in your own ways, I would be very interested to hear about your experiences with sound bites, or what the term ‘sound bites’ means to you.
Please leave a comment or find me on Twitter: @kb2bkb
For the purposes of this post, the term ‘transition point’ means any point where something changes from one state to another. Some examples are;
- A caterpillar changing to a butterfly
- A company growing from a start-up to a large business
- Developing a skill from basic to competent and then to expert would be considered at least 2 transition points
We assume that it is easy to anticipate when transition points are going to happen – this is because for our whole lives up to now we are looking into the past and it is easy to see when transitions occurred. But this is a fallacy – we are using the benefit of hindsight to observe when the transition happened and in many cases we could not have estimated when the transition would occur beforehand.
Transition points can impact efficiency – I harvested some damson plums this morning and was pushing out the stones with a cherry pitter. Easy for 10-20 plums – but I was doing over 100 of them. The transition in this case was the scale of fruit that I was preparing – I found that I was picking up the cherry pitter, then putting it on the other side of the sink, then picking up a strawberry huller to get the stone out. I found that putting down the cherry pitter on the same side of the sink that I was working on instead of the opposite side sped up the process.
The same thing happens at work – imagine a small company dealing with incoming traditional mail – almost anyone can manage it on top of their normal job because only a small amount would get delivered each day. But it is easy to see a difference in a large company – often there are several people who have full-time jobs sorting and delivering the traditional mail and parcels. When did the transition point/s occur? How did they get detected and then managed?
When we notice problems, these can be symptoms of a transition point in progress – I noticed the delay caused by reaching to the other side of the sink and created a counter-measure to reduce the distance to put down and pick up the tool. But imagine that someone delivered a lot more plums to me – how would I process them in that case? The 100 or so this morning took me about 30 minutes to pit. The process I used today would be very inefficient in a plum jam factory – how many other things are we doing in ways that we always have and imagine them to be efficient? Perhaps an external factor has changed that we have not noticed yet and our ways of working have therefore reduced in efficiency.
The term ‘counter-measure’ in the Lean sense is starting to grow on me. It is a good term to use instead of ‘fix’ because any action that we take to address a problem is likely to become less useful later on and we will need to create and implement a new counter-measure at that time. It takes the pressure away from finding the perfect solution and focussing instead on one that is good enough to address the issue that we are observing, implement it and then observe the effect of the counter-measure – adjusting again when needed.
- Efficiency can drop if we apply the same ways of working when a transition point occurs
- It is easy to see the transition points afterwards, but hard to anticipate them – use problems and issues as indicators of transition points
- Using the term ‘counter-measure’ instead of ‘fix’ can be helpful to recognise that future transition points will happen and a new counter-measure will need to be developed later
Of course, this post has been using the term ‘efficiency’ which is not the same as ‘effectiveness’. We also need to be aware that the effort we are making is towards a valuable outcome. In the case of my plums, I am just about ready to put the cooked plum paste into a container – this is valuable for me, but not for people who do not enjoy the taste of plums. For such people, it might have been just as good for me to put the plums into a compost bin – but then I would not have had to remove the stones – so being more efficient with that process would have been wasted efficiency.
I enjoyed attending LKUK13 and would like to share some of the snippets that I found interesting. These are from my notes and are my interpretations – any mis-interpretation is entirely my responsibility and I am happy to receive any corrective feedback.
Mike Burrows – Kanban is like Onions!
- If we organise the work, we make it possible for people to re-roganise around the work
- Ask if any single improvement can benefit the Customers, team and organisation – the improvement is good if all 3 can benefit from it
- To help with paying attention to flow, then keep work sized to see movement every day
- Small acts of leadership – such as the routine from Toyota – leaders can ask
- What is the process?
- How can we see it’s working?
- How is it improving?
- Agreement from people versus agreement between people
Liz Keogh – Cynefin in Action
- Frog thinking vs bicycle thinking – we can take a bike apart and put it back together, and it will work again – not a frog
- We’re discovering how to discover stuff by doing it
- Deliberate discovery – Risk (newest things) first – tell the story that’s never been told
- Focus on how we can quickly get feedback
Edward Kay – Mulit-client Kanban
- The ‘ready’ column makes a good handover point
- Use ‘Help’ tokens to indicate that you need assistance with a story – either with context or skills – so that you don’t interrupt others and they can select their own time to help you
Torbjörn Gyllebring – #NoMetrics – the ephemeral role of data in decision making
- Lines of code is the best metric (and everyone hates this) – great for archaeology, but it’s all from the past
- Ethics – in a position of power, you start to influence people – do no harm
- Our customers are those whose lives we touch
- Clarification should be at the centre of any measurement effort
- Data needs to always be relevant
- Informational measures are useful – but it depends on how people perceive it
- ODIM – a good model – Outcomes, then Decision, then Information, then Metrics – use the metric and then discard it
- Know why you need the data
Yuval Yeret – Kanban – a SANE way towards agile in the enterprise
- When trying to change culture, engage in marketing – identify and nurture opportunities
- Start with leaders and managers
- Need to balance between prescriptive guidance and no guidance
- After a chance allow time to stabalise and recharge – then provide good reasons to get out of recharge mode
Chris McDermott – The Other Side of Kanban
- Encourage shared understanding – not managers are dating agents and chaperones
- Add a ‘ready to celebrate’ column onto the board
Stephen Parry – How to develop Lean leadership and create an adaptive, learning and engaging organisation
- Reciprocity only works when there is a sincere and genuine feeling – does not work if there is a feeling of manipulation – It can be negative
- ‘Dont bring me problems, bring me solutions’ is an example of leadership abandonment not empowerment
Chris Young – Models, Maps, Measures and Mystery
- Asked why customer approval waiting times went up a lot – led to the idea to have customers sit with the developers
- At one stage the customer started leading the standups
- Added an extra column to personal kanban board ‘didn’t happen’ next to the ‘done’ column
Jabe Bloom – What is the value of social capital?
- A value stream is a linear view of the social network
- Swarms – form temporary teams on high-value problems with volunteers
- Emergent slack – have 20% of time spent on interruptible tasks (tasks that no-one is waiting on)
- Social capital is the ability to distribute and leverage trust (reciprocity)
- In a low social capital environment we use consensus models
- In a high social capital environment we trust each other to make decsions
- Authority removes social capital (consumes it)
Jim Benson – Beyond Agile
- Flow if you can, pull if you must (pull systems are all remedial)
- No recipe for success – just a recipe for not likely failing
- Trying to do agile versus delivering value
Zsolt Fabok – I Broke the WIP Limit Twice, and I’m Still on the Team!
- If you understand small, incremental evolutionary changes and pull, then you can decduce the rest
- The goal is to have a stable system – easier to improve it
Alexis Nicolas – Management hacking in progress
- Managers should focus on learning. We can live with problems for 1 or 2 days because we have better risk management
- Change is viral – not prepared planning – we can design a viral change
Troy Magennis – Cycle Time Analytics – Fast #NoEstimate Forecasting and Decision Making
- Statistics is more of a logic problem than a maths problem
- When we forcast, state the level of uncertainty – ask what point would sway the decision
- Every choice we make changes the outcome – Decision induced uncertainty
- Diagnostic models allow us to run ‘what if’ scenarios
- Estimating what could go wrong is more important
- We should update our forecast each time we finish a piece of work because we have learnt more
The image that I have used at the top of these pages is a photo that I took outside the London Zoo on the pathway between Gloucester Gate and The Broadwalk path. It was in February 2012 the week after CALM Alpha and it was a beautiful day – I think that the temperature reached 16 or 17 degrees Celsius. I felt almost alone – there were not many people around and I took a few photos from the same point such as the one below looking at the zoo.
I chose the image for this blog because there are some shadows at the front and not many shadows cast by the trees in the distance due to the scattering of clouds that were in the sky. I find the idea of shadows interesting, it is another way of looking at an object and I wonder if we can use the concept to look at methods and principles or values?
If we start with a principle or value from Agile or Lean – are the methods that we use like the shadows of those principles or values? Or is it the other way around?