The A-Ruminations team discuss knowing where to start, enabling constraints and metrics.
Category Archives: Principles
Efficient Expediency?
Steve, Tobbe and I were discussing actions and the differences between working in efficient ways and working in expedient ways.
Efficient is a non-judgemental word and rather clinical – are we working in ways that reduce or eliminate the waste of resources, effort, time and money?
Expediency has a moral element – doing things in ways that are convenient regardless of whether they are morally the right things to do.
I did not notice my attitude to visual management changing – it struck me only recently. When I first started to work with cards on the wall, I thought it was about accountability. I would feel awful if I pointed to a card that I said I would finish yesterday and I still had not completed it today. Now I feel fine using cards on the wall to see how the work is flowing. It gives me ways to capture data and articulate where the workflow is being impacted. The focus is not on me and my accountability (there are plenty of other ways to look after that in the workplace) – the focus is on how we can make the system of work flow better.
Getting back to the words – expedient and efficient. Kanban-style visual management is a very efficient way to visualise the work in order to improve it, it allows us to see queues of work that are otherwise invisible. I have also heard horror stories of it being used to victimise people – it is an expedient tool in that respect. Someone could stand at the board, point at a card and interrogate the team about who is working on it, why it has not moved and yelling could happen. Unfortunately expediency also often includes efficiency.
Because I had not noticed the change in my attitude, I am careful to explain the difference when speaking to others who are new to visual management – it is likely that they may be feeling the accountability side just as I did at first.
Action and Activity
Action – doing something that will result in a valuable outcome
Activity – doing something – regardless of the result
We tend to think that if we are not doing something then we are not being productive – we need to be cautious of doing things because we think that more is better. There are many examples where more is not better – even drinking water. We need to stay hydrated and we think that drinking more water is better for us – but over a certain amount, it can cause toxic and dangerous effects on our bodies.
Since the discussion with Tobbe and Steve recently, I’ve been reflecting about times in my life when I’ve mistaken activity for action – there’s more than I’d care to admit at this point.
We should check what we are doing and ask ourselves – is it activity for the sake of activity or are we taking action and making progress – whatever the endeavour? To answer this we need to understand purpose.
One of my favourite things to check is the purpose of reports that are being generated. I’ve seen situations where there are 100’s and 1000’s of reports – and no one really knows how they are being used. The activity version of a report, likely came from an initial need to make a decision – let us imagine that we needed 3 types of data to make that decision – so we ask for a report every week with those 3 types of data. And then – due to the ephemeral role of data in decision making – we quickly discover that we need another 2 elements of data. Very quickly, we can have a report being generated every week with lots of data elements. A lovely amount of activity – but what if we are not making those decisions any more? And there are better ways to gather data when we need to make a decision – reports can be very . inefficient.
Whatever we are doing, ask about the purpose of it. Is it activity for the sake of doing something? (And therefore can we stop doing it?). Or is it action? (And we should continue).
Agile Governance
Or…How it is Difficult to Understand a Thing if you don’t Already Know the Key Thing
Governance is a word that throws me off – wondering what it really means.
It’s supposed to mean having clarified roles, accountability and responsibilities.
It means understanding how decisions get made and who makes them.
It means making sure that policies are in place and that processes are monitored to ensure that they are working as intended.
It’s tricky to explain governance in agile when people don’t already have a good grasp of governance in traditional organisational constructs.
It’s similar to when I was a new video editor and our organisation bought a fancy piece of equipment called an ADO – Ampex Digital Optics (It flew a small picture around the screen and cost over $100k AUD in the 1980’s/90’s…now you can do the same thing with free software).
We did not purchase the training reference materials and only had the operating manual – which kept stating to do this, that, or the other with a thing called a ‘keyframe’.
I had no idea what this keyframe thing was – and the glossary was not helpful – so I stressed and tried a few things – and eventually called another video editor who was more experienced and asked him.
He explained that in any movement from point A to point B, the key frames would be the start and end point (so you basically put the small picture into the spot you wanted it to start at and press the ‘keyframe’ button and then move it to point B and hit ‘keyframe’ again – then the small picture would move from point A to point B whenever the effect was run).
Once I understood what a keyframe actually was, the whole machine was unlocked and I could use all of the features – but until I understood it, I could not even start to use this very expensive machine.
Back to governance and agile – when we understand how decisions get made – it’s quite easy to translate roles such as Product Owner into an organisation – the same decisions are being made – we are packaging them in a different way in agile teams.
When governance is not well understood, we end up circling around definitions for Product Owner etc – we are already causing confusion by introducing a completely different way of working. And on top of that, we need to break apart the decisions, accountabilities and responsibilities and place them into the daily planning, checking and doing aspects of agile delivery.
A way forward is to spend some time ensuring that the governance principles are better understood for the pre-agile ways of working and only after that, attempt to translate into the agile context. It feels like taking a step backwards – and it is much better than going around in circles and talking at cross-purposes.
If governance was never really there in the first place – this is one reason for the impression that governance is absent in agile.
Personal Philosophy 101: No Solutions, just Tools
Personal Philosophy 101: No Solutions, just Tools.
In a world driven by a culture with a need to compete, complete, deliver and rapidly produce. I put forward, the simple personal perspective that there are no solutions, only tools and choices.
The need we all feel to deliver a “solution” for our customers and ourselves is admirable but it also has a much darker side and consequences. The unspoken idea that we can give people and organisations a solution, can be very harmful and blind us to the true solutions. The cold hard truth is that we can not give anyone a solution to anything, we can only provide them with tools, which they can use to help find their own solutions.
The underlying premise is that only “self” can find the “true solution” because only self can know the factors needed to solve anything often with many conflicting needs and consequences. To complicate the process even further, often these factors specific to attaining your true-solution are partly or mostly unknown. Therefore, if the self doesn’t know the required factors to attain the true-solution required how can a third party give them a solution?
It is this philosophical viewpoint, which leads me to the personal view that regardless of saying we deliver solutions, we actually can only ever provide tools so the client (“self”) can determine their own solutions.
We can provide options, opinions, advice and other tools but we can not actually quantify completely their requirements and the level of “hardship or discomfort” the client would find acceptable. In actual fact, they themselves, often are unaware of some or most of these factors, when they engage you to solve their “issue”.
The “solutions” we provide often become band-aids because of this very fact. If we do not know the complete environment, how can we provide a solution? If the customer is not aware or educated about the options, constraints, and issues how can any “solution” they ask for be anything but a band-aid? Just like a band-aid, these solutions sit on the surface and never actually become part of the “self” or culturally absorbed. The true-solutions are derived from “self” only when awareness of the goal and the issue matrix surrounding the goal are realised.
This may seem an unbeneficial viewpoint, yet if you and your staff understand this, then this acceptance will liberate and empower them to focus on the why and what-ifs.
Consider the developer asked to provide a solution for a customer, the first step is to usually focus on the constraints of the solution, not the issue matrix for the customer. In this step we immediately become solution focused not customer focused. Then we focus upon the constraints of the individual technologies we force upon ourselves to be used, not the evaluation of the best technologies or processes for the particular case. Again solution focused and constrained.
If we see our job as to provide tools we more easily embrace the path of discovery through discussion, communication, advice, options, and opinions and avoid the pitfalls of assuming the responsibility of a flawed band-aid solution.
The old saying “The customer is always right” always annoyed me, even when I worked retail. The simple fact is that if the customer knew what they needed, they would not need you. Your role is to help them make a good well-informed decision, your job is to give them the tools to do so! It is then up to them to decide their appropriate course. Some customers only focus on cost and then complain, others focus on brands and then become frustrated (you can’t complain when you spent that much). A few customers realise they need help and trust you will do the right thing by them. They are the customers you want and need to try and develop through education and together we may move a little further towards a better outcome, a true relationship.
LIGHTNING BLOGS – THE RULE OF THREES, OR THE RULE OF THIRDS.
LIGHTNING BLOGS
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.
Planning and Focus
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
But…
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.
Planning
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.
Retrospective Coherence
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.
Summary
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).
Sound Bites
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.
We filter without realising it – if we did not filter, we would be overloaded with information and find it very difficult to proceed.
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
- Approaches
- System
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
Efficiency and Transition Points
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.
In Summary
- 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.
Lean Kanban United Kingdom 2013
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