Author Archives: kb2bkb

Deadlines – Looking Beyond

Posted on by

For many good reasons deadlines can be seen as bad things. For more context and clarity, I recommend Beyond Deadlines by Jabe Bloom.

So here is what can happen if we take the time to look beyond a deadline and ask about why it is important.

Imagine that we are going to have a birthday party.

And now imagine that we want to develop an application to help us organise and run the party.

We might start by asking for the full application functions to be ready 2 months prior to the party (which, being a birthday, is a date that is fixed).

We may find that the reason we need the application is to help us draw up the list of attendees first and this is why we need it 2 months prior.

However the other things that we need the application to do are not needed by that date and can be delivered a bit later.

Functions are needed at different times

A basic set might look like the above.

  1. Function to draw up a list of attendees – needed 2 months prior
  2. Function to create invitations and get them ready to mail – needed 6 weeks prior
  3. Function to order the ingredients and make the cake – needed 2 days prior
  4. Function to run the party (check in the guests) – needed on the birthday

By asking why a date is important, we have created a list of functions in order of priority – so that we can make an informed choice about delivery instead of trying to develop and deliver all of the functions at once.

We also have a great conversation about why each function is needed and what it will be used for.

People often set deadlines for good reasons, looking beyond and asking about those reasons is a great starting place.

 

 

Complicated Kanban?

Posted on by

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.

 

 

 

Goal Alignment

Posted on by

Ideally, a group put together from different areas would all be working on the same thing at any one time and towards the same goal. Often this is achieved in agile teams and works well.

Sometimes, there are other reasons to pull people together from different areas to work on several goals at once. Here is a way to get an idea about effective ways for groups like this to work together.

Examples of Goals

Ask the group to state their goals – in the example, the three goals are

  • Build Pyramids
  • Make Bricks
  • Destroy Pyramids

Put each goal across a page and also repeated down the left side – then ask for each pair of goals whether they align, conflict or are unconnected.

Goals GraphGoals Map

In this example

  • The goals of building pyramids and making bricks are aligned (and actually have a dependency).
  • The goals of building pyramids and destroying pyramids are conflicting
  • The goals of making bricks and destroying pyramids are unconnected

If we had a group put together with a goal map like this, we would need have discussions about the conflict and dependency so that we could work out the best way to start working together. In fact, we might ask why the people with the ‘destroy pyramids’ goal had been sent to this group in the first place.

 

 

Ladders

Posted on by

Thanks to an ‘off the cuff’ comment from @semanticwill about ladders of inference, I started to think about it a bit more deeply.

We each have a rich set of different experiences in our lives that make us who we are. When we make assumptions about statements that others make, we can ‘race’ up our ladders of inference – this can happen on both sides of the conversation.

Our Ladders of Inference are Uniquely Our Own

We are advised to ‘walk back down’ our ladders of inference when we make assumptions, but what I had not thought about much was that some ladders can be short and others long. So if I am working with someone else rung by rung to unpack our assumptions, I should not be surprised if one of us only goes a couple of steps and the other many more.

Causal Chains

Posted on by

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.

Causal Chains

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.

Approaches

Posted on by

There are many ways to improve the way we work.

Approaches

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.

Development and Large Structures

Posted on by

I have been wondering about the similarities and differences between software development and large building projects.

Building a Pyramid

Take the example of building a pyramid. We firstly gather some blocks, then mark out the shape and then place the blocks in the correct places to build the structure. Tasks need to happen in a certain order, we cannot place the blocks before we have gathered them.

If we are developing in a green-fields environment, which features we build first does not matter very much. We can use customer value and learning opportunities to determine the first features. So it is less similar to a large building project.

If we are developing in a brown-fields environment, then we often need to consider existing systems and features that our customers are already using. These factors may constrain the order that we can develop and deploy new features. So this is more similar to a large building project.

Consider the similarity between fixing a complicated system defect and brown-fields development. The order of developing and deploying fixes is extremely important to avoid causing further issues and rework.

Fixing Complicated Defects

In the above example there are four boxes representing applications and five interfaces. Root cause analysis shows defects in three applications and three interfaces.  The correct output can be restored when the six fixes are applied in the correct order.

Questions

  • Should brown-fields and green-fields developments be recognised as different?
  • Should brown-fields developments and production fixes be recognised as similar?
  • Why is development work treated as better than production support work?

Industry Migration to Complicated

Posted on by

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.

Obliquity

Posted on by

Thank you to Dave Snowden for his pointer to this John Kay post in a recent Cognitive Edge blog. It is a long read and I highly recommend making the time to read it.

Building on my recent post about the Gradient of Misinterpretation, we can be better off if we move indirectly towards a goal.

Many Paths to an Outcome

Here is my version of why obliquity can be good.

  • The first path taken is direct and leads us to our expected outcome of a box
  • The two middle paths lead to good and not-so-good outcomes, we are still looking for a box, and we find other things on the way that might be better
  • And the last path takes us under the mountain – sometimes other pathways are not so obvious

So how does this relate to the gradient of misinterpretation? It comes back to ambiguity, if we are a little ambiguous about what we want to achieve and how we describe it, then the pathways we take to understand it can take us to more interesting places.

 

Framework Examples

Posted on by

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