The owner of a window shades company, was asked by a business consultant “What business are you in?” He initially answered “We are in the window shade business”. Then he was asked “When someone walks into your store, why do they want a window shade? What are you really selling?” he had to pause and think before he saw it
“We’re in the light-control and privacy business! – not the window shade business.”
The implications of this discovery were that by understanding the company real purpose, he was able to introduce new products that his customers loved.
Reading this story reminds me of the struggle of the testing community to get buy in from business owners. Years and years of hearing complaints that business owners don’t understand the importance of testing, they don’t appreciate the hard work of testers, I have grown tired of it.
I believe it’s not the business owners not to understand testers, I believe it is testers not understanding the business they are in.
The majority of the testers I know believe that they are either in
“The business of finding bugs”
“The business of sourcing information to help make decisions”
The testers I want to work with are in “the business of delighting their customers”, that is what we all need to be in.
If we make our business “delighting our customers” believe me, we will find a lot of innovative ways to do it as testers.
Forget about defects, forget about information, focus on delighting your customers and
you will find innovative ideas to improve the quality of your product
the business owners will love your work – and most of all
Previously on “A knowledge worker’s tale“: Team X discovered that lack of clarity on what to build, was creating a backlog in their exploratory testing work queue. They realised that adding new testers would have only fixed the symptom of the problem but not addressed its root cause.
Team X met to talk about a possible solution to the fact that too many misunderstandings in the user stories were slowing down the work dramatically and driving the testers crazy.
When Gus walked in, they were all there, nobody was late, the team really wanted to resolve this problem.
Mike took charge and said “We need to ensure that the user stories contain all the details, we can’t be blamed for problems in the requirements”. All the others nodded in unison, the bloody user stories were the problem…
Peter added “Absolutely Mike, we need Fritz to sign off the user stories so that when we start, if there is a problem, we know who’s fault it is and we don’t get the blame every time, I am tired of this!” he added “we need to make sure we know who’s fault it is”.
Before Fritz could answer, Gus interjected “OK, let’s see. Am I right in saying that our goal is to deliver value to our customers? Right. How is identifying who to blame going to help our customers? How is blaming somebody going to help our customers at all?”
He continued “Customers will still get the product late because of the misunderstandings, I bet if you asked them, they will tell you that they don’t give a rats arse who’s fault it is. What they care about is to get a solution to their problems, through our software”
Then he went “Once there was a little man in Japan, many years ago. He said that every activity that does not benefit the final customer is waste and needs to be removed from the process. He went to define 7 categories of waste that can be found in manufacturing. This guy’s name was Taiichi Ohno, he revolutionised the motor industry and his learnings have been used to improve manufacturing all over the world, he worked at Toyota. I strongly believe his lessons can be used very much in every context, including software development, let’s not introduce waste, let’s focus on value add activities”
“It seems reasonable” said Mike “but how do we make sure the defects in our stories don’t get caught only at exploratory testing, we have seen that when that happens our flow gets to a standstill, we can’t allow that”
“Taiichi would be proud of you Mike” said Gus. “One of his 7 categories of waste was exactly what you described, ‘defects’.” he continued “Quality was fundamental in the Toyota production line, one tenth of a millimetre difference in a bolt could bring the line to standstill, Taiichi knew it and made sure the workers knew it too so that they could find new ways of avoiding it”
Gus stood up and went to the whiteboard, he wrote “Prevention over Detection”. Then he drew a circle that had 3 stages “1. Write a failing test” – “2. Write enough code for the test to pass” – “3. Refactor”.
He went “Ladies and gentlemen, this is TDD, the one most effective ways of preventing defects in your code I have found in my 20 years as an engineer. In one of it’s more modern evolutions it is called BDD. Through high collaboration and conversations it allows teams to deliver code that has a fraction of the defects of code written without it. If you like to know more, I can organise a one day workshop to talk about BDD and how it can help us prevent defects”
Peter said “I am a bit confused about all this stuff, little Japanese people building cars and tests that are written before code, it doesn’t make sense. But in all fairness Gus has been right before with even more nonsensical stuff like ‘do less to do more’, I think we could take a leap of faith and trust something good will come out of this, what do you think guys?”
The team nodded in silence, they were puzzled. Accepting something brand new and counterintuitive can be scary, but true agile teams are courageous in their decisions.
Gus smiled and left the room so that the guys could make a decision freely.
Will Gus’s nonsense help team X? Stay tuned and discover what happens next
I 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?
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.
I have had a lot of conversations, with agile people and not, around the topic of measuring success of an agile team. I have heard all sorts of metrics thrown around, from velocity, throughput, number of bugs or lack thereof, and so on.
The fact is that those metrics are completely useless, let me tell you why.
Imagine that your team in a period of 3 months has increased its velocity from 24 to 48. What does that mean? Some people will tell you they are 100% better or even 100% more successful!
I say that they are 100% better at delivering stories (assuming they didn’t game the metrics)
More than likely they work in an organisation that measure success based on the old Budget-Time-Scope paradigm.
Unfortunately in your search for speed you are sub-optimising your system and not achieving the real goal of your company.
What is a successful team?
A team is successful if they help the organisation they serve be successful, regardless of how many story points they deliver.
Let me tell you what a successful team measures.
A successful team measures business outcomes. What are business outcomes? Let me give you some examples:
1) x% increase week to week on downloads of your mobile app
2) y% increase in signups month to month
3) z% reduction of customer support calls month to month
or any similar outcome depending on your context where x,y,z>0
Because an organisation that obtains those outcomes is normally successful.
Even more importantly, the team will continuously monitor how their actions affect the business outcome metrics they have set to achieve so that they might decide to:
Stop writing that feature, we have obtained the result and any further bell and whistle wont give us ROI
Do more of this, the metrics are going in the right direction but not as expected
Stop doing this and do something else, this feature is not producing the results we were expecting
Ah, look at what the customer is doing instead of doing what we thought he would do! Let’s help them do it in an easier way…
Now compare this to delivering all the 1 zillion stories in the fixed scope at the velocity of 48 per sprint.
If you don’t want to read the full article here’s the TLDR: Can we embed the agile values in the format of a beginners talk so that people will learn by breathing them rather than hearing about them?
I received quite a lot of encouragement from a lot of people. I love the agile/lean community, thank you folks, you are incredible!
I got some great suggestions from Patrick Steyaert that recommended looking into Lean Coffee and Fish Bowl.
Both formats are highly participative and pretty much agendaless and gave me a great point to start at.
My goals in priority order:
Do not bore an audience that for the first time hears about agile. Don’t push them away!
Identify a format that embodies the values I believe to be the most important in agile and make sure the attendees feel and recognise them while they are attending
Make sure people actively participate
To me the most important values in agile are: people, customer and responding to change.
I asked 3 fantastic practitioners to help me on the day. The 4 of us were “the agile product team” that was going to deliver the product (learning) to our customers (audience)
Thank you so much to Claudio Perrone, Andrea Baker and Lisa Hickey for accepting to help with less than 24 hour notice and no details whatsoever on what i needed them to do (isn’t this ability to respond to change? :-))
I told the audience that me and my team mates were going to give a product to them, they were our customers and as such they were extremely important.
To start we needed the customer help to understand what real value is to them.
We asked them to select with dot voting some agile topics from around 35 different agile topics (I took a subset including mainly basic concepts).
The customers immediately queued towards the table where the cards and the markers for voting were. We time boxed the activity to 5 minutes. Claudio, ever the lean man, immediately identified a bottleneck as the table was too small and only 2 to 3 people could vote at the same time.
The activity had to be extended to 6 minutes to allow everybody to vote.
The team took 6 topics with highest number of votes and put them on the wall in dot voting ranking order.
We started with the first topic.
It happened to be BDD: First thing, I asked the customers if they knew what it was. One of the people in the audience started giving us his take. When he finished, I spoke about it a bit, then my 3 team mates took turns in adding their perspective.
Responding to change
This lasted for 5 minutes when the timer went off and i asked the audience to tell us by using thumbs up or down whether they wanted to continue talking for 5 more minutes about BDD or if they wanted to move to the next topic.
People voted for sticking to BDD for 5 more minutes
After 5 more minutes we voted again and we went to the second topic.
We made sure that the team swapped activities, everybody took turns in talking about the topics, we alternated roles like time keeping and pulling the cards from the wall.
We wanted to show team collaboration and cross functional abilities.
I got loads of feedback from the people in the audience and the team.
Claudio suggested that when talking about topics, the first couple of sentences need to describe it in a easily understandable recipe format, this is true in particular because of the audience low level of agile knowledge.
Davide Lovetere an enterprise Architect among our customers gave me a lot of incredibly valuable feedback around some contradiction in terms he had noticed during execution.
Other customers said that they enjoyed the format and want to use it for some of the meetings they do in work (yay!)
Other customers said that they enjoyed it but it finished too early, we only had time to talk about 4 topics and they would have loved to touch more
I loved doing it, received valuable feedback to improve it and can’t wait for the next time!
A 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.
I started to really listen to what developers said instead of listening for finding gaps in their thought
I listened and listened and listened a bit more
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
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”
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!”
Who do you think will be able to influence developers actions when something important for testing needs to be done?
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.
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.