Agile Australia 2017

Melissa Perri at Agile Australia 2017

It’s been two weeks since the Agile Australia 2017 conference in Sydney, it was great to see so many people there and the quality of speakers was very high. Here are a few snippets from the conference.

Melissa Perri spoke about ‘The Build Trap’ and how it is easy to get very good at writing specifications and stories, which is the ‘build trap’. There is more value in understanding the true needs of the Customers and building to those needs. Melissa also had a great way to explain the difference between Product Manager and Product Owner ‘Product Owner is a role you play on a Scrum team. Product Manager is the job’

Sami Honkonen showed us how the Cynefin Framework is one of the building blocks of a Responsive Organisation – it helps us understand why Agile works in a complex adaptive system. Sami also talked about how structure drives behaviour and that it’s not the individuals, but the structure that they are in. I have also found the concept from Sami about designing very small experiments (ones that can be done in minutes) very useful.

Chris Chan at Agile Australia Lightning Talks – ‘Pirate Metrics’

The lightning talks were little nuggets of knowledge and very well attended. The picture above is from the ‘Pirate Metrics’ talk by Chris Chan – his way of explaining AARRR using examples of Pirates going into a bar is engaging. For example – Referrals – one Pirate saying to another ‘Arrr – you should try out this bar, it’s good’

The Deep Dive sessions with the keynote speakers were a bonus – Agile Australia has started doing this in the last couple of years. These give us the opportunity to learn more from the speakers, especially when they cover such interesting and useful items in their keynotes, that leaves us wanting more details.

Efficiency and Behaviour in Different Contexts

I like efficiency – when I walk into a shop, I want the sales person to help me find what I’m after and process the sale in a business-like manner. I also like to be treated as a person.

The other day, I was getting an ID card and the person serving me took a little extra time to find out about my transport means to the site. She then let me know about an extra public transport service that I wasn’t aware about. This is now saving me 10 minutes travel time each way which is 20 minutes per day. So a little less efficiency in one transaction has resulted in ongoing efficiency for me on a weekly basis.

ID sketchWhen is efficiency good and when is it bad? It’s related to the type of system we are in.

In the obvious domain on the Cynefin framework, we can attain best practice – repeatable processes. Here we can see the cause and effect relationships, observe bottlenecks and optimise the process to make it more efficient fairly easily.

In the complex domain, efficiency is not easy – or is about something very different. Using my ID example, by having a little chit chat with me, the service centre person was able to identify an extra need that I had and supply me with valuable information. The efficiency in that exchange was the use of ‘anticipatory awareness’ – being sensitive to the hints in conversation that could express a need. Great sales and service people are very good at this – if we asked them to document the process they use, it would not be easy. It would not be a step-by-step ‘recipe’ – instead it might be something like a multi-branching if/then/maybe flow chart thing. I’m certain that it would be adapted or added to after almost every interaction.

Another example of efficiency being bad is in farming, Imagine that we created plants that could extract all of the nutrients they needed from the soil and grow until the nutrients in that place were all taken up. This would be a disaster – we could only grow one crop in that space and it would desperately need all sorts of composts and fertilisers before it was useful again. If it can be that bad in a farming sense, perhaps we do not want all of our best practice processes to become super-efficient – it could deplete supplies in ways that we cannot anticipate.

In summary, efficiency can be good when we have processes that sit firmly in the obvious domain and can achieve standardisation and best practice (except if the efficiency leads to resource depletion). In these cases we can save time, money and effort by becoming more efficient. Efficiency can lead to poor outcomes if we try to apply it in the same way to the complex domain – this can waste time money and effort in the pursuit of gains that are not possible. Instead, here we want to sharpen our awareness and improve our methods of detecting small signals.

Linear, Non-Linear, Predictable and Unpredictable

Firstly, a thank you to Torbjörn and Steve for the conversations and feedback leading to these thoughts. Torbjörn has also written a post on this theme for those who have not yet seen it.

We can have a tendency to use linear and predictable as synonyms, but there are non-linear concepts that are also predictable and one of them is called hysteresis.

The easiest example of hysteresis is a thermostat for a heater. If we use one temperature setting to turn it on and off, then it will click on and off endlessly. If we set the on temperature just a little under the desired one and the off temperature just a little over it, then it works much better. When we walk into the room and measure the temperature only, then we cannot know if the heater is currently on or not without knowing the historical temperature and thus whether the room is currently cooling down or heating up.

So this is an example of a predictable process that is non-linear – we can use mathematical modelling to generate that predictability. I wonder if there are other processes that are non-linear, but still have some predictability in our work places.

One example might be change initiatives. We start at one level of understanding, do some training, coaching, communications and other ways of influencing change. After a period of time we move up to a new level of understanding. Then as other things happen and new people join the group, we lose some of that understanding – but it is likely that we are still above the original level.

I’m still looking for other examples – but hypothetically, a whole bunch of non-linear processes over-lapping and intersecting with each other would likely look like a very complex system.

Of course, mathematically, we would then be able to demonstrate these parts of the system and their predictability – but that is not really the point. We are all observers of our world and how we experience it as individuals is different for each of us. Therefore, the natures of systems that we interact with will differ according to our experiences of them and what seems predictable to one person can appear quite random to another one.

Back to the title of this post – along the gradient of predictability, we move from linear with obvious cause and effect to non-linear, such as hysteresis with less obvious correlation, then towards a lot less certainty where the relationships are dispositional and then to randomness. Most of the time whatever we are observing is likely to have a mixture of these attributes both inherently and from the ways that we experience it. Taking the example of a thermostat, I wonder how many other things also appear quite simple and are really elegantly complicated and on the flip side, how many things appear complex and are likely non-linear, but still predictable?

Questions as Boundaries

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.

Question‘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.’

Obvious StepsHowever, 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.

Complex SpaceIn 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.

Questions as BoundariesQuestions like

  • 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?’

Questions on Cynefin FrameworkIn 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.

Grateful

It is a beautiful Sunday morning and I was reflecting about the way I used to perceive time.

I used to see the weekends as jewels that were very far apart on a string of grey and dull time that included the obligations of work in between. I would despair that the weekends were so short and start to feel stressed from Sunday lunchtime about how little I had achieved in the weekend.

That was a long time ago – now I see things very differently.

Each day is a gift and I am curious to find out what I will learn from every single day. The reason this has changed is because of the joy that I have in learning new things and having the freedom to do this at work as well as privately.

I am grateful to all the people that have helped me to understand new ways of working related to Cynefin, agile, lean and beyond. You know who you are – if we have ever spoken/tweeted around these topics, or if you have written posts, tweets or books that have inspired the people I have spoken to…Thank you.

 

Complicated Kanban?

Catherine Walker has asked if ‘…professional designation edges the Kanban community towards the Complicated domain…’ in a recent post. On a slightly different tangent, I think that aspects of Kanban sit in each of the Simple, Complicated and Complex Cynefin domains and the complicated aspects are the ones that could be used for certification purposes if needed.

Here is an explanation using a Kanban board as a simplistic example – of course, Kanban is much more than a board…..

Simple BoardSimple Domain – Simple Board

Setting up a board to visualise the work is easy – anyone can put up 3 columns and place work items into ‘to do’, ‘doing’ or ‘done’. This puts it into the simple domain.

Psychology of the BoardPsychology of the Board

Understanding the reasons why visualising the work on a Kanban board helps us in  many human ways takes education and expertise. Thus it belongs mostly in the complicated domain. This is an example of an area that could focus on certification – where patterns have stabilised and outcomes are predictable.

Speaking BoardBoard Informing Work

One of the most powerful things about the simple Kanban board is how it can show us ways that the work is flowing (or not) so that we can improve the ways we work. What the board will show us will be different for each context that it is used in and thus sits in the complex domain.

 

 

 

Industry Migration to Complicated

As an industry matures, does it become less complex and move into the complicated domain on the Cynefin framework? Catherine Walker asked this question in a recent post and these are reflections.

Industry Migration to Complicated on the Cynefin Framework

As  a whole, the industry itself does not move from the complex domain to the complicated domain. It is closer to the images above.

Emerging Industry

When it starts, there are a lot of unknowns. As we learn more about the system, some practices become stable, but require expertise. Some practices even become well-known and move into the simple domain.

Developed Industry

Over time, there are more practices that are stable, more predictability and the industry can be well understood by experts. There are also more best practices. However, there is a danger in the simple domain (and probably also in the complicated domain) that something will tip the system into chaos – like when our Ferris wheel cracked in Melbourne.

With most industries, we will continue to push the boundaries and this is what will keep them active in the complex domain. It is likely that industries ‘pulse’ between the two diagrams, moving back towards the emergent picture when we learn that we did not really understand as much as we thought we did. An example is positive psychology of recent times.

Framework Examples

It can be tricky to come up with examples to use for the Cynefin domains when we are facilitating workshops.

The examples need to be easy to understand, but not so close to the topic of the workshop that accidental bias is introduced.

It turns out that the word ‘chicken’ is  great source of examples.

  • Simple – Chicken, everyone knows what a chicken is
  • Complicated – Gender of chicks, it is a specialised skill to tell the gender when they are so young
  • Complex – Why did the chicken cross the road? The answer to this joke can be different every time and hard to predict
  • Chaos – A headless chicken
  • Disorder – a fox in the henhouse

Learning in the Cynefin Domains

If you are not familiar with the Cynefin Framework by Dave Snowden, you might want to have a quick overview by watching The Cynefin Framework

Different management methods work better in some domains compared with others, so I was wondering if different learning styles might also be more effective in some domains than others.

Learning mapped onto the Cynefin Domains

Notice that the lower two domains, Chaos and Simple, focus on learning by repetition and the upper two domains, Complex and Complicated, focus on higher forms of learning (and unlearning).

In disorder, meta-learning might be more useful or perhaps the act of learning is one of the things that pull us out of Disorder into the other domains.

Learning in the Complicated domain is how we develop our expertise – the more patterns and interactions we can learn about, the better we get at predicting how to get good outcomes and avoiding re-work and waste.

Unlearning is more important in the Complex domain – the more patterns and predictions we are good at, the less likely we are to notice the emergence of something new.