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

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

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

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

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

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

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

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

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

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

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

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

tobacco smoke
Slow feedback loop

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

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

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

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

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

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

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

Let’s look at product development for example.

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

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

Our plan didn’t survive contact with reality.

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

waterfall
Effect of slow feedback loops in Product Development

 

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

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

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

fastfeedback
Fast feedback loops in Product Development

that regulates our body temperature. 

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

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

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

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

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

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

Advertisements

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.

 

Stop building a Shitload of products, you are killing your company

idreamoforganizations0awherepeopleareempowered0atodeliverproductsthat0amatterjoyfulorganisations0a28-defaultI took my first steps in technology over 20 years ago. If we exclude the year off I took in 2006 I have always been employed in many different companies and I can say with certainty that I worked on a “shitload of products” and I use that specific term with purpose, read on to find out.

During all these years, being somebody that loves learning, I ended up working as system analyst, developer, tester, business analyst, manager, leader, coach, change agent, plus some other short term hats.

If I exclude the last 6-7 years where I had the skills and the ability to influence decisions I can go back and say for sure that the products that were initially envisioned, before any customer feedback was used, can be called a shitload of useless stuff and one or two good ideas that resolve real customer problems.

Very often the product envisioned was very similar to the product that we delivered.

Am I saying that in my first 13 years I worked I mainly produced waste?

Pretty much YES.

Another thing I remember in those early years was that I was never in a team where we could say, oh thank god we are busy but it’s not too bad, we can do our work, go home and have a balanced life. Invariantly there was pressure. We need all this by that date, come on! Work faster!

To me, it always felt like we were told by Dilbert’s boss that if we shove some more paper in the printer it will print faster. Also, when we were not busy, then managers will fill our capacity with a new shitload of useless products created for the purpose to make people sweat, very often no thought on the customer whatsoever.

Am I saying that trying to deliver fixed scope, fixed date shitloads of products creates big problems to the workers that build them?

YES, not even the pretty much is needed this time.

Another thing that I have noticed through the years is that without exception, companies older than 3 years have already built a shitload of products that are now impeding their ability to respond to change and survive. We will call this “shitload of legacy systems”.

This specific shitload is used as the excuse for not being able to change, as if saying “yes sure, we can’t compete with the market and we will die soon, but it’s not our fault it’s the fault of the legacy system (that by the way we built)

Am I saying that the shitload of products are also causing the slow death of the companies that created it in the first place?

Yes

Next time you start a product, think twice before rewarding people for the delivery of all the scope, in time.

I have been helping organisations deliver products that matter to their customer as soon as possible, I am not in the business of delivering projects or shitloads of products.

I am researching new ways of demonstrating THE VALUE in MONEYof the “non built shitload of products and features”, if you are interested, let’s do this together.

 

 

How Team X got to the root of the problem by asking why

screen-shot-2016-10-28-at-08-26-32

Previously on A Knowledge Worker’s Tale: A large bottleneck appeared in the exploratory test column of team X’s kanban board, but only Rick and Jane, the testers, seemed to give a damn about it working hard to unblock it. Gus saw the problem asked the team to take off their headphones, go to a room and get instructions from the testers on how to unblock the flow of work.

And the story continues…

Team Xers reappeared in their open space with renewed energy. Rick and Jane had explained what they needed to get their work unblocked and soon people started working in pairs. Rick and Peter were debugging together an issue that seemed difficult to track with the assistance of Fritz the business analyst that seemed positive he remembered something important that could help them. Jane was showing to Mike and Jimmy how, what she thought was the correct customer journey, was not what Zach the customer thought it was.

It was great to watch, a group of skilled professionals working in groups, using all their skills and knowledge to troubleshoot a complex problem.

As expected, the pairing and collaboration gave its fruits, defects were getting fixed and retested and the bottleneck was reducing fast. Flow was being reestablished thanks to the team swarming and focusing on the biggest problem in the system, it was great to observe.

Once things got back to normal Mike called the team to the board and said “Folks, it has taken only 3 hours to fix that bottleneck that had basically stopped our flow for two days, I think we have learned a very big lesson today and the lesson is that when we see a bottleneck, we all have to chip in and help unblock it!”. The other guys nodded with satisfied faces finally seeing their work getting to completion again. “Well done all!” Rick the tester added “without your help, we would still be where we were 3 hours ago, collaborating has been fantastic” and the lads gave themselves a small round of applause.

“Let’s go back to work!” said Mike.

“Hang on, hang on” intervened Gus, that had been lurking from distance. “It is great that you guys found a way to reestablish flow, I was delighted to see how you collaborated and forgot about your roles for the good of the customer, I say well done for that”. He continued “The fact is, if we go back to work without addressing the problem that created the bottleneck in the first place, it will be only a matter of time before it happens again, don’t you agree? Now that we have it fresh in mind, I suggest we try to understand the real problem that created the bottleneck, let’s do a quick retro, who’s with me?” The team nodded and followed Gus in the retrospective room.

“So WHY do you guys think the bottleneck formed at exploratory testing?” asked Gus.  Immediately Peter jumped in “Because we need more testers!” to which some of the other team members nodded in unison. He added, “Rick and Jane are always super busy, they never have a minute free and at the same time they are always behind with work, the guys need help, we need more testers!”

“Adding more testers is a potential solution, but we haven’t identified the problem yet” said Gus. “I am going to ask a tester now, Jane, WHY do you think the bottleneck formed at exploratory testing?” Jane, slightly caught by surprise turns to Rick, mutters something, then says “Because exploratory testing was taking too long”. “Ok this sounds like a reasonable problem, and WHY was it taking too long?” added Gus. “Well, running tests would have been fast, but we found a lot of defects that needed fixing and that created a never ending back and forth with the developers and Zach” added Jane.

“Very good Jane, thank you, we are getting somewhere now” said Gus, and continued “so it appears we had too many defects in the stories you were testing, so WHY were we having so many defects?”. A long silence ensued.

Peter broke the silence and said “For my user story, it turns out I didn’t understand clearly what Zach (the customer) wanted, so I had to change it four times”. Jimmy added “Yes, the same for me, this feature is complex and the work me and Mike were doing had to be changed many times, every time Jane or Rick would find something wrong because they’d ask Zach and he changed his mind, yet again”

Gus smiled and went “Oh Oh Oh, I think we might be getting somewhere here folks, what do you think Mike?” Mike was deep in thought, head down. He stood up and said loudly “I get it! It looks like a communication problem early in the process presented itself as a visible problem in exploratory testing. It’s got nothing to do with testing!” He was truly excited by the revelation, then he added “The root cause of the problem is the bad communication between the team and the customer and the symptom shows up in exploratory testing.”

Gus said “That’s an excellent observation Mike, do you guys think that if you clarified your doubts with the customer before you started working you would have saved the time you have spent reworking?” Everybody in unison went “Yeah!”. Well, now we know what the real problem is, I’ll chat to you tomorrow morning at the stand-up and we’ll find a solution together, it’s getting late now. Great work everybody and well done for getting to the root of the problem with only four why’s, I normally need five…”

Gus stood up to leave but stopped mid-track and asked “Guys, so do we still think we need more testers?” Peter was first to answer “No Gus, you’re right that was a knee-jerk reaction, thinking about it ,we need more clarity, not testers”

Asking why enough times to get to the root cause of a problem is a great technique, thought Gus while leaving the office and heading to the pub.

Stay tuned and find out what happens next!

The next episode is out, find out how they will resolve the problem!