Conflict, complexity and the use of language

In recent team meetings I’ve been involved in a lot of conversations that seem to quickly escalate into arguments based on a misunderstanding of the words we’re using. Words like intervention, disrespect and even something as simple as experiment are causing confusion within the group.

This got me thinking about how are use of language is shaped by the environment we’re in. Specifically which of the Cynefin domains your team is currently operating in.

In the Simple domain, use of language is not a problem. Everyone has a shared and deep understanding of the words used, their is no ambiguity. Plain speaking is all that is needed to get your point across.

Things require more care when you consider the other ordered domain. When you’re operating in the Complicated space you need experts. Experts tend to have their own very specific definitions for the words they use. So my proposal is that when working on an ordered, complicated problem then best to agree your use of language up front. Put together a glossary of terms, and if you involve more than one expert (as recommended) then ensure they are all talking the same language.

Now the more interesting space for me is when we operate in a Complex domain. Here I believe use of language needs ambiguity. The same idea needs expressing in multiple ways. The same words have multiple meaning. A group operating well in this environment, will be exploring the essence of what they are trying to communicate with a variety of means. As Dave Snowden often talks about in his blogs, parable, narrative, anecdotes and story are all tools at your disposal.

Finally when it comes to the Chaotic space, then I suspect we are back to plain speaking, keeping the concepts and communication methods straight forward and focused on what is being observed. Less is more, and listening becomes a great default position. I’m thinking about a fire-fighting or combat crew for ideas on how to handle this domain.

I’d love to hear about anyone’s thoughts or experience of how best to communicate in these different domains.

Posted in Agile, Complexity | Leave a comment

Things get interesting at the boundary.

Polish-Russian border line on the beach (by Wyksztalciuch)

I like the idea of boundaries. Once set they allow me to relax. The stuff outside a boundary “just is”, these constraints need understanding and exploring but there is no need for me to try and change them. So I found this joke (in Debt: The First 5,000 Years  by David Graeber) offered some interesting insight, it also brings forth fond memories of my mountain biking adventures in the Pyrannes which are hosted in Hondarribia/Hendaye on the French/Spanish border. 

There was a small town located along the frontier between Russia and Poland; no one was ever quite sure to which it belonged. One day an official treaty was signed and not long after, surveyors arrived to draw a border. Some villagers approached them where they had set up their equipment on a nearby hill. “So where are we, Russia or Poland?” “According to our calculations, your village now begins exactly thirty-seven meters into Poland.”
The villagers immediately began dancing for joy. “Why?” the surveyors asked. “What difference does it make?” “Don’t you know what this means?” they replied. “It means we’ll never have to endure another one of those terrible Russian winters!”

Boundaries are all well and good, but they are unlikely to be black and white. However it does reinforce another thought that is currently colouring my view of things. That is the really interesting stuff doesn’t happen in the middle, it happens at the margins, at the boundary.

Posted in Agile | Leave a comment

A software development motto

It may well be an urban myth but I understand the US Marines have a motto for when the shit begins to hit the fan

“Keep moving, stay in touch and head for the high ground.”

This got me thinking, when we hit a similar situation in software development is there a simple motto that can help. I was surprised how similar they might be with just two words changed and one added.

“Keep delivering, stay in touch and head for high value features.”

What I’m saying is, first don’t go dark, keep delivering code on a regular basis. If anything increase the cadence of delivery if things have got truly chaotic.

Then keep talking to everyone in the team and most importantly the business stakeholders, and finally keep the focus on what delivers the most value, if you follow the value this will ensure you head away from the danger zone and towards a place of more certainty.

References

Posted in Agile | Leave a comment

How to find a combined standard deviation of two groups of figures?

So I’ve got two groups of numbers, which I want to probabilistically add together. The question is how the variation found within each set will effect the variation in the combined sets.

Group 1 = 1,2,3,4
Average = 2.5
St. Dev. = 1.1180

And a 2nd smaller group made up of two numbers.

Group 2 = 7,8
Average = 7.5
St. Dev. = 0.5

This gives me a 3rd group of combined numbers.

Group 3 = (1+7), (2+7), (3+7), (4+7), (1+8), (2+8), (3+8), (4+8)
Group 3 = 8, 9, 10, 11, 9, 10, 11, 12
Average = (2.5+7.5) = 10
St. Dev. = 1.2247

So the question is how do I arrive at the standard deviation of the 3rd combined group using only the standard deviations of the simpler groups?

It turns out to be a very simple calculation, square the standard deviations, sum them together and then take the square root.

= SQRT(1.1180^2 + 0.5^2)
= SQRT(1.25 + .25)
= SQRT(1.5)
= 1.2247

So as long as my sets are independent then it is quite easy to find the combined variation. However as soon as their is any real link between the numbers, for example low numbers in the first set will lead to higher numbers in the 2nd set then the maths goes out the window.

Posted in Agile | Leave a comment

How do you know what to wear?

Measurement, especially when it comes to forecasting can cause a lot of stress and bad feeling in most organisations, that gives it a really bad name, but stopping measuring anything is also generally a bad idea. I wanted to use the idea of weather to explore what we can measure, why this can help us.

To set the context, we are now talking about complex systems. Not complicated and not chaotic. Complex systems can quickly fool us into thinking there is some method in their madness. We seek patterns and thanks to that cognitive bias we will find them. Let’s take the weather. Sayings such as “Red Sky at night, shepherd’s delight. Red sky in the morning, shepherd’s take warning.” have been around since biblical times, and while there is some science behind the rule it won’t work all the time.

I’ll rephrase the title of this blog slightly. How can we be effective in our choice of clothing to ensure we feel most comfortable throughout the day? Based on the information we know about the complex system called the weather, how can we make good decisions?

Well we don’t start by not measuring anything, that’s for sure. You’ll end up cold, wet or hot and sweaty most days.

We could make use of the historical information at hand, both our personal experience and that of the Meteorologists. These measures (rainfall, temperature, wind speed etc.) give us boundaries in which to operate. Averages with their deviation tell us that we should get our winter wardrobe out, or it is time to pack away the shorts and flip-flops. We then have our view of the current situation, who doesn’t look outside before deciding which coat to take or whether packing an umbrella today is a good idea?

But if we want to make sure we’re really comfortable, whatever the weather, then we’ll start playing with options (real options for ref.). We can use layers to give us control over temperature, a vest in the winter but an optional jumper. The umbrella mentioned above is a low cost solution to keeping dry. Gloves, scarfs and hats give us even more control when things get really icy.

So given this analogy, I think it is more generally acceptable to measure things in a complex system environment, just don’t try and forecast too far ahead and don’t try and read too much into the patterns you see, use this information to keep your options open, by doing so we can all reduce the level of stress and anxiety that will happen when you’re forecasting starts to go wrong.

Posted in Agile | Leave a comment

Value Driven – A Simple Context

I’ve been struggling with the idea of shifting a team’s focus away from activity and towards that of value based measures. However I’m finding it hard to articulate these ideas well. So I thought I’d build a simple fictional cased to try out these ideas and stimulate some discussion.

Imagine if you will our virtual development team is working within a small ecommerce company. They have little legacy code or backend logistics to worry about. Most days they can code, test, deploy pretty rapidly. There are no barriers between the development team and the business/marketing folks, in fact we can view them as one big happy family.

So I believe value is pretty simple in this context. Our costs are fixed. If the team stop work tomorrow, the website will continue to operate at the same level of sales. So the team delivers value by increasing sales.

Imagine the team currently has no work in progress. We’re in effect starting with clean sheet. So what do they do next?

The first thing the team need is some ideas. In our virtual space, I can’t see any other way for our team to get started. The developers might have ideas for improving site speed, marketing see opportunities with the latest social network integration, the usability guys have a step in the basket that they think can be improved and some suggestions from customers on twitter also get added to the list.

So we have our classic backlog of work. Given the way value is generated in this imaginary world, how should the team prioritise which ideas to attack first? There are going to be some simple, small tweaks, that are low risk but not particularly likely to introduce a step change in sales. There are also more audacious ideas, which the team think might make a massive improvement to the business but that come with a great deal of risk.

Now I’m beginning to get nervous for our fictional friends. It feels like the team could spend a whole chunk of time “analysing” the situation without adding value, this kind of waste is really bad and might result in analysis paralysis. However I’m also worried if they just want to “crack on” then they are more likely to favour the smaller less risky ideas, as these get people busy and start delivering some real value earlier (perhaps the classic agile mind-set) but then the large items will get ignored.

To help out our crew I’d like to find a quick (low cost) method of comparing two ideas. One low value and relatively risk free and the other high value and even higher risk. The low value item should be pretty straight forward, there is an estimated value with some level of uncertainty. For example we’re expecting our tweak to the basket process to have a 75% chance of delivering a 2% increase in sales. Whereas our big item, which involves integrating some new 3rd party mapping interface on the homepage only has a 25% chance of going right in which case it is likely to increase sales by 20%, but if it doesn’t work then we’re looking at a 10% decrease, as performance and usability of the homepage takes a dive. Of course these are all little better than guesses at this stage so no need to sweat about the numbers too much.

Worst

Best

Average

Idea 1

0% (25%)

+2% (75%)

1.5%

Idea 2

-10% (75%)

+20% (25%)

-2.5%

What our team needs is to create a 3rd idea. This work item is better called an experiment. It is designed to improve our understanding of the potential outcome of our big idea. This experiment needs to be totally safe to fail, and should be designed in such a way as to not impact sales either way. In other words it is 100% likely to deliver 0% increase in sales. So how can we assign value to this 3rd idea? The team need to focus on failing earlier, so should be exploring the reasons why this big idea might fail. In this case the potential performance problems the integration might cause. So they come up with an experiment which has a 50% chance of proving the performance issues and if successful will reduce the downside of our big idea to zero.

Worst Best

Best

Average

Idea 3

0% (50%)

0% (50%)

0%

Idea 2

0% (75%)

20% (25%)

5%

Idea 3+2

0% (37.5%)

20% (12.5%)

2.5%

By doing our experiment before we tackle the big idea, we’ve turned the estimated value from a negative to a positive, and given it a relative measure above that of the simple thing. Now the team know what to tackle next, the experiment first. If that is successful then the big idea.

So now let’s fast forward a few months. How can we best measure the effectiveness of our team?

Clearly the speed at which we can take an idea, commit to working on it and then measure the effect on sales is going to be important (classic cycle time). This will ensure the team remains agile and able to reprioritise the next item to work on quickly. Experiments are more interesting, it has been said the optimum success/failure rate for experiments is around 50%, at this level we are learning the most, and it may be good for our team to be able to prove that. Perhaps also the ratio of experiments to other work would be important, as it ensures the team can get the balance between low risk/low value items and our bigger value items. Finally throughput as measured in terms of increase in sales would be the most interesting measure and something the team can be sure will talk volumes to the business folk.

References

Posted in Agile | Leave a comment

It is hard to really know something

Thanks to @KevinObee I watched the Horizon documentary The Pleasure of Finding Things Out this morning. Being a Physics student, and having read many of his books, I always enjoy watching interviews of Richard, he has such a different view of the world. This morning I was particularly taken by this short section where he talks about “Science which is not science …”  (44 mins in).

You see, I have the advantage of having found out how hard it is to get to really know something, how careful you have to be about checking the experiments, how easy it is to make mistakes and fool yourself … I know what it means to know something, and therefore I see how they get their information and I can’t believe that they know it, they haven’t done the work necessary, haven’t done the checks necessary, haven’t done the care necessary.

Richard Feynman

I talk a lot at the moment about getting more scientific at work. I talk about avoiding opinion based decisions, do more research, use hypotheses and test those hypotheses with experiments. So I found myself humbled by this quote.

To apply the scientific method to the work clearly requires is going to be hard, in the future I clearly need to change my approach.

  • More time reading and applying the body of knowledge already out there.
  • Take the time to get to know my work better. More time spent as close to the work as possible.
  • More time to reflect on the work. The dynamics and interplay of complex adaptive systems are non-trivial.
  • Build better more rigorous experiments, that extend my knowledge of the system.
  • Watch for mistakes, dead ends and times when I’m fooling no-one especially myself.
  • Stop rushing and take more care, both in the process and with the people.

Has anyone else thought how to apply more rigorously scientific methods to a work (especially software)?

Posted in Agile | 4 Comments

10 things Business can learn from London 2012

Doing my research on this post it soon become apparent that I wasn’t the first to try and link Great Britain’s Olympic success with business, Mervyn King (Governor of the Bank of England) and political pundits from all sides have been jumping on the band wagon (so with with awareness of confirmation bias) I’ll attempt to do the same.

1. Have a clear vision

I know I’m starting with a quote from the Tour de France, but it still shows clearly what a single-minded, vision shared by the whole team can do to help get things done.

“I’d never have said that we could do it unless I really believed that we could. A lot of people laughed when we said that we could win this race in five years with a clean British rider. But we were serious about it, we’d done our homework, we knew what Bradley was capable of and what a British team would be capable of – and we set about it.”

Dave Brailsford

As Peter Senge says “It’s not what the vision is, it’s what the vision does.”.

2. Money won’t motivate

Even before the Australian swimming team had left for final preparations the sport’s executives changed the funding for swimmers to a high performance model. This meant swimmers would be paid a small base rate and a large fee if and only if they were successful.

Perhaps if the management team had taken some time to review Dan Pinks work on taking money off the table, and using purpose, mastery and autonomy to gain the results they so desired then the team wouldn’t have delivered its worst result in 20 years.

In the Team GB’s cycling team did just that, securing funding to pay competitors rather than having them train after work. This hasn’t been missed by those involved in the financial sector.

“Motivation is more than mere money. Bankers should concentrate on laying a solid foundation for customers, not focusing on making quick cash.”

Mervyn King

3. Think long term

Olympians can’t help but think long term, their chance to shine only happens once every 4 years and most of Team GB had 7 years to plan their approach to their home Olympics.

In business it is much harder, month and quarter targets are the norm, taking a longer term view is hard but imagine what could be done if organisations did this all the time.

4. Work bloody hard

Chris Hoy, trains 35 hours a week and dare not even walk to the shops as he is meant to be recovering for his next session. This kind of dedication sums up this rather overlooked learning, as does this paraphrased quote from Jason Kenny (team and individual sprint gold).

“Erm, I don’t know, hard work, I guess”

Jason Kenny

Too often in both the euphoria surrounding the Olympics and in creating high performance organisations this rather simple learning is over looked.

5. Don’t be afraid of tough decisions

During the 2012 Olympics the cycling team had some tough decisions to make with people like Andy Tennant, Wendy Houvenaghel and even Chris Hoy being pulled from races they desperately want to compete in.

“You’ve got to take the personal element out of it, look at the data and be professional,”

Dave Brailsford

I feel the same approach must be taken within business, too often decisions are made simply to avoid conflict and a hard conversation, when things should be kept focused on the reality of the situation.

6. Always learning

If there is one thing any team in any organisation can take from the success of Team GB it is their constant search for improvements.

“It’s all of it, the science, the training, the coaches, but most of all we point the mirror at ourselves and ask ‘how can we get better?'”

Chris Hoy

The same is surely true for organisations of all types.

7. Devil is in the detail

This is perhaps the most often quoted “secret sauce” behind the Team GB haul of medals in the Velodrome, whether it is how they wash their hands, which pillow they sleep on, how round their wheels are or spending hours in a wind tunnel.

“They’re tiny things but if you clump them together it makes a big difference.”

Dave Brailsford

Sometimes this attention to detail is lost in the rush to deliver results.

8. Training Partners Help

Having a training partner at the same level really helps.

  • Mo Farah and Galen Rupp
  • Usain Bolt and Yohan Blake
  • Bradley Wiggins and Chris Froome
  • Alistair and Jonathan Brownlee

I can see the parallels with XP style Pair Programming, the principle behind it can be applied to more roles than just coding.

9. Everyone needs a therapist

Steve Peters [the psychologist Brailsford brought in to help his riders just before the Athens Olympics] Other key staff include sports psychologist Steve Peters, described by Brailsford as “the best appointment I’ve made”. He has helped riders control and eliminate irrational thoughts.

Foreign coaches like Jan van Eijden and Shane Sutton are here because they enjoy it. Success begets success.

Head coach Shane Hutton, a Commonwealth Games gold medallist, acts as a mentor for other coaches.

10. Measure the right things

As the Australian Swimming team found out, judging success by position doesn’t work too well. Instead keep the goals within the boundaries of the team or individuals control.

“If you look at your own performance and think, ‘Am I happy with that? Is that the best ride I could have done?’ And the answer’s yes, then you can look at everybody else and see if they went faster. That’s how I look at it.”

Dave Brailsford

Too often organisations set unrealistic goals that de-motivate and cause serious systemic problems. Teams should be asking, am I being as effective as possible.

References

Posted in Agile | Leave a comment