Collaboration and roles, learning from Rugby union

rugby

I keep on hearing team mates say things like

“it’s not my job to test, I am a <insert_role>” or “It’s not my job to design the product, I am a <insert_role>”

and I am quite tired of the behaviours caused by the message when left unchecked.

A team is more than the sum of its parts, a team has the power of collaboration.

When I was young I used to play Rugby (union).

Rugby union is a highly specialised sport, in fact the 15 players on the pitch are divided in 2 main silos, “forwards” and “backs” and within the silos there are these following roles:

Forwards: 1. Loose-head prop, 2. Hooker, 3. Tight-head prop, 4 and 5. Lock, 6. Flanker, 7. Wing Forward, 8. Number eight, 9. Scrum half

Backs: 10. Fly half, 11 and 14. Wing, 12. First centre, 13. Second centre, 15. Fullback

WOW 13 different roles for 15 people in the same team, more than the usual PO/BA/DEV/TEST/UX etc. we find in modern agile teams. How come they are able to collaborate so effectively?

The difference is that nobody in a rugby team will ever use a sentence of this type:

“I am not doing X because my role is Y”

In fact the very best rugby players are not the super specialists but the ones that are good at every different skill and activity required to play rugby. (Research the case of Brian O’Driscoll to me the synthesis of excellence in collaboration skills)

When there is a ruck 2 meters from a goal line you will see the ten stone (63Kg) Scrum Half stick his head in and push the 15+ stone (95Kg+) players away from his goal line.

He won’t say, I’m a scrum half I don’t do rucks, I guarantee 100% he won’t, because if he does he will lose the respect of his teammates, his coach and his fans and never play the game again.

Why do rugby players collaborate so well even though they are such a specialistic group? Because they have one clear goal, the clear goal is to score more points than the opponents. They all get that and do their utmost to help their teammates achieve it.

Why are agile teams not collaborating like rugby players?

One of the reasons is that they don’t see a common goal in the customer value to be delivered but see the beauty of the “elegant code”, “smart test strategy”, “beautiful solution”, outstanding “user experience” and so on.

So if you want to get your team to collaborate better together you got to give them a common cause to fight for. And just to save you time, it is not lines of code, story points, tests passed, number of bugs or lack there of, it is something bigger and more important.

Discover what it is together with your team.

 

Advertisements

Back to school at 49

In my efforts to help organisations gain business agility, I have through the years, tuned my approach continuously, using small experiments based on what I learned on the job, the people I spoke to, the books I read, the blog I visited and even the conferences I attended.

I have had thousands of teachers and I thank you all.

At the end of 2018 I sat down to retrospect on where I am on this journey and this is what I currently do when I work at a client.

chart

This is my current approach that is the result of years and years of small improvements.

For 2019 I want to do 2 things.

First of all I want to stop Telling people what to do completely, this in turn will free 10% of my time and I want to dedicate it to connecting with people on a personal level.

This is an area where I don’t feel completely confident and I fear I might be doing something wrong to the people I connect with.

For this reason I decided to go back to college and do an Advanced Diploma in Personal, Leadership and Executive Coaching.

I am very excited and proud to go back to school at the age of 49.

Wish me luck 🙂

How to build better products by betting small and keeping an eye on the race

The Grand National is a National Hunt horse race held annually at Aintree Racecourse in Liverpool, England. First run in 1839, it is a handicap steeplechase over 4 miles 514 yards with horses jumping 30 fences over two laps. It is the most valuable jump race in Europe, with a prize fund of £1 million in 2017 [1].

In the UK and Ireland, the Grand National is the most watched race of the year. It is an amazing spectacle to watch for the excitement, the fierce competition, the danger that comes with the massive fences and obviously to see if the horse we backed wins.

Every year, I put a small bet on one of the horses, but I don’t remember ever winning in my last 20 attempts. Predicting the winner on a field of 40 horses is not a simple matter, it is indeed very complex.

So many things can happen during the race that can throw even the most experienced and knowledgeable horserace expert. Among the things that happen during the race, changing weather and track conditions, the form in which the horse woke up in the morning, the training or lack thereof he had the week preceding, the horse in front of yours falling at the fence and bringing you down with him, the amount of drinks that the jockey had the night before, how distracted he might be from other thoughts in his head, after all his wife is divorcing him, the effect that the noise from the crowd has on your horse, and just about another million random events that could happen in those 5 minutes of racing.

Predicting a winner among the 40 participants is hard

But what if we could bet while the race has already started? Would that help us with our prediction?Well, yes. We could discard the horses that have fallen at the first fence, the unseated ones and the ones that have fallen too much behind.

That’s interesting, does that mean that now our chance of backing the right horse has increased?

Yes indeed and this does not only work for horse racing, it works for product development and innovation too.

Let’s imagine an organisation with €1M budget. Based on their understanding of the market they decide to invest the full budget into delivering “my shiny project” that again according to their understanding of the market will give them a return on investment when finished of €10M.

In gambling terms they are making a $1M bet on the “my shiny project” horse at 9/1 odds.

So what do they do? They use the €1M for assembling a team getting them the necessary resources to get the work done and do the work to deliver the project. While they are delivering, the race is on, but they are not watching it, they are busy building the project. Once they are done, only then they will know if their bet was a winning one.

If things go well, they might even get better odds as return, they might make $100M instead of 10, but history has thought us that this happens only in statistically negligible cases, while most of the time the result is that we have lost most of our money if not all of it. There are more fallers than winners at the Grand National year after year; and indeed there are more losers than winners, in fact on a field of 40, 39 lose, and one wins.

What can we do to help our organisation win the bet? Is there a possible approach that gives us the edge over other companies?

Oh yes, there are ways to help you win the race, let’s look at one example.

We take our €1M budget and allocate 9% of it to bet on the product we believe will win based on our understanding of the market and we pay an extra 1% to watch the race.

How do we watch the race? We invest 1% of our budget in tracking how our customers use our product with the intent of understanding what our customer really needs.

This would equate to spending €90k on betting on one horse and €10k on a live stream of the race we are betting on.

bets
Don’t bet all your money when you have the least amount of information

 

While we are watching we find out that our original horse has fallen at the first fence, and we also observe that another horse, we never thought could be the winner, is jumping very well and is at the centre of the leading group, a very good strategic position.

Then obviously we decide to invest another €90k betting on that horse and another €10k to keep on watching the race.

risk
Gain an unfair advantage against your competitors by watching how your customers behave and limit the risk of your bets

You can clearly see where I am going with this analogy. By limiting the risk of the initial bet and investing in observability I am gaining a clear advantage on the people that made their big bet before the start of the race.

 

In product development we can do this by making sure we create customer observability in our product to have a live stream view of the customer behaviours that informs our future bets.

Sources:

[1] https://en.wikipedia.org/wiki/Grand_National

What can Product Development learn from our body temperature regulating system?

Systems are all around us, and inside us. Understanding the systems we live and work in is fundamental if we want to navigate the problems that they carry.

Let’s think about our body as a system. It is a pretty complex and advanced one as it went through millions of years of evolution to get to the current state. Its working is truly fascinating and even though we have been studying it for millennia, there are parts that we still don’t fully understand.

Our body, as all systems, contains feedback loops. One we are very familiar with, is our body temperature regulating system. In order for our body to work well, its temperature needs to be between 36.5 and 37.5 degrees Celsius. In extreme circumstances, if it goes under 25 degrees we can die and a rising body temperature can damage our organs very quickly.

How do we make sure that this doesn’t happen without a thermometer that measures our temperature constantly?

Our body has a very sophisticated yet simple feedback loop system that allows us to regulate the temperature to the optimal range. In fact if we go out naked in the snow, we immediately feel a cold sensation, decide to get back into the house to put on some heavy clothes and then go out again. If we are running or exercising for a prolonged period of time and our temperature raises, our system will automatically start sweating to reduce and regulate it to its optimal range.

body temperature
This in Systems Thinking terms is called a balancing feedback loop.

What happens every day of our life is that our body temperature will oscillate within a range of acceptable temperatures because, through evolution, it has designed a defence system based on fast feedback loops. By continuously knowing when it’s too hot or too cold we are guaranteed we won’t die frozen or for too much heat. A slower feedback might have caused our body to freeze, imagine for example if we felt the cold only after 24 hours in the snow, but a feedback loop fast enough prevents all that.

What a great system our body is. But even such a wonderfully evolved system has its Achilles heel, in fact it can be damaged by slow feedback loops.

Let’s think for example about the effects of smoking tobacco on our body. How come we only recently found out that smoking is so dangerous for our body? Why did it take so long?

When we smoke our first cigarette, chemicals such as tar and formaldehyde penetrate the cells in the lung tissue and change them. At first our body may be able to repair the damage. With repeated exposure, normal cells that line our lungs are increasingly damaged. Over time, the damage causes cells to act abnormally and eventually cancer may develop.

The problem is in the fact that the time that will take for the cancer to develop is so long that only recently we could only start hypothesising tobacco smoke was a potential cause. You can easily imagine why. In ~30 years our body absorbs an incredible amount of chemicals coming from all sources, the food we eat, the air we breathe and the tobacco smoke we inhale. How could we have guessed? It was very difficult and only through data driven medical studies we managed to identify a clear link between tobacco smoke and cancer.

tobacco smoke
Slow feedback loop

Tobacco smoking is a very recent habit in human history if we consider humans evolution and our body has not yet developed a defence from it. What happens unfortunately is that our body will alert us of the cancer (feedback loop) only when it has damaged one of our organs. At that point, unfortunately, it is often too late to repair the damage.

A slow feedback loop can often look like the this picture. No impact for a long period of time, then a massive impact all of a sudden.

Slow feedback loops are everywhere around us, look at how some policies that seemed harmless at first sight, have caused migrations, desertification and destruction, years after, look at how the excess co2 in the atmosphere is damaging our planet slowly but nevertheless unequivocally.

Not being able to predict the effects of policies and changes to a system is troubling, but how does this fit with modern organisations and product development?

The link is in the feedback loops. We have seen earlier how the fast feedback built in our body temperature regulating system has helped our body defend itself from changes in temperature for millions of years, can we learn something from it?

A system that oscillates within a healthy range, like our body temperature, is a balanced and healthy system. What produces the healthy oscillation is the speed at which the feedback is delivered. Our body senses the changes in temperature very quickly and allows for regulating it in a way that appears to us to be continuous.

Now let’s think about organisations that rather than regulate their own temperature are trying to achieve an outcome.

Let’s look at product development for example.

Traditional organisations spend quite a lot of time studying the market to identify new solutions or products that can help them achieve an outcome. This work is often done by internal experts. Such experts have been involved in delivering previous products and are naively expected to have the wisdom that is required to design the product that will achieve the goal.

A lot of work happens inside the organisation and a lot of time passes before the new product is given to the customers. The more time the idea stays within the organisation the more we build assumptions upon assumptions instead of satisfying real customer needs. After one year or two we finally have a new product on the market, but very often we realise that the outcome we had originally thought we would get is not materialising. We often are very far from the expected outcome. We are objectively surprised, sometimes astonished at the results.

Our plan didn’t survive contact with reality.

Reality indeed, this is the first time we get feedback from our customers and it’s not what we thought it would be.

waterfall
Effect of slow feedback loops in Product Development

 

Organisations rarely understand the cause of the problem and often an unsuccessful product causes blame games. Everybody is to blame, excluding the people that designed the product. “The market has changed!”, “The latest regulatory policy makes it more difficult to use!”, “The downturn of the economy killed us!” Et cetera. I even heard leaders blame the customers, saying things like “they don’t understand!”

Slow feedback loops for product development cause something like this picture. The delta can be very big in the presence of slow feedback loops.

What can we do to avoid the truly sobering experience of showing our customers the fruit of years of our work and seeing it rejected? Well, we can’t avoid it completely but we can make it much less painful if we introduce a balancing feedback loop like the one

fastfeedback
Fast feedback loops in Product Development

that regulates our body temperature. 

The first thing to do is to identify an outcome we want to reach over time. This outcome is for us now the ideal body temperature we want to maintain.

The second thing we need to do is to plan regular and frequent feedback loops with our customer to verify directly in the real world how we are doing against the outcome.

The third thing is to measure how we are doing against the outcome and design the next bit of functionality taking in consideration the learning from the last feedback loop.

A fast feedback loop on product development causes a behaviour like the one in the picture.

By doing this we make sure not to diverge too much from our desired outcome. We know that we will make bad decisions that might move us further away from reaching it, but we also know that through frequent feedback loops we will be able to discover our mistakes early and take actions to repair them in a cost effective way.

It looks like we can learn a lot from our body temperature regulating system and treat our customers like our body regulates our temperature, with care and continuously.

How to maximise the work not done

Recently, due to a new exciting engagement, I have been thinking a lot about simple ways to explain the advantages of iterative incremental delivery over big bang releases. When speaking to C-level executives, coaches like me often have very little time, so we need to be able to engage with language they understand to make those few minutes count.

Money and impact on revenue seems to be a topic that is widely understood and accepted, so I have used and will use it during those conversations. My recent musings have brought me to a place where there is a currency that for modern organisations might be more important than revenue itself. Knowledge.

Now, let me expose differences between iterative incremental delivery and bing bang releases in terms of revenue and of knowledge.

Let’s start with revenue.

This picture is probably familiar to most of the agile/lean coaches out there and it is a good one to start the conversation on why releasing often while monitoring our customers behaviours has an immediate positive effect

revenue

From the picture is clear that incremental delivery has an earlier return on investment, while for big bang we have to wait until time t1 to get any return.

This is quite powerful but I don’t think it tells the full story.

Can we express the differences in term of something else?

To look at other aspects of the full story, we need to start visualising a different dimension than the usual revenue or $.

This new dimension is the currency of modern organisations, and it is called knowledge.

Let’s look at what happens with knowledge in a big bang delivery approach:

bigbang

At the start of envisioning and planning we start building knowledge about what the customer wants but at the same time, being humans and fallible, we start building wrong assumptions about it. We will get full knowledge (wisdom) only after the release date t1. At that point we will be able to validate our assumptions and will build the knowledge about what the customer really wants. Isn’t it a bit too late?

Now let’s look at the same dimensions for an incremental iterative delivery

incremental

As we can see, even in our iterative incremental world we build up wrong assumptions about what the customer wants, the difference is that we disprove them very quickly by delivering early and validating them through customer behaviour. This reduces the risk of building assumptions over wrong assumptions but most of all frees our mind to look at how the customer behaves using our product and understand it better. As you can see the assumptions get eliminated and rebuilt often but the knowledge grows continuously. This is very different from our previous graph, what happens if we overlay the two is the following

Maximising the amount of work not done

Every time we deliver a small increment we must ask ourselves 2 questions:

  1. Have we satisfied our customer needs?
  2. Do we still need to do more to satisfy them?

worknotdone

Given K the point at which we can answer one of the 2 questions with a NO then a decision that impacts on the amount of work to be done can be made.

Case A: If at point K i have enough knowledge to decide that I have done enough to satisfy the customer and any other added work will have diminishing return on investment, I can decide to stop.

Case B: It at point K I have enough knowledge to decide that the customers aren’t happy with the product and I am losing revenue, I can decide to stop.

In cases A and B the red area is the work not done as a consequence of my decision. Such decision could not be taken with the knowledge gained with a big bang release if not AFTER the release and all the work had been done.

So, in conclusion, you should use iterative incremental delivery to maximise the amount of work not done. This way, you will save money on work not done, will have the opportunity to spend that money on something your customers really want, obviously through iterative incremental and knowledge seeking delivery.

From Consulting to Coaching, what’s the difference for the client?

“An expert is a man who has made all the mistakes which can be made, in a narrow field.” Niels Bohr

In order to resolve complex problems, organisations often hire experts for help.

When I am such expert, very early in the engagement I explain how I can help resolve the problem they have in a few different ways.

What I tell them is that I can provide my service at three different levels:

  1. Coaching, where I help the people i coach ask the right questions, find the answers within themselves and resolve the problem.
  2. Mentoring, where I use a combination of coaching, training and also offer some options that might help resolve the problem .
  3. Consulting, where I either solve the problem as individual contributor (doing) or give instructions in order to solve the problem (telling)

The idea is that the paying client will decide what service level he requires, but the decision is not very straight forward if I only provide the three definitions above.

Lately I have found useful using a new approach (new to me) to help my clients make the right choice. With this approach, I show the impact of each of the different levels of service on “things” paying clients care about.

I use three simple visualisations, if you think they can help you, feel free to use them. If you have another interesting visualisation you found useful, please share it with me.

Future dependence on my service

Dependence

Through this view the client will be able to see how one approach is going to create a dependence on my service to be continued in the future, while the opposite is going to remove completely the need for my service. This is useful for clients to verify what fits better with their long term strategy on dealing with problems similar to the ones I am helping resolve.

Time to Resolution:

TimetoResolution

Through this view I highlight the impact of the approach on the time that it will take to resolve the problem I have been hired for. This will help the customer make a decision based on the urgency of the problem. The more urgent the more to the left we will go.

Resistance to Change

ResistancetoChange

This view in my opinion is extremely important because it is not always obvious to my clients but has massive impact on the organisation’s ability to deal with the result of my work.

If I am a specialist working on my own (doing) i won’t have any resistance as I am the one that is changing to resolve the problem. If I have to tell other people how to change to resolve a problem by giving instructions (telling) I am very likely going to be told “go away!”. If I exercise power to apply the change, things won’t be much better as people will do what I say but on a spectrum from unhappy compliant to angry saboteur. If I help people find the right way to change for the better, I will acquire many allies that will be invested in making change happen and most importantly sustain it in the long run.

Are we shifting left or in a continuous loop?

leftI just read a refreshing point of view on a subject I love, from one of my testing heroes, Janet Gregory.

Before proceeding, please take your time to read her point of view.

I use it

I have been using the Shift Left and even Shift Right terminology, as we say in Dublin, for donkeys years. I am not sure who I heard it from, I seem to vaguely recall a conversation with Gojko Adzic, or was it Dan North? I am getting more and more forgetful, whomever I pick I am very likely wrong, so forget about where i heard it from. and let’s move on.

I love it, it’s leaner!

I have to say I love Shift Left, it has helped me and my teams understand where we needed to take our attention to. In my mind it was never only about redistributing testing activities, but it brought great emphasis on prevention over detection, going towards a leaner testing, some people like to call #NoTesting.

I am all for prevention and I was always going to end up with the Shift Left party.

I understand

Now, reading what Janet says, I understand perfectly where she is coming from and there is no denying that the continuous infinity loops models describe the new reality much better than Shift + direction does.

Was it always like this?

Software development today is certainly non linear 100% agree.

Now correct me if I am wrong here, but waterfall is linear.

The water goes in one direction and there is no going back unless we are on some planet with different gravitational laws, which would be pretty cool to see now that i think about it 🙂

The key is “what” are you shifting from?

My take is that, maybe, in the early days, testers suffering with a bad waterfall hungover, would have understood Shift Left with more ease than if presented with the new continuous models (that in fact, didn’t exist yet).

We are improving

Think about being a waterfall tester in the mid late 200x. You are in a room and I talk to you about how to think and use Shift left. Somebody else maybe Janet, talks to you of either of the (excellent) continuous models we have today. What do you reckon you are going to do next?

If I had to guess, I’d say you’d Shift left. It is easier to understand if all you know is waterfall.

There is a left, a right and a centre in waterfall and people get it when you ask them to go left.

It was the first step to move from waterfall to agile, at least for me.

I see the continuous models as the reflection of the growing maturity of modern testers.

We are ready

We are now ready, bring the new continuous models on and let’s leave the shifting to rally drivers.

The models are good now, because testers are ready to understand, embrace and apply them.

Janet, thank you so much for making me think!