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.

Advertisements

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.

 

Can we train ourselves to be more empathetic?

how_does_that_make_you_feel_

For a good while, I have been thinking more and more about the impact of our behaviour on our success and the success of the organisations we are part of. This brought me to observe people’s behaviour in trying to achieve a goal and the different reactions that each approach caused.

I have also done some experiments myself, trying to achieve the same goal using different behaviours on purpose.

The differentiator in the behaviours I have been observing is empathy

The subjects I have observed are of the type: developer, tester, analyst, business stakeholder, manager, leader.

What I found out is that the difference in the success of people with high empathy versus the less empathetic ones is astonishing. It is a different ball game. Empathetic people, get things done while building strong relationships and creating an enjoyable environment.

On the other hand, I have seen extremely skilled and capable people struggle to get anything done because their lack of empathy for their teammates made them choose behaviours that instead of achieving their goal, frustrated them and in some extreme cases made them withdraw into a corner full of anger and resentment with a common mantra: “they are idiots and they don’t understand”.

Being very empathetic, I feel very bad for them and I want to try to help.

You control how empathetic you are

The first thing I can do to help my less empathetic readers is to demonstrate to you that you are in control and can train your empathy to become more successful.

I believe we decide whether we want to act with empathy or not. Empathy is not in our DNA, it can be learned and improved. How do I know that? 

Let me tell you a story

A few years ago, driven by my burning curiosity, I had managed to get the hang on agile software development and I really thought I knew a lot about it.

Being an extrovert, I thrive when I am in the presence of big groups of people. At the same time, I am also an avid learner and I know that for me, sharing my thoughts in public, is the most effective way of learning something new.

One obvious  way of taking advantage of this two aspects of my character was to start participating actively to some Agile and Agile testing online groups with the honest intent to help people that needed help and learn in the process.

I tried. It was a train wreck.

My goal was learning by helping people resolve their problems, but the result was that I was pissing people off and pushing them further away from subjects that they found already enough challenging before they met me, the annoying Italian dickhead that thought he knew everything.

What was the cause of this disaster?

Was my knowledge on the subject not sufficient? Did I fail because of my incompetence?

No.

I knew enough to help the people starting with agile, I had the necessary knowledge and skills.

So what?

One day, I started following the answers of another person in the group let’s call him Mr. Joe. He was saying the same things I was saying, we agreed on everything, we even spoke a few times about how much we cared for the agile community and how much we wanted to help.

So, same skills, same motivation. Was he annoying people like me?

No. People loved him. They asked him direct questions and thanked him all the time.

I remember in one specific case, I got frustrated as I had spent quite a long time replying to a quite complex question with a good solution, then after I already did, Mr. Joe said the same things I said, in different terms.  and the person asking the question would thank him and ignore me.

Guess what? The person asking the question thanked Mr. Joe and completely blanked me.

Can you imagine? Somebody asks a question. I give him the right answer. Mr. Joe gives him the right answer after me. Mr. Somebody thanks Mr. Joe and blanks me.

I knew something was wrong and I started trying to find patterns, similarities and differences between me and Mr. Joe.

Then one day it hit me.

I was answering to “say the right thing”. Mr. Joe was answering because he cared that the person that asked the question would learn.

I felt stupid and ashamed of myself. I was really down. I realised how self-centered and selfish I had been while acting righteously as the “saviour of agile”.

Discovering bad things about ourselves is painful, but life has taught me that it is also the best thing that can happen to us because that’s the time we can make a decision to change and improve our lives.

I changed, bit by bit, slowly. Before answering any question on the forum, I started asking myself:

This person came to a public forum and asked for help on a subject he doesn’t know well, how might he feel?

How might this answer affect his feeling?

If I say this will he feel bad? How about I say it like this, same message but more positive, will he feel any better?

And it worked.

empathy

Week after week I started to get people contact me privately and thanking me for my time and help. They were telling me how my message had helped them resolve the problem.

I had been doing that exact same job for years and nobody ever did thank me. Then it became a stream of people thanking me for my help.

Be considerate, mindful, empathise with others. They will feel your empathy and compassion. They will want to work with you and their actions will also make you feel good about yourself.

It’s a win-win, we are both happy, why don’t you try?

5 Easy steps for Testers to Influence Developers

nobodylistenstomeA classic problem for testers in agile contexts is the fact that they feel they are not listened to by developers. Testers, often rightly, warn developers from doing stuff because the consequences could be very bad, but developers in many cases don’t listen to them.

This is very upsetting, testers find themselves lonely within an agile team because of this. They get frustrated and if they keep on asking and screaming their needs they risk being alienated by their team members becoming completely ineffective while growing dissatisfied with their job.

But, but, they are right in telling the developers what to do! WTF?

When working as a tester in an agile team you’ve got to develop a skill that before you really didn’t need that much.

It is called influencing. Before when you worked in your separate QA department/test team you didn’t need it because there was a test manager that was fighting the battles for you and deciding the test strategy to be applied.

Things have changed, you’ve got to become good at influencing.

This is what Gus did when he moved to an agile team as a tester many years ago.

First I tried barking orders, screamed and shouted, but it din’t work at all, so I decided to adopt a different approach.

  1. I started to really listen to what developers said instead of listening for finding gaps in their thought
  2. I listened and listened and listened a bit more
  3. Third I started asking questions showing real interest in what they were doing. Being mindful of their fears and feelings. I made sure they knew I was there to help and that we were all in the same boat
  4. I started praising them when they did something good, for example thanking them for adding testability to the application. Things like “without Roberto’s design I would have spent weeks doing what I can do now in 10 minutes, thank you so much Roberto, you made my life better”
  5. I started coaching them on how to test by testing with them. When they saw what testing really involved, they understood its importance and challenges and started asking interesting questions about it.

Who will developers listen to?

Now compare the developers’ reaction when faced with a suggestion raised by Gus to the one that Jack gets. Jack is a tester that uses the classic approach of “what the hell are you talking about? This is going to explode in production!”

You feel like this
Jack

Who do you think will be able to influence developers actions when something important for testing needs to be done?

Not Jack.

Me? Often, I always got the developers at least to listen to me and a lot of the times we did it my way unless somebody in the team had a better idea.

So, do you want to be Jack and keep on moaning about developers that don’t understand anything about testing?

If I were you I’d take Gus’s approach and build your influence within your team, start now, start listening.