Many moons ago, my confidence was at its lowest. For a few years my leader had convinced me that I was worthless. I remember the feeling of hate I had for my job and at the same time how lucky I felt to have that job, because I was so useless that nobody in their right mind would give me another chance.
If you know me well and read this, you’re probably thinking that this is a fictional story, in fact I am an extremely (too much some say) confident person. But no, this is the truth, I was at my lowest and the reason was that my leader had bullied me into a ghost.
When, after years of pain, through the help of a colleague and the support of my friends I saw what was happening to me and realised the psychological violence I had been subjected to, I decided that leaving the company was not enough and I wanted to do the right thing by coming clean on what had happened.
I went to talk to my leader’s boss and explained what happened. By then I had an overwhelming amount of data that unequivocally proved that systematic psychological warfare had been used against me. Not only me for that matter, other people were receiving the same treatment.
My leader’s boss was very sympathetic and said that I was not the first one that reported that behaviour. He also ensured he was going to act upon my complaint.
Little I knew, he was playing a game. He delayed and delayed his intervention, once even faking that his flight had been cancelled on the day we were meant to meet Human Resources (I checked with the airport and no flights had been cancelled that morning). That Same day i had to go to a doctor, because my depression had reached a point in which I was unable to face going to work.
Eventually, tired, disappointed and broken, I decided to simply leave it as it was as I knew i was trapped between a bully and a spineless bully enabler.
That was that, i left and life went on.
Nobody loves a bully, bullies are massive problems for organisations, but worse than bullies are unhelpful knowing managers that by not acting and stopping the bullying perpetuate a culture that accepts it.
If people are afraid to talk about things, true leaders will investigate and find out why it is happening and when they find out that the problem is a bully, they will act promptly. If I found out that one of my people was a bully, i would try to help him trough coaching, and if it didn’t work I would have to defend the other people and the bully would have to go, no two ways about it.
When a leader does not act firmly, also sends a signal to his people that bullying is ok. When this happens, bullying becomes part of the organisational culture. Leaders, it is your responsibility to make that not happen.
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.
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.
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.
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 .
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.
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.
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.
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.
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 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.
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
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.
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
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:
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
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:
Have we satisfied our customer needs?
Do we still need to do more to satisfy them?
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.
“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:
Coaching, where I help the people i coach ask the right questions, find the answers within themselves and resolve the problem.
Mentoring, where I use a combination of coaching, training and also offer some options that might help resolve the problem .
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
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:
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
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.