In today’s connected world, we are continuously witnessing or being directly part of conversations where there are two positions/ideas defended. Usually it is one side that supports “A” as the good option and the other that supports “B”.
These conversations become quickly polarising and even though A and B have a lot in common, what the 2 parts focus is on the differences and for the first section it would be something like “B includes X that is terrible because blah blah blah” and on the other hand somebody will respond “Well, A also says Y hence it is wrong because blah blah blah”.
If you are a twitter user you will know exactly what i’m talking about, if you’re not I’m sure you can relate it to live conversations you have had in your life.
One thing that these conversations have in common is that they never bring anybody to any sort of agreement. Focussing on what’s wrong in somebody’s idea is the easiest way of making an enemy. All we hear is “you’re wrong” and as humans that carry an ego, this is the worst way of starting a conversation.
Twitter and social media can be turned off, conversations muted at cetera so we have a safe place to go when something becomes too much for us.
A place we cannot escape as easily as that is our workplace.
Leaders have a big role to play in creating an environment where polarising conversations don’t happen and a search for the beauty in our interlocutor’s ideas is part of how we communicate.
My experience with leadership on this context is quite disappointing. A lot of leaders I have worked with consider being right the most important thing and will do anything it takes to make sure nobody proves them wrong. I can’t start to say how bad this is for the people that work with this type of leaders. Beyond not being listened to as soon as the leader has something to object, people quickly decide not to talk about what they believe in. This obviously causes the loss of perspective coming from these people and quickly the team becomes an impersonation of the leader and his ideas, some supporters (we won’t dwell on the reasons for support here) some compliant silent members and the ones that comply but deep inside would want to tear their skin off every time the leader talks.
A leader of this type will never create an environment that foster innovation and free thinking and the team will be as good as the leader, no more, no less. People won’t feel motivated to follow a purpose because it is not their purpose, it’s their leader’s and the team will be at best unhappy.
Some leaders consider this simply a side effect of the fact that they are more experienced, hence more likely to be right and don’t see the impact on their people. Furthermore, when polarising conversations happen within the members of their teams they often use the same approach, choose one side and demolish the other, nothing better if you not only want to diminish the innovative power of your team but you also want to ruin the relationships between the people that work in your team.
And many leaders are really good at it.
Is creating good relationships something as important as delivering the next piece of work in time? Less important, equally important, more important?
To finish I want to ask leaders two potentially uncomfortable questions.
Do you understand the impact of your conversation style on the relationships you have with your team?
What do you do to improve the relationship between you and your people?
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.
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.
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.
Most of us involved in software development are familiar with the term “technical debt”.
As a quick reminder, it was introduced by Ward Cunningham to describe the phenomenon that occurs when we use code that is easy to implement in the short run instead of applying the best overall solution we have identified.
It is by definition a conscious decision to take a shortcut for short term gratification (like taking out a new credit card for a holiday) that in thew long term will cost us to spend extra time in development when improving the system (like paying interest on the credit card debt).
Until the capital is repaid in full we will always pay interest when adding features to the system as the debt creates obstacle to adding new code efficiently.
Ward suggests that when we are in a situation of rushing something out we need to be conscious that we will have to pay the capital in the future or the interests will cripple us.
Ward suggests refactoring as a solution to paying off technical debt.
I really like Ward’s vision and I want to expand the metaphor one level up.
Now if we change the word “software” in my description of technical debt above with “processe” we can define Process Debt.
Replacing we get:
Process Debt is the phenomenon that occurs when we use a processes that is easy to implement in the short run instead of applying the best overall solution we have identified.
Let’s look at one example
You notice that lately the system seems to be more unstable than usual. You know this because there are more calls from customer care and more defects get raised.
Option 1: You want to get to the bottom of the situation and believe that a root cause analysis with 5 whys could get you there. If you use this approach you will probably identify a change in your process to help you prevent some defects in the future.
Option 2: You implement a better policy for developers to select the defects to work on reducing the time the defects are in the unresolved queue while maintaining new features creation throughput relatively stable.
You know Option 1 is better in the long run because it will generate a change in the process to reduce the amount of rework. This will mean less time spent fixing and more time spent on new features that as a consequence means higher throughput and lower lead time for new features.
Option 1 requires some investment. You need to hold one or more root cause analysis sessions, identify the problem(s) experiment with solutions until you find a solution that mitigates your problem.
If you are under pressure, because the new product needs shipping and the old defects need fixing, you are likely to choose option 2.
By doing this you have introduced process debt
The capital of this debt is the lack of change in the process you could have identified if using Option 1.
Oh, yes, I forgot, change is difficult.
The worst part of it is the interest on the debt you will pay forever until you pay the capital. This interest will appear in the form of.
1. bugs keep on coming, we seem to be fixing bugs all the time
2. new features get delayed because now the queue is in the new features to be delivered
3. the lead time of any new feature is expanded by a factor X
4. the customers continue on complaining because of your defects in production
5. your product owner starts being annoyed at the amount of work spent by the development team on defects
6. developers are tired of always fixing defects
n. need I say more?
This interest will be paid for the rest of your life if you don’t fix the problem.
Months after you are covered in defects, are stressed by your customers and change job.
Is this healthy? Certainly not.
Is there a cure? Oh yes, indeed.
Continuous improvement has the same effect on process that refactoring has on software. It repays the capital of your process debt.
With small changes in the form of experiments you will be able to clearly discuss the problem that the team is having and make small tweaks continuously.
My esteemed colleague and fervid innovator Claudio Perrone presents his continuous improvement model called PopcornFlow saying
If change is hard, make it continuous
I could not agree more.
By making process change a continuous activity, we enable behaviours that will stay with teams forever and we unleash the power of people’s creativity in improving their own way of working.