Sometimes there is a woman

Our world disappoints me in many aspects. I fail to deal in an orderly manner with law and regulation when it impacts my ability to be free and let my mind fly.

I can’t deal with capitalism, i am poor at dealing with low empathy people, I am only starting to learn how to forgive the people that hurt me.

But then sometimes there is a woman, that makes the learning and pain worth it.

A woman that, on her own, decided to leave it all behind to go up in the Alps to run a 18th century built hotel, restaurant, pub in a 17th century sanctuary. She got beaten up by COVID-19 that forced her to close off her business, she raised up and called for help, she called me and she helped me deal with my demons of the past.

Sometimes there is a woman that is worth worshipping for the rest of my life.

Promise: I will never ask you for a CV

Over the years i have applied for many jobs, sent many CVs. I have also read many CVs and hired hundreds of people. That’s it I’m done with it.

Working with somebody is a very important human relationship, I am not going to ask you to describe yourself on a piece of paper because i am too lazy to take my time to know you.

Not only i am too lazy to get to meet you all, I also am so arrogant that i expect you will want to work for me. This is ridiculous. Why would i assume that you want to work with me without meeting me first?

Is it because i offer you a salary?

Well if that’s the only reason you want to work with me, then i might not want to work with you in the first place.

I’m done with CV’s. Keep an eye for job postings where i invite you ALL to meet me for a stroll on the beach, for a drink in a pub, for a meal in a restaurant, for a walk in the park.

If you think you want to, come over, let’s meet and see what we can do for each other.

Dear leader: can trust be earned? Should trust be given?

Over the years I have spoken to hundreds if not thousands of leaders and there is a fundamental aspect that differentiates them and their effectiveness: how they handle trust

Category 1 – The Micro Manager: “Trust must be earned, I am not giving trust to people that i just hired, they need to earn it”

Category 2 – The Servant Leader “I trust my employees, until i don’t trust them anymore”

It goes without saying that leaders in Category 1 suffer because they are always checking on their employees due to lack of trust. They become swamped and slow down their people and organisation with their obsession for checking work done by others.

Category 2 leaders get the full strength of their teams by allowing them to make mistakes. This can only happen when people are trusted.

I have met some inspirational category 2 leaders, if you are reading this one you know who you are.

I have also met many Category 1 leaders and if you are reading this I am really sorry you tied yourself into a knot because you can’t trust your people, maybe a non leading role is better suited for you.

But i love you both regardless and i will help both regardless if you hire me

The sunrise and the Indian Girl’s gift

Once upon a time there was a business consultant that travelled the world every day of every week of every year to follow his path.

When he was young, he loved travelling, but after over 10 years of that routine, he started to even finding the thought of yet another check in queue, delayed flight, angry passenger and 3 am alarms going off disturbing.

That morning his heart was serene, he was going to his favorite destination of them all. He was flying from Dublin to Europe. The destination he liked was not a specific country, it was an experience that he still loved after so many years. When he travelled to mainland Europe, he knew that if the flight was early enough, he would have met the sunrise over the left of his plane keeping him company for those magic minutes, when from darkness, a small speck of light appears to become a soft halo before exploding into a red ball of fire that colours the skies in front of any attentive left window plane passenger.

He craved that feeling every time, it seemed it was the only thing that kept him doing that job he didn’t love anymore and those trips he was starting to hate.

That morning he walked on the plane at 5:20 am full of excitement and anticipation for yet another unparalleled show of beauty, another sunrise from a flying plane, his job’s most loved perk.

When he walked to his window seat, he saw a young Indian girl sitting on his same row on the aisle side. There was something in her eyes that suggested sadness and unrest and he thought, “let me help her, she needs the sunrise more than me” and told the girl “good morning, I am on the window seat, but if you prefer it to your seat feel free to swap with me.”

The girl nodded and with a little smile she moved to the window and thanked him.

He knew what was going to happen soon, and the thought made his heart warm a bit. Wasn’t it beautiful to be able to donate a sunrise to a sad girl to brighten her eyes? He thought that the gesture was romantic and rejoyed of it.

He sat and waited.

The girl appeared to being nervous and alternating from reading something on her phone to look ito a copybook to find something to change in what she had probably written before. She was in pain, he didn’t know what it was but he could see some it.

And then it happened.

From a corner of her eyes, the beautiful red shades of the sunrise distracted her from the mobile phone. She looked up and her eyes were captured. He could see her attention had shot open and her sadness disappeared. Soon after she started taking pictures with her phone to try to capture that eternal beauty, that, for the first time, had met her sight on a plane.

She was happy like a little girl playing in the Indian sun he thought, and his heart was filled with joy for the fact that a little gesture of love had made her forget her reason to be sad. It was pure joy, he thought that he was seeing the sunrise he’d given up for her in her eyes, he was content.

With so much love in his heart he decided to send her a message, to be understood either now or one day in the future, so he turned to her and said “Did you like my beautiful present?”

He was taken aback when he saw that the girl’s eyes were now filled with sadness again. Did he distract her from the beauty of the sun back to her sadness? The thought terrified him. He had spoiled the moment he had helped create and he felt like shit.

She went back to taking pictures of the sun, he let her, because her eyes were newly happy, he would not risk destroying them again.

And then it hit him. He could give more love, a love without a trace of self, a true generous love so he went ahead and did it.

He said to the girl: “do you mind taking a couple of pictures of that beautiful sunrise for me?”. She didn’t hesitate this time and with a smile she reached for his phone. She took it and started pointing it to the sun, making sure she found the right angle and the right timing to try to show the devastating beauty of that sunrise. He watched interested, she was showing love for him, she was trying to give him the best sunrise she could get, he felt so happy.

She handed back the phone with a smile and the consultant looked at the last picture she took, still on the screen and said “Wow, thank you so much for taking this picture for me. Isn’t a sunrise so beautiful? Isn’t the knowledge that there will be another one tomorrow reassuring?” She looked at him with eyes that didn’t know if they had to be happy or sad and said “I love this sunrise, because it reminds me of the sunset of my youth. When I was a young girl I used to go meet my father returning from the sea and help him carry the fish back to our house for my mum to cook. That Kerala sunset on the Indian ocean is what i miss more about my father that is not with me anymore”

The consultant looked at her with a smile and a tear in his eyes and told her “Thank you for sharing your sunset with me, if you are ever sad again, share your sunsets with the people around you, you are giving them joy”

She smiled

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.

 

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 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.

Test coach versus test specialist, impact on queues

I recently had a very interesting conversation with a group of skilled testers on whether or not there should always be a test specialist in a cross-functional team.

A lot of people say yes, my personal experience says not.

My personal experience tells me that the most effective and efficient approach uses a test coach that slowly makes himself scarce. My experience focuses on creating competencies for completing an activity (testing) in a collaborative context.

One aspect I am finding difficult to explain is the impact on queues of a test coach approach, I will use a series of Scenarios and pictures to facilitate my reasoning.

If you feel like substituting activity A = development and activity B = testing feel free, but this approach is activity agnostic in my experience as I have applied it to analysis, and development obtaining similar results.

Scenario 1 – Test specialist

In the presence of one specialist on Activity B and many specialists on activity A.
Problem: Long q
ueues form in Ready for Activity B (Case1) or worse specialist multitasks on many activities at the same time slowing down flow of work as per Little’s law (Case2)

Screen Shot 2017-05-29 at 10.40.47

Scenario 2 – Test coach

Stage 1: In the presence of one coach on Activity B and many specialists on activity A
Initially coach pairs on Activity B with people that do activity A. This way we obtain 2 benefits:

  1. Queue in “Waiting for Activity B” is reduced as one person normally performing activity A is busy pairing with coach on one activity B task
  2. By pairing on activity B feedback loops are shortened
  3. Person with activity A acquires new skills to perform activity B from pairing with coach
  4. Quality of activity B increases as it is a paired activity
  5. Flow improves because of 1 and 2

Screen Shot 2017-05-29 at 11.22.49

Stage 2: When cross-pollination of skills required for activity B starts to pay off, we have 2 benefits

  1. Normally some activity A person will show particular abilities with activity B, in this case this person can pair with another less skilled activity A person to perform activity B
  2. Queue in “Waiting for Activity B” is reduced as more people with activity A skills are performing activity B
  3. Flow of value improves lead time decreases
  4. More activity A people get skills on activity B

Screen Shot 2017-05-29 at 10.56.00

Stage 3: All activity A people are able to perform activity B
Activity B Coach can abandon the team to return only occasionally to check on progress. Benefits:

  1. Activity A and activity B can be performed by every member of the team
  2. the WIP limit can be changed to obtain maximum flow and eliminate the queue in Ready for Activity B.
  3. The flow of value is maximised
  4. The lead time is minimised

Screen Shot 2017-05-29 at 10.58.05

WARNING: I have applied this approach to help teams with testing for many years. It has worked in my context giving me massive improvements in throughput and reduction of lead time. This is not a recipe for every context, it might not work in your context, but before you say it won’t work, please run an experiment and see if it is possible.

This is not the only activity that a good test coach can help a team on, there are many shift left and shift right activities that will also reduce the dependency on activity B.

I have been told a million times “it will never work”, I never believed the people who told me and tried anyway, that’s why it worked.

Try for yourself, if it doesn’t work, you will have learned something anyway.

One very simple tip to help teammates connect

A couple of years ago, I started working with a new development team. As a coach, I spend the first few days observing behaviours and saying very little beyond a joke here and there.

Well, this team didn’t seem to have a process or technical problem, but I noticed a strange trend at their morning standups. People were being a bit “bitchy” to each other and focusing on people rather than on the work to be done.

You could hear things like

“well, my card is still there because I have been spending all day reviewing Frank’s pull request, not great…”

or

“I was writing the new stories but then Jack changed his mind… again…”

et cetera, I’m pretty sure you know the drill.

So on day 3 I went to the standup and I said, folks, let’s do an experiment. Before you say anything, you have got to say something nice about one of your teammates, shall we try?”

People looked at me like if I had seven heads, so I went “I’ll go first. Frank, you’re looking good today, I like your shirt, very smart”

People laughed. Then they tried.

I could see they were spending some time trying to find something nice to say, they were looking at something they liked about their teammates.

As humans, we are very good at finding flaws in people, on the other hand, we need to make an effort to find something we like about them, but if we try, we can discover something that we like, helping us connect.

Another consequence of this approach was that people realised their behaviour was not acceptable without being told and felt that they came up with the idea of reducing the bitching remarks.

All in all an easy win with very little effort.

WARNING: This approach won’t produce any positive effect if the hostility between team members derives from long-standing hatred, but it works very well with newly formed teams where people are trying to make themselves noticed sometimes using means that might be confrontational to their teammates.