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.
Following on from the earlier post about decisions, what would we do differently if we realised that we have been mixing together the concepts of creation work and information flow work?
This is the way we usually think about work – doing things, fixing things, reporting completion rates and then measuring the amount of value delivered. As we perform this work, reports get generated, decisions get made and dependencies managed.
Information Flow Work
Information is required to support decision making and also for the purposes of monitoring. We tend not to focus on this type of work. There may be an advantage to specifically calling it out.
- Groups that gather data to flow up to decision-makers – if there is clarity about what decisions are being made and what information is required in order to make them, then these groups could be more effective
- Groups that help disparate teams to work together – what decisions do the teams need to make or what types of data do the teams need to monitor for dependency, risk and issue management?
Perhaps our work structures would look more like the picture below.
Creation and Information Flow Work Intertwined
Roles and teams specifically created as either primarily creation work or information flow work and then structured so that they intertwine. This could free up capacity in the creation work roles as they would not need to do so much reporting. It could also allow the information flow roles to better describe the value that they provide to the organisation in the support of decision-making, communications and monitoring.
The method for Multi-Hypothesis research that Jabe Bloom describes in his Failing Well session is very useful for exploring ideas and gaining new insights to problems.
The main idea is to use ambiguity by presenting factual statements to a group and allowing each person to form their own opinions and conclusions about those facts.
We ‘unpack’ what thoughts may have led to the original opinions and conclusions, some thoughts will be certainties that the facts are right or wrong and others will be guesses and doubts.
- Guesses and doubts are then explored to find ways that we can conduct tests or experiments in order to learn – the focus being on the smallest effort we can invest in order to learn something useful, regardless of the test failing or succeeding.
- Certainties are sometimes worth testing as well – in the picture above, we try to invalidate gravity by throwing a ball – if it did not fall, we would be surprised and have a great opportunity for learning.
This workshop method can be completed in as little as 60 minutes with a small group, 90 minutes is comfortable for a group of about 10 people. It is a great way to get a lot of ideas in a short time and to shed some biases in our thinking by allowing many different points of view.
There are many ways to improve the way we work.
Agile, Lean, Cynefin, Lean Startup, Kanban, XP, TDD, BDD, Srcum – these are just a few.
There are also many ways to apply these approaches to the way we work.
Ways to Approach
As a ‘pure’ method, a set of principles, a staring point, assembling a mixture of approaches appropriate to the problem we are trying to solve.
The great thing is that it gives us many combinations to try so that we can find solutions that suit the outcomes we are aiming for.
The down side is that it can be very hard to choose an approach – what has worked for one place, can be difficult to apply to another and get the same outcomes.