Tasks and activities are easy to manage – we see that a job needs to be done, schedule some time for it and then do it.
Queues are easy to see – waiting in line to pay for some goods when we go shopping – or waiting in line to see a popular tourist attraction. Waiting in queues like these is a good time to ponder about why the queue is there and how it could be better managed. Could the shop hire some more cashiers? Could the tourist venue allow more people through at once by setting out the attraction in a different way?
What about the queues that we cannot easily see such as those in our everyday work?
One thing that seems efficient is a regular set of decision-making meetings such as review and approval to proceed with an activity (like recruitment or a project). There could be a better way to manage these decisions – or are these regular meetings actually the most effective way to do it?
How many of us have rushed a presentation together to get it into the next cycle for a decision meeting? What might happen if the decision could be made as soon as we have brought together the information needed to make that decision? Would we have less of a sense of urgency and take longer to do simple things? Would it take less time because we know that the decision will be made as soon as we are ready for it?
The decision to proceed or not is a constraint – up until that time, we are not certain that the project or other action will go ahead. By holding a regular meeting for the decision-making, we are making efficient use of the decision-makers time – but we are introducing queues into the process. Imagine that there will be 5 project ideas presented at the next meeting – all 5 have different sets of data that they need to gather in order for the proceed or not decision to be made. This data-gathering will have different lead times and each project will actually be ready for the go/no-go decision well before the meeting – so the length of wait-time in the queue will be different for each of them. How many of us record these wait times? Those things that remain invisible cannot be managed – people will be waiting on the decision-meeting before they can do the next set of useful actions. We could have 5 teams waiting on one meeting with senior decision-makers – because that is the best way to use the time of those decision-makers.
Constraint management is hard to do because it is very hard to notice the constraints. We get used to it taking a certain time to do things and waiting for the next decision point – because that’s how it’s done and it appears to be efficient.
There are a lot of other constraints out there waiting to be noticed – the clues are there when our colleagues roll their eyes or complain about something. We can empathise with them and move on – or we can empathise and then dig a bit deeper.
- Is this a part of a pattern?
- Do other people also complain about it?
- How can we measure the things that people are complaining about?
- If we could measure them, what would we expect the measurements to be in order to validate or invalidate those complaints?
- If we are not already capturing the data, why?
Next time you are planning work – notice if you are planning activities, tasks or constraint management. Planning some time each week for observation sounds like a good idea – only by looking at something for a while and reflecting will we find ways to improve.
Have you ever been in a meeting that went a bit like this?
Somehow the meeting went off-topic, or a conversation suddenly took over the entire session. What went wrong? Perhaps our conversations were assumption-based rather than fact-based.
Assumptions are very valuable things, they help us to move forward. An obvious example is the assumption that the footpath in front of us is solid, if we doubted this all the time, we would have a lot of trouble walking around, let alone running or jogging.
The less helpful types of assumptions are ones that we make about our own or others definitions of words or level of understanding about a topic. I can remember having 30 minutes of strong debate about an issue a long time ago, only to discover that we were actually arguing for the same thing – just using different terminology.
When planning meetings and workshops, list out the topics that might cause debate or miscommunication and then ask what assumptions we might be making about those topics. Whenever possible, spend some time validating or invalidating those assumptions before the meeting so that we turn those assumption-based conversations into fact-based ones and use our time more effectively.
How do we know when we are asking a good or a poor question? One sign of a poor question is when people are spending a lot of effort for seemingly little gain.
‘What should we do?’ can be both.
If it’s been done before and there is a predictable, best practice way to do it, then the obvious answer is ‘The next logical step.’
However, if we are exploring complexity it can be a poor question, there are so many possible options that it can take a long time to decide what to do.
In order to explore something which has limited certainty, it is better to form a view or hypothesis and test it. This then creates a type of boundary around the thing we are trying to understand to help us make sense of it.
- Will ‘X’ happen if I do ‘Y’?
- Is it feasible to achieve ‘X’ for ‘Y’ effort?
- Will people buy our product?
For example, we often start a project by asking how much time and money it will take to make our idea a reality. This can drive a very large amount of effort to find out – when the project happens to be in the complex domain (as per the Cynefin Framework). If we change the question to ‘Is it feasible to make this idea a reality for $X and Y time-frame?’ it puts boundaries around the initial exploration stage and we can avoid large amounts of wasted and unfocussed effort. An example can be found in my previous post ‘Why do we Estimate?’
In summary, check which type of system the question relates to according to the Cynefin Framework. Then check if the question is helping to drive useful logical work or useful exploration and if not, then change the question.
There are companion posts from Marc Burgauer and Trent Hone about this topic – these 3 posts are our initial thoughts based on some Twitter interactions.
For the purpose of this post, the term ‘automation’ should be considered in the broadest possible sense.
If we think about software supporting and automating tasks such as ordering products and producing bills, then continuous delivery is like automating parts of the software delivery process. I thought that it might be a useful thought-activity to consider other forms of automation and see if that generates any insights – especially around how we decide what things are safe to automate and what things need to have human judgement applied.
One form of automation is refrigeration – imagine if it was manual. We would need to keep an eye on the temperature and add ice whenever it went over a certain amount.
In a broader sense, even pathways might be considered an automatic guide for where to step next and a convenient way to find places.
In the above two examples, we might make the decision about where to build a path once we see a worn track where many people have walked. We might decide to automate refrigeration because transporting and adding ice manually is very labour intensive.
On the safety side – a worn dirt track is not as safe as a textured concrete path because in the wet, it might be slippery. Also, hauling ice through the house risks injury and if we forget to add ice at the right time, our food will become contaminated and make us sick.
If we abstract these concepts, here are some good reasons to automate something
- We have already done it many times and will continue to do it the same way
- We know exactly what we need to do and it is hard to do it manually
- Problems are happening due to lack of care
There is still a bit more pondering to do with these thoughts and I am looking forward to further inputs and insights from Marc Burgauer and Trent Hone – thank you to both.
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
Thank you to Torbjörn Gyllebring and Thom Leggett for the conversations and inspiration to write this post.
It can be useful to step back from our work and study the decisions that we are making. Here are some of the ways to study decisions and how we can start to visualise the information.
Start by writing out the decisions and laying them out in a logical sequence – grouping similar ones together and consequential ones after each other. Draw some arrows between them – it can be helpful if another person is working with you to help clarify which decisions lead to others and their inter-relationships.
Sometimes there are loops such as the ones labelled ‘A’ and ‘B’ where, when we make decsion A, it changes how we should make decsion B which then impacts how we should make decision A. It might be possible that we get false ‘loops’ as well as the real ones when we are not clear about the decisions that we are making.
Once a decision has been identified, we start seeking the information required in order to make the decision. It is as if the decision is ‘pulling’ the information into it, and once there is enough, we can then make the decision. We can visualise this by writing the decision as a question on the top of a card and the information items required as bullet points under the question.
Some information items are actually prior decisions, we can use a code to link these cards together and put them up on a wall to show the realtionships. This allows us to have good conversations about both the activities required to gather information and the progress of the decisions that we are making.