Can you remove a Tester and get better quality?

whaatHave you ever been in a conversation like this?

Manager: “The last release is very buggy, why didn’t we spot the issues before?”

Tester: “We did all we could with the resources and the time given to us”

Manager: “What can we do so that it doesn’t happen in the future?”

Tester: “We need more testers”

Manager: “OK let’s get Michael form the 4th floor help us from Monday”

I have been hearing this conversation for more than 20 years. I have even been the tester and the manager in these conversations.

But what happened the following release? Did Michael from the 4th floor manage to help improve the situation? Not at all, and the same would have happened if also Frank and Jane from the 5th floor helped, and so on.

One day, over 10 years ago (before I even knew what agile or lean was), I thought that insisting with the same approach would have been insane, so I started to look at what different possibilities we had and I tried a crazy move.

When challenged with the same “too many bugs in this release what do we do?” I said:

Why don’t we remove a tester instead of adding one?

People laughed at me, but I had enough influence to be able to try this.

Against all odds, things got a lot better. The one tester remaining in the team was swamped with work and developers felt they needed to help to avoid getting everything on hold.

Guess what, they started to help.

Some of the activities that were “tester zone only” before, became accessible to developers. A different perspective helped identify some inefficiencies in such activities and developers adapted some of their own process to help.

All of a sudden giving developers visibility over the test activities had triggered a lot of curiosity and interesting hypothesis. Some developers, challenged with repetitive tasks, created small tools to make them faster, some other saw how sharing the test plans with the developers could help prevent issues that otherwise would have been caught much later, and so on.

This was many years ago, it wasn’t perfect, but taught me a great lesson.

If people don’t have skin in the game they won’t improve the system. If they are affected by a problem they will resolve it instead.

If you ask your developers to write code, that’s what they will do, defects and all.

If you empower them with delivering customer value they will look beyond the code and make sure that what they deliver is also useful for their customers.

This is one of the foundations in today’s agile software development teams where role silos are gone, collaboration is fundamental and team members care about customer value rather than lines of code or number of tests executed.

We’ve come a long way

 

The art of doing 1/15th of the work and getting earlier business outcomes

imagesIf you are an agile practitioner you are likely to have read the book “Scrum – The art of doing Twice the Work in Half the Time” from Jeff Sutherland. I am a fan of Jeff and I believe that what he has done for software development in the last 20 years is great.

I do have issues with the book’s title though.

That title is what makes people think that being agile means being able to go fast and deliver more stuff.

Is this what real agility is?  Let me tell you a story.

At a client of mine a couple of years ago, I was asked to coach a product team and help them with a new product they were starting to work on. I was excited about it and asked the product owner to meet for a coffee and initial chat.

He kindly agreed and told me: “before we meet, have a look at our requirements document so you will know what the topic is”. He also told me that a high level estimation had been done and that the product would take from 6 to 8 months based on one agile team and that there would be licensing costs associated with an automated scanning system we had to acquire.

Attached to the mail there was a document of about 50 pages with detailed workflows, low fidelity prototypes of the screens and quite a lot of explaining text. I skimmed through it looking for a description of the problem that the product was meant to resolve, but couldn’t find it.

I read and reread the document and I couldn’t find the original problem that the product had to resolve, it was not there.

When I met the product owner, after agreeing the weather was miserable (that’s how we start any conversation in Dublin regardless of the season) he started describing his solution. I let him explain to me the beautiful features to build and the amazing technologies we were going to use.

When he was finished, I asked him: Why are we building this?

The initial reaction (completely normal) was a defensive stand for his solution. When I probed more, it was clear that after having worked for so long on the product on his own he had forgotten the nature of the initial problem that triggered the decision to build this product.

Using the 5 WHYs technique, in about 10 minutes, we eventually got to the initial problem that we needed to resolve.

At this point the conversation became different.

I asked what he thought were the features we should prioritise to resolve the problem so that the customer could have something earlier than in 6-8 months. That triggered the interest in the PO that identified 5 features (about 30% of the total described in the document).

I then took each feature and asked him if it was necessary to resolve the problem we just identified. After another 10 minutes we agreed that 1 single feature, that accounted for about 1/15th of the initial solution, would resolve the customers problem. To avoid making the PO feel bad about having done so much unnecessary work, I told him that we would build the other features incrementally, and that it was a great success that he had identified a single feature that would be useful for the customer almost immediately.

We then agreed to identify outcomes of success for the full product and start measuring immediately as soon as we released the first feature.

These read something like:

“We will know we have succeeded when 30% of customers do X instead of Y” or

“We will know we have succeeded when we will have 40% less support calls related to problem X”

et cetera. I made sure the business outcomes were related to the initial problem, not any product.

What ended up happening is that we built the first feature in 2 weeks (opposed to 6-8 months) and the measurements told us that we had reached what we wanted already.earlierbusinessoutcomes

We never built the other 14 features, we stopped because the business outcomes we had set were reached.

And yes, you guessed, we didn’t have to buy the licenses for the automatic scanning system either.

As a coach, my mission in organisations is to guide teams and navigate problems, maximising value with minimum work. This is always welcome when meeting CTOs or CIOs because – most of the time – less work means lower costs and earlier delivery.

We did 1/15th of the work and got business outcomes earlier, a big improvement IMHO from “doing Twice the Work in Half the Time”, what do you think?

This is how I measure the quality of my work

notneededI have blogged in the past about product development and measures of success, it is a topic that interests me a lot.

I am an individual that sells services to organisations that develop products. This makes me a product as well. In fact organisations might want to hire me because they have a problem and believe that I (the product) can resolve it.

The product I advertise is something like this:

“I will help your organisation deliver products that matter through coaching your people on the use of agile and lean practices”

 

There are many ways of defining success KPIs for engagements of this type. targets will be set, numbers will be pulled out of thin air, promises will be made, but I am not 100% sure that the quality of my work can be measured like this.

I might meet or exceed all the KPIs we agreed at the start of my engagement, but if at the end of my gig you still need me to fix the same problem, then I have failed.

A coach must be able to work himself out of his own job.

If you don’t need me anymore because your people are now able to resolve the problems without my help, then I can safely say I succeeded.

So, my promise to my customers is:

I will do all I can so that you don’t have to pay my services in the future

Two months off the rat race

rat-race-1After 4 years in PaddyPower I have decided to stop working there and I am newly unemployed.

In the last month, when talking to people about the situation, the questions I was asked in 99% of the cases were: Have you found something else? Where are you planning to work after you finish?

When I responded, “I plan to have a great summer not working and start thinking about getting back into the wheel in September”, I saw worried looks in people’s faces

People generally hear my answer as “I haven’t found anything but I am too proud to admit it and while I struggle with self esteem, financial difficulties and rejection I might hide in my apartment and post on Facebook that I am on an exotic holiday, pray for me”.

It is not so socially acceptable to take a break to think in particular if like me you are  well over 40. It is instead completely acceptable to jump into the next shitty job immediately because it is important to be turning the wheel and if everybody stopped to think the world would likely implode.

Time to think about life. Time to think about what we are. Think about what we want to be.

I am off the rat race for 2 months, ciao!

 

 

What tester are you? /s

Let’s see what kind of tester you are, answer the 3 questions below and find you profile description at the bottom.

You start testing and the product has obvious problems even with the “happy path”, both cosmetic and very obvious bugs are everywhere, what do you do?

  1. I send the product build back and don’t touch it because it is not testable and back to facebook for the day!
  2. I log 124 bugs in extreme detail, one for every problem I encounter. If somebody after 3 days asks me why I am not finished yet, I respond that I am logging bugs and testing is not complete.
  3. I go talk to the developer that made the last check in and ask him why he didn’t test his product. If he says, “because you are supposed to do that” I talk to him about the incredible amount of waste he is creating by delaying the feedback on the product and not testing it himself. I sit down with him, ask him to test the product and fix the issues we find together in a continuous loop until we both are quite happy with the result.
    I then explain to him that if the feedback for each of the issues has to come from a different party (me) the delays in the detect fix retest rate will create a massive amount of waste. I encourage him to test his application before sending it to me and as we are at it I suggest the next time we test it and fix it together.
  4. I tweet to the world how idiotic my developers are and include screenshots of the errors. I spend 2 hours defending my point on social media and catching my interlocutors on inappropriate use of terms to prove my point.

You have been sitting idle on your chair for over an hour because there is a delay in the build you want to test, what do you do?

  1. Yippee I have time to browse the web and watch some videos on youtube! I hope their problem persists for a while, the new Game of Thrones season is awesome!
  2. I look at my test plan, change it a bit, add some graphics, get a coffee and start reading that testing book I always wanted to read.
  3. I have been out of my desk already for 50 minutes. 10 minutes idle time is waste, our customers are getting our product later than they should.They say there is a problem with the build, let me see if I can help out. I go and offer my help to my teams’ developers. They might need me to rebuild a machine to check something or to try something quickly to debug the problem. I get stuck into it, wow, I even learn something about it! I might even resolve the problem altogether using my strong critical thinking skills and looking at the problem from a different perspective. I help, we solve the problem and, yes, now I can test it! Chances are that while troubleshooting the problem I have already gathered a lot of information on the product that will support and supplement my testing.
  4. If developers are idiots there is nothing I can do, I will spend this time blogging about how to become a better tester and how testing is the most important thin g in the universe, much more complex than development by the way.

Developers have nothing to do because the analyst has been sick and there are no refined user stories in the backlog, you just finished testing, what do you do?

  1. BINGO! I might as well re-start House of Cards
  2. I start complaining and moaning about how this company sucks and about how better it would be if I was the decision maker here. We need to hire more analysts and testers of course! I then go back to writing more test cases even if there is nothing to test. I might also create some fancy SQL query to extract lovely bug lists to show to management with graphs and all.
  3. Great opportunity for learning a bit more about how business analysis works. In the previous weeks I have been helping the analyst and I think I can get the job done. I organise a meeting with the team and we start breaking down user stories, as soon as we have a couple ready we can start working. I will replenish the backlog until the flow is reestablished, using WIP limits will help me understand how much work I need to do on this.
  4. There is nothing to do, if development activities are foreign to me, imagine how I feel about doing something that is even further away from my testing world. I am here to find bugs and provide information to stakeholders, not write user stories, hire more analysts if you don’t want this to happen.

RESULTS

If most of your answers are 1, you are a slacker that happened to be doing testing. Why don’t you find a job you enjoy doing instead of trying to avoid the one you have?

If most of your answers are 2, you are an old time tester that spent the last 15 years in a bubble far away from the evolving world. Nothing outside your little testing world is worth consideration, after all you know better than anybody else and why should you improve?

If most of your answers are 3, keep on doing what you’re doing, you and your company will be OK

If most of your answers are 4, I know who you are🙂

 

 

 

Why are we sprinting?

another-victory-for-cipo

A few weeks back I asked this question on a very popular Agile and Lean LinkedIn Group:

10 years ago not many companies delivered value every month and Scrum really helped the industry with the concept of sprint. People started thinking in terms of vertical slices of value rather than systems and started to deliver value often, it was a great step forward towards agility.

Today most shops do 2 weeks sprints and it is commonly accepted that smaller batches are better than larger ones as they are less risky and also allow for earlier benefit realisation.

I understand how the concept of sprint has helped the industry become more agile and lean, but, and there is a but.

Why have sprints today? Why create artificial deadlines? Why create a minimum batch size, be it one week, two weeks or whatever it is?

If I am a mature organisation, I probably have cut delivery transaction costs and have a good strategy for continuous delivery and I am able to release whenever I want with little effort and risk. Why can’t I release when I have value to deliver?

Can anybody give me a valid reason for having sprints?

The topic became popular with a total of 35 thumbs up and 85 comments (including my replies)

Reading the answers, I am not only more and more convinced that sprints are unnecessary and dangerous artificial deadlines, but I am starting to think that in some agile practitioners thinking, the scrum guide has replaced the true reasons for agility.

If you have better reasons why we should always sprint, please add them as a comment, I am still hopeful I have missed something and want to learn.

 

 

 

 

 

 

Testers Prevent Problems, every day

500_euro_banknoten

Earlier Today, I read an article from the notorious tester Michael Bolton titled “Testers don’t prevent problems“. I would like to use an example to counter this assertion end expand the conversation.

Disclosure – I am a firm believer in prevention over detection in product/software delivery.

The Fact– In today’s news, we read that the ECB will be stopping the print of the 500 euro banknote because of its association with money laundering and terror financing.

(Source: The Guardian)

The Problem: According to the article, producing 500 euro bills was an error. It is a bug in the product “Euro currency bills and coins denomination”. In fact such bug has caused quite a lot of problems to our society according to what reported in the article.

Larry the tester – Let’s imagine that Larry, a tester, happened to be in the room where people where deciding the denominations of the euro notes. Let’s imagine he said “Hang on lads, this could be a problem as it would be easy to conceal large sums of money and smuggle them. Banknotes this valuable might help illicit traffic, should we stop at 200 or maybe even at 100?”

Let’s assume there were smart people in the room that decided to take the objection into consideration, made research to prove its validity and as a consequence decided not to print the 500 euro notes.

The Question – Could we say that Larry had helped prevent the problem?

I say yes, how about you?