Author Archives: kb2bkb

Learning in the Cynefin Domains

Posted on by

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.

Scope

Posted on by

Is it better to start with a large scope and reduce it, or start with a small scope and increase it?

Argue Scope Out

It seems easier to start with the full idea – everything that we want – often this ends up costing more than we have and taking longer than we want.

So we do more work to come up with options in order to deliver something in the time-frame and for the money we have – so many decisions.

These can be hard to explain to the decision-makers and stakeholders and results in a lot of frustration, unmet expectations and further delays before we even start the work.

Argue Scope In

Here we start with the Minimum Viable Product, the smallest part of the idea that can provide learning and/or value.  If this cannot be done in the time-frame or for the money we have – then stop now.

The conversations we have about adding scope to the work are about the solid reasons to add it and about the cost and time-frame impacts.  Each piece of scope added is carefully considered before it is agreed to be added.

Any changes to costs and time-frames are much easier to explain to our stakeholders and decision-makers.  The conversations are more positive and productive, decisions are clearer and we can get on with doing valuable work more quickly.

Stop Signs

Posted on by

Knowing when to stop is important, and sometimes it is easier than others to pick up the signs.  It depends on our focus.

Focus on Outcomes

When we understand why we use the principles of agile and lean, and we remain focused on the outcomes it is easier to see when to stop.

  •  When our fast feedback loops inform us that we are building the wrong thing
  • When our first release to the market does not delight our customers as expected
  • When we thought it might take 2 iterations to build and discover we are not even halfway through after 1 iteration

Focus on Method

Sometimes we think that if we follow a process perfectly, then we will always get a good outcome – this obscures the stop signs.  Methods are good – but should not be our focus.

  • Methods give us a shared context and language so that it is easier for us to work together
  • Methods help to provide regularity, this can give us measures that we can use to observe impacts – but do not use them as targets because they will be gamed

Focus on Speed

This focus will help us to miss most of the stop signs because we are only observing how fast we are going.

Innovation and Misinterpretation

Posted on by

Misinterpreting something is often seen as a  bad thing – there is another way to look at it.

It is not possible to know for cetain if we have understood another point of view fully, because we are ourselves and not someone else – so there is always some degree of misinterpretation.  The other extreme is when we get something wrong such as interpreting a red traffic light as ‘go’.  The gradient of states in between could look something like this.

The Gradient of Misinterpretation

Between shared understanding and embarrassment lies the potential for innovation and new ideas.  This is one aspect of what we are trying to leverage when we use brainstorming – someone says one thing that helps us to think of something else.  It also works well on Twitter – the text limit forms a constraint that limits shared understanding.  If we can avoid going too close to embarrassment and wrong, we get a fertile field for new ideas.

 

Why do we Estimate?

Posted on by

The first question we naturally ask when we have an idea is ‘How much will it cost?’

The main reason we do this is in order to make a decision about whether to proceed with the idea or not.

Asking the question this way will often result in a lot of work in many delivery teams, understanding the idea and then estimating how much it will cost to develop.  By the time we have done all this work it is as if we have started the project already – so we can find it very hard to stop.

It is more useful to ask ‘How much are we prepared to spend on this idea?’  A good way to do this is to use the IRACIS template and ask ourselves about the goals and drivers for this idea.  For each goal or driver, capture the item into the most appropriate box – does it Increase Revenue, Avoid Costs or Increase Service to our customers?

Next we look at the metrics and measures we would use to determine if each of the goals and drivers were met.  Would we count the number of sales? Would we look for a drop in complaints?  Could we reduce or delay investment? ….and so on…….

The next question is ‘With all of these benefits, how much should we be prepared to spend in order to meet these goals?’

This can be very hard to answer in a work context – but we do it all the time in our home lives.  For example, if I want to buy bananas, I already know how much I am prepared to spend.  If they are more than I have budgeted for, then I do not buy them.

Once we have the amount that we are prepared to spend, there are many light workshop techniques we can use to get an idea of the work involved in the solution and whether we think it is possible to build for the desired spend.

Back to the reason for estimation – to make a decision about whether to proceed or not with the idea.  If we estimate that we can build the solution for the desired spend, then let’s continue with the idea.

If not, then stop and spend no further effort on it.

Deadlines

Posted on by

Thank you to Jabe Bloom (@Cyetain) for inspiring this post with his submission for Lean Kanban Netherlands 2012

What is a deadline?  Let us start with it being a demand for delivery of something by a certain date.

I think that demand for delivery by a deadline is really a couple of different things.

  1. ‘Real’ dates. These are for things that will not move such as the start of an event or a holiday special.  These are true deadlines in that the item will have no value if it is delivered after this date.  We don’t get these very often.
  2. Dependencies.  These need to be worked with as true dependencies, then when things move around, we can see what else has been impacted.  They can be a bit hard to pick up sometimes and we need to ask questions to get enough understanding from the person requesting delivey by a certain date to pick up that it is really a dependency.  We have lots of these.
A couple of examples of dependency dates
  • Benefit dependencies. Where the business model states that we will start getting benefits from a certain date.  Many people will not see these as dependencies and will treat them as deadlines.  Identifying the key influential people and having discussions with them to fully understand the dependency is important so that we can all drive to the same goals.
  • Downstream activities dependencies. These include training, marketing and so on. Our teams need to include these groups as part of the build. When we find that we are going too fast we need to extend the concept of working on smaller and more valuable items to all involved groups. Then we can start to realise the benefits as soon as possible.

Update 25th September 2012

One of the reasons we may get pressure to meet a deadline is due to a misinterpreted dependency.  These can be identified when we call them critical dates, without also mentioning the dependencies that the dates are based upon.

Conversations with key people can help us to discover more about these dependencies.  They might be taken aback a little when you first start to ask about the reasons for the critical date, so be careful to explain why you are asking and empathise with the pressures that they are also under.

These concepts are ‘bread and butter’ for seasoned project delivery professionals. The key point is that most of the time we should be managing to dependencies and not to dates.