The man that listened to my heart

Travelling by foot with a rucksack on my back and a mask on my face is not easy. Restaurants are shut, buses make their own schedules and arbitrarily decide not to run if there is nobody around despite advertising their services and selling their tickets online.

I look weird and people look at me with suspicion, i am at peace with that, i am properly starting to not give a fuck about it, it is liberating.

Sometimes, when i show up at a bar, people get startled, they are not used to seeing people travelling alone, in particular in this lockdown time. People these days are afraid of everything and they combat their fears by buying the latest gadget or that book that promises huge improvements by following 5 easy steps. Patience and slow learning is no longer of this world.

Cecina is a lovely tuscan village north of Rome and home to some great people i met while working in Dublin. I was returning to the continent from Sardinia and as my ship to Genoa got cancelled for 2 full weeks due to the pandemic, I decided to sail to Livorno and go visit Cecina and my friends on my way to Genoa.

One early morning i walked from the main village to the marina through the fields. It was beautiful to watch the sun rise from the Apennines in total silence with only 2 builders on top of a roof calmly staritng their working day.

The pine forest that precedes the beach is really beautiful, well kept and with a 5k track to exercise, for free. I was the only one, everybody else at home hiding from the pandemic. I had a great time doing the track, in silence, with the noise of the rain dropping softly on the maritime pines that protected me.

Then I went to the beach. Wild and full of tree trunks, in front of an agitated sea. More silence, more nobody around. Best place for stretching and exercising, using the different rocks to do all the “weights”, it just takes patience to look and find the right one for the right thing to do.

By 11 am i was hungry but all the restaurants were closed and all i could get was pastries in the kiosks at the sea and little pizzas. I wanted something better, so i found a fish shop and got 3 beautiful French oysters that the owner kindly opened for me so that i could eat them in front of their shop. Oysters for breakfast is my favourite thing, they are super tasty and full of energy.

Then i decided to walk back to Cecina and i wanted to find a fountain to drink some water. I asked and some people gave me directions but i could not find it. I saw a man, that later i will learn was called Leo, next to an ice cream little shop working patiently on fixing a bicycle. I moved closer and i asked if he knew where a fountain was. He turned and told me, “here’s the key, the bathroom is at the back, you can wash yourself.” I thought it was a bit weird but I was in need of a quick wash after all the walking and exercise and decided to take on the offer.

I went at the back, washed myself and filled my bottle with water.

I went back to give the key back to Leo and thank him and so I did. I told him that i was very grateful because he not only helped me fill the bottle with water but also offered me something i needed. He looked at me quite puzzled and asked me if i had filled the water bottle in the bathroom. I said yes and he said, “don’t drink that” and he handed me a water bottle from a selection he had in front of him.

I was confused and wanted to pay for it. He said i didn’t need to pay. So i decided to spend some time talkjing to this strange kind man, more or less my age. I had assumed that he was being kind because he saw i am an amputee and sometimes people give me extra care due to that, but what i found out is that Leo is partially blind and didn’t even notice i was an amputee. What he told me is what hit me, he said “I heard it in your voice that you needed help, and i gave it to you”.

I might be walking alone, but with people like Leo I will never be lonely.

Thank you Leo, i will come back when your ice cream shop is open this summer to repay your kindness, or just for a chat.

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

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.

 

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

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!

 

 


					

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.

Is agile Alive? Dead? Misunderstood?

Lats Sunday, after reading multiple “Agile is Dead” articles, I posted this short update on linkedIn

screen-shot-2017-03-05-at-11-03-37

As you can see from the stats, in less than 7 days it has received a lot of attention (I am not an influencer and my updates generally do not receive such large feedback)

My contacts in linkedIn include a lot of Agile or Lean Coaches and as expected, initially the message got some positive comments. Soon after some agile detractors joined the conversation and made it much more interesting as generally feedback that comes from different perspectives enriches the conversation adding dimensions that sometimes cannot be expressed by a biased mind.

I noticed 3 interesting trends in the messages.

  1. When agile is not driven by technology, agile fails
  2. When agile is driven by technology and not the business stakeholders, agile fails
  3. Agile is only useful to deliver something nobody wants quickly

The first 2 are extremely interesting, in fact they say exactly the opposite thing but they both come to the same conclusion “agile is dead”. I read and reread those messages and then I saw it

If agile is driven by one part of the organisation, whichever it is, and trust is not built within the whole organisation, it will fail. Do it like this and agile is dead before you even start.

If you try to own something that will change your organisation and run with it, you better make sure you share your vision, your responsibilities and your success with the rest of the organisation. How do you expect people outside your little world to want to follow you in this difficult change if they don’t know, understand, own and help you change. Agile/lean transformations are not driven by a department, they are driven by the whole.

And the result might be that you even stop talking about departments and only talk about the whole.

Now on objection #3.

Agile is only useful to deliver something nobody wants quickly

I have seen this very often and honestly makes me sad. A lot of scrum implementations have a Product Owner that is seen as the heart of the product, the person that understands the vision of the product and that takes the responsibility to take the important decisions for the future of the product in regards to strategy, prioritization and so on.

If you look at it this way, you might think that the PO is a single point of failure, in fact what if he is not able to make good decisions, how about his bias, is he a dictator?

As an agile coach I make sure that any product owner that works with me will have the tools for making good decisions. He in fact will know how to manage flow using WIP limits, he will be aware and become proficient in UX techniques, he will learn how to monitor, gather and use feedback from his customers, he will understand the importance of small experiments, he will be aware of cost of delay and when prioritising his features and user stories will have access to many advanced prioritization techniques.

Being agile does not mean automatically ignoring lean startup, lean UX, research. No that is not being agile, that is being a scrum master after 2 days training.