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.