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.
Muhammad Ali has always been my personal hero and source of inspiration. I recently discovered that my affinity for him might also reside in his natural born “agility” and ability to innovate.
This is what Ali has thought me about agility and innovation
First lesson: Be ready to react quickly to changing conditions.
Kinshasa, Zaire, October 30, 1974, 4:00 am. The fight that will be remembered as the greatest of all time is about to start.
Ali wants his world champion’s title back. He tried to get it back from Joe Frazier three years earlier but didn’t succeed, he lost. Before he could have a rematch with Joe Frazier, a brand new guy stormed the scene and took the title, this guy is George Foreman, tonight’s opponent. George Foreman is a young giant, with incredibly powerful punches that managed to knock out Frazier 6 times during their title bout.
Nobody believes Ali can beat Foreman apart from Ali himself.
The fight starts. Ali and Foreman go at each other. Ali is being hit hard by Foreman. He is incapable of making his fast hands count against his opponent’s superior power. His dancing feet are not enough to keep Foreman away. This is a disaster. Ali’s best skills, punch speed, and fast dancing legs are not enough against this guy, Ali is going to lose.
But he is Ali, the King Of The World, the greatest of all time, it wasn’t going to be that easy.
It is at this point that Ali decides to change his tactics. This is something that boxers do all the time. They start with a plan; if it doesn’t work, they go to plan B, then plan C and so on until they either find an approach that is effective or they go down.
Ali is different, his plan B is something that nobody had done before and he devises it there and there while the fight is on, while he is being outpowered by his opponent.
The rope-a-dope is born.
Ali decides to let Foreman push him to the ropes of the boxing ring and to focus only on defending. He uses the loose ropes of the ring to go down on his back and duck his opponent blows. He decides that it’s a good choice as he can transfer some of the power of his opponent blows to the elasticity of the ropes and out of his body.
His guard is as high and tight as it had ever been in his career. He throws one or two punches only when he sees a clear opening. These punches are by design not powerful, no intent of knocking his opponent out, they are defensive punches, because “he won’t hit me while I hit him clean”.
For any of the millions of Ali’s fans, the first 7 rounds of the fight are heartbreaking. They can see their hero bullied against the ropes, unable to hurt his opponent. Everybody thinks it is only a matter of time before Foreman unleashes a clean blow and knocks Ali down. Not even his corner trainer, Angelo Dundee, can understand what Ali has in mind, and he keeps on shouting “Get away from the ropes! Ali, get away from the ropes”.
Then the 3rd, 4th, 5th, 6th, and the 7th round go by like this. But by throwing so many punches, George Foreman is starting to get tired. His punches are not effective against Ali. Ali uses the ropes to absorb the power and keeps his face out of reach through a tight defensive guard. George Foreman is punching himself out, Ali’s plan is working.
Then the 8th round. Foreman’s tiredness is showing clearly, even the commentators notice he is unsteady on his legs throwing ever slower and tired punches. Ali was waiting for it and sees it too. Foreman is tired, it’s time to strike.
Twenty seconds before the end of the 8th, Ali sees Foreman unsteady on his feet slightly lose his balance, he slips the ropes by turning to his right and hits Foreman with the most beautiful combination of 6 punches you will ever see.
Foreman goes down, he never gets up.
Ali is the King Of The World again.
Second Fundamental: Don’t be afraid to fail if you want to innovate
Ali had to try something new, if he didn’t he would have lost. He could have tried a less risky approach, less risky than one that nobody had ever tried before.
But he was Ali, he was brave, he went for the big bet, and choose the riskiest solution.
His experiment was successful, he created the rope-a-dope, an innovation in the 100-year-old world of boxing.
From Ali, I learned that being able to react to changing conditions and having courage when experimenting can help us innovate.
Thank you, my hero!
That’s what creates innovation in this world. We’ve got to try!
A defect is anything that threatens the value of the product.
Before we start, let’s agree that:
we don’t want defects that threaten the value of our product
we want to give our customers as much value as possible at all times.
If you don’t agree with 1 and 2 then, don’t waste your time and stop reading now.
Testers are normally associated with finding defects. Some testers get very protective with the defects they find and some developers can be very defensive about the defects they wrote. Customers don’t like defects, developers don’t like defects, product managers don’t like defects, let’s be honest, nobody likes defects besides some testers.
Why would that be? The reason is that the focus of a lot of testers is on detecting defects, and that’s what they get paid for in a lot of organisations. If you are a tester and love your defects, you might find this article disturbing, if you decide to proceed, do so at your own peril.
Defects are waste
Let’s be clear from the start: defects are waste. Waste of time in designing defective products, waste of time in coding defective routines, waste of time in detecting them, waste of time in fixing them, waste of time in re-checking them. Even writing this sentence took a good while, now think how much time it takes you to produce, detect, fix, recheck defects.
Our industry has developed a defect coping mechanism that we call defect management. It is based on a workflow of detecting => fixing => retesting. Throughout the years it has become best practice (sic) to have defect management tools and to log and track defects. Defect management approaches are generally cumbersome, slow, costly and tend to annoy people no matter whether you are a tester that gets his defect rejected, you are a developer that gets a by design feature flagged as defect, or a product manager that needs to spend time prioritising, charting and trending waste.
Another dangerous characteristic of defects is that they can be easily counted and you will always find a pointy haired manager that decides he is going to shed light on the health of his product and on the efficiency of his team by counting and drawing colorful waste charts.
But, if we agree that defects are waste, why are we logging and tracking waste, creating waste charts seems even more ridiculous, wouldn’t it be easier to try to prevent them?
Oh, if only we could write the right thing first and reduce the number of defects we produce! I say we can, be patient and read on.
Software development teams have found many ways of being creative playing with defects, see some examples below.
Example 1:Reward waste
Some years back I was working on a business critical project in one of 5 scrum teams . Let me clarify first, that our scrum implementation was at best poor, we didn’t release every sprint and our definition of done was questionable.
Close to an important release, we found ourselves in a situation where we needed to fix a lot of defects before going into production. We had 2 weeks and our teams had collectively around 100 defects to go through. Our CTO was very supportive of the defect killing initiative and he was eager to deliver with zero defects. He put in place a plan that included free food all day and night and some pampering for the developers that needed to focus 100% on defect resolution. Then he decided to give a prize to the team that would fix the highest amount of defects.
I remember feeling frightened of the possible future consequences of this reward. I spoke to the CTO and told him that I would have liked more a prize for the team that produced the lowest amount of defects rather than the one that fixed the most. Our CTO was a smart guy and understood the value proposition of my objection, he changed his approach and spoke to the teams on how not introducing defects in the first place is much more efficient than fixing them after they have been coded. Soon after the release, we started applying an approach that focussed on preventing defects rather than fixating on detection. We never had the problem of fixing 100 bugs in 2 weeks again.
Example 2:Defects metrics
In my previous waterfall life, I remember when management introduced a performance metric directly linked to defects. Testers were to be judged on the Defect Detection Index calculated as (Number of Defects detected during testing / Total number of Defects detected including production)*100. An index lower than 90 would mean nobody in the test team would get a bonus. Developers were individually judged on the number of defects found in their code by the testers and business analysts were individually judged on the number of defects found by the testers in their requirements.
Welcome to the battlefield!
The bug prioritisation meetings were battles where development managers argued any bug was a missed requirement, product managers argued that every bug was a coding error or a tester misunderstanding and the test lead (me) was simply shouted at and criticised for allowing his testers to go beyond the requirements and make use of their intellectual functions outside a scripted validation routine.
Going to that meeting was a nightmare, people completely forgot about our customers and simply wanted to get their metrics right. The amount of time we wasted arguing and defending our bonuses was astonishing. Our customers were normally unhappy because instead of focusing on value delivery we focussed on playing with defects, what a bunch of losers we were!
Our customers were very unhappy.
Example 3:Defects as non-conformance to requirements
In the same environment as Example 2, testers, in order to keep their Defect Detection Index high used to raise large amounts of minor or non-significant “defects” that were in reality non-conformance to requirements. Funnily enough such non-conformances were generally improvements.
Testers didn’t care if they were requirements, code defects or even improvements, to them they were money, so they opened them. Improvements were filed as defects as they were in non-conformance to requirements. In most of the cases, these were considered to be low severity and hence low priority defects to make the testers happy and had to be filed, reviewed, prioritised and used in trends, metrics and other useless calculations.
This activity could easily take 30% of the tester time. Such defects would not only take testers’s time, but would also affect developers, product managers, business analysts and eventually clutter the defect management tool.
Waste that creates waste, exponentially, how wonderful.
Example 4:Defect charts, trends and other utter nonsense
Every week I had to prepare defect charts for management. These were extracted from our monstrous defect management tool and presented in brightly coloured useless charts. My manager got so excited at the prospect of producing useless information that she started a pet project to create charts that were more colourful than the ones I presented. She used 2 developers for 6 weeks to create this thing that was meant to wow the senior executives.
In the process of defining the requirements for wowing the big guys, she introduced a few new even more useless charts and consolidated it into an aggregating dashboard. She called it the product quality health dashboard, I secretly called it the dump.
Nobody gave a damn about the dashboard, nobody used the numbers for any reason, nobody cared that they could configure it, but my boss was extremely proud of it. A legend says that she got a big raise because of it. If you play with rubbish, then you will start measuring rubbish and eventually you will end up doing data analysis and showing a consolidated view of the rubbish you store in your code.
How can we avoid this?
1. Focus on defect prevention
Many development teams focus on delivering features fast with little consideration for defect prevention. The theory is that testers (whose time is sometimes less expensive than developers) will find the defects that will be fixed later. This approach represents a false economy; rework disrupts developers activities and harms the flow of value being delivered. There are many approaches available to development teams to reduce the amount of rework needed.
Do you want to prevent defects? You can try any combination of the below:
With BDD/ATDD/Specification By Example or other test first approach, delivery teams test product owners assumptions through conversations and are more likely to produce the right feature the first time.
The ability to have fast feedback loops also allows for early removal of defects, automated unit and integration tests can help developers quickly identify potential issues and remove them before they get embedded into a feature.
Tight collaboration between business and delivery teams helps teams be aligned with their real business goal and reduce the amount of unnecessary features. This means less code and as a consequence less defects. Because, your best piece of code is the one you won’t have to write.
Reducing complexity is very powerful in preventing defects, if we are able to break down a complex problem in many simple problems we are likely to reduce the amount of defects we introduce. Simple problems have simple solutions and simple solutions have less defects than complex ones.
Good coding standards like for example limiting the length of a method to a low number of lines, setting limits on cyclomatic complexity, applying good naming conventions to help readability also have a positive impact on the number of defects produced
Code reviews and pair programming greatly help reduce defects
Refactoring at all times also reduces defects in the long run
Moral of the story: If you don’t write defects, you will not have to fix them.
2. Fix defects immediately and burn defect management tools
If like me years back, you are getting tired of filing, categorising, discussing, reporting, ordering defects I have a very quick solution. Fix the defects as soon as you find them.
It is normal for a developer to fix a defect he finds in the code he is writing as soon as he finds it without having to log it, but as soon as the defect is found by a different individual (a tester for example) then apparently we need to start a strict logging process. Why? No idea really. People sometimes say: “if you don’t do root cause analysis you don’t know what you are doing, hence you need to file the defects”, but in reality nobody stops you from doing root cause analysis when you find the defect if you really want.
What I am suggesting is that whoever finds a bug walks to a developer responsible for the code and has a conversation. The consequence of that conversation (that in some cases can involve also a product owner) should be let’s fix it now or let’s forget about it forever.
Fixing it now, means normally that the developer is fresh on the specific code that needs to be fixed, surely fresher than in 4 weeks, when he won’t even remember he ever wrote that code. Fixing it now means that the issue is gone and we don’t have to worry about it any longer, our customer will be thankful.
Forgetting about it forever means that it is not an issue worth fixing, probably it doesn’t threaten the value of the project and the customer won’t care if we don’t fix it. Forgetting about it forever also means that we won’t carry a stinky dead fish in a defect management tool. We won’t have to waste time re-discussing the same dead fish forever in the future and our customers are happy we are not wasting time but working on new features. If you decide to fix it, I’d also recommend you write an automatic test for it, this will make sure that if the issue happens again you’ll know straight away.
I have encountered huge scepticism when suggesting to burn defect management tools and fix just in time. Only very few seem to think this is possible. As a matter of fact all my teams were able to do this for the last 6 years and nobody ever said, “I miss Jira and the beautiful bug charts”.
Obviously this approach is better suited for co located development teams, I haven’t tried it yet with a geographically distributed team, I suggest you give it a try and let me know how it goes.
Playing with defects waste index:
Epidemic: 90% – The only places that don’t file and manage defects I have ever encountered are the places where I have worked and have changed the process. In the last couple of years, I have heard of two other places where they do something similar but that’s just about it. The world seems to have a great time in wasting money filing, categorising, reporting, trending waste.
Damaging: 100% – Using defects for people appraisal is one of the worst practices I have ever experienced in my long career, the damage can be immense. The customer becomes irrelevant and people focus on gaming the system to their benefit. Logging and managing defects is extremely wasteful as well, it requires time, energy and can among other things, endanger relationships between testers and developers. Trending and deducting release dates from defect density is plain idiotic, when with a little attention to defect prevention defects would be so rare that trends would not exist.
Resistant: 90% – I had to leave one company because I dared doubt the defect management gospel and like an heretic I was virtually burned at the stake. In the second company I tried to remove defect management tools I was successful after 2 years of trying, quite resistant. The third one is the one where people were happy to experiment and as soon as they saw how much waste we were removing it quickly became the new rule. I have had numerous discussions with people on the subject and the general position is that defect management must be done through a tool and following a rigid process.
Things were getting better, the headless chickens that were once running around were a memory of the past and the good folks of team X were now concentrating on a few work items at a time. The frenetic pace had turned into something much more sustainable and people had time to think about what they were delivering.
It had been more than 2 weeks since Gus had been with the team, one morning he decided to pay Team X a visit. When he arrived at their open area, he noticed a strange dynamic. Rick and Jane the testers were huddled over Ricks desk clicking and typing frantically while speaking hurriedly with a worried tone. Ther rest of the developers were sitting at their desks, with headphones on, not a worry in their life.
Gus didn’t even need to ask Rick and Jane what was going on when he looked at their kanban board and saw five cards in the “exploratory testing” column. The team had a WIP limit of five, that meant that those were the only cards on the board.
Gus walked to Rick’s desk and asked “Hi guys, how can I help you?”. Rick immediately goes “Not sure Gus, we are behind with testing and must finish this stuff now, we’re blocking development, they can’t pick any new cards”
“Oh wow” Gus said “developers must be going crazy with you, you are blocking them”, he said it again, louder, making sure that the rest of the team heard him “DEVELOPERS MUST BE GOING CRAZY WITH YOU, YOU ARE BLOCKING THEM”. The ones not wearing headphones realized something was going on, turned and asked what the problem was.
Gus looked at Mike, the senior developer and said “Mike, would you please tell your temporarily hearing-impaired colleagues to follow me to the board, please?” Mike poked his headphone-loving colleagues one by one and told them to follow Gus to the board.
Gus pointed at the board and said “what do you see?”. Silence. “I see 5 cards in a column” Gus continued, “what does that mean?”
Peter , a junior developer, went “well there are 5 cards that need exploratory testing and they’ve been there for a while, this means that we can’t pull any new cards because the WIP limit is 5 and testers are blocking everything”.
“Very interesting” said Gus “well, allow me to retort, what I see is a team that doesn’t understand what flow is. I think that we need an example with something you are all familiar with, like driving in traffic”.
The team moved closer to the side of the whiteboard that they used for drawing flows and sketching UI elements, Gus started drawing parallel lines on the board and continued.
“Imagine you are driving on a highway, three lanes, you are doing 100Km/h and there are a few other cars but it flows very well, you will be home in time for the football game you really want to watch. All of a sudden 10 Kilometers in front of you an accident occurs and from the original 3 lanes, now only 1 is free for cars to go through. What do you think will happen?”
“The cars close to the crash slow down to fit in the only free lane and a long queue develops” says Mike. “Very good” Gus continued “you are 10 Km behind, you slow down to 20Km/h then down to 5 and that’s your speed for the 10 kilometers up to the accident”
“How come you can’t go 100 km/h any longer? The reason is simple, you are as fast as the slowest point on the highway. You could have 100 lanes instead of 3 now, but you’d get out of the bottleneck always at the same time.”
“How would you fix this problem to make sure you make it home for the football game?”
“Well we need to get a truck to take the crashed cars out of the lanes, we need to unblock the bottleneck” Peter quickly goes.
“Very good” Gus goes “the same principle applies to your kanban board, you people are the highway lanes, and the cards coming through are the cars. There is a bottleneck because we have only 2 people working on the full stream of cards”.
“You guys leaving Rick and Jane working on the full stream of work has the same effect of the car accident that leaves 1 lane only in the highway.”
Gus paused, let the people observe the 2 boards, the one with their work and the one with the picture of the traffic jam that Gus had drawn. Then he asked.
“Do you understand that?”
Mike, then Peter than the rest of the team nodded and agreed. “How do we fix this Gus?” Mike asked.
“In this case, there is a simple way of resolving the problem, we remove the car wreck from the highway and we add lanes to remove the bottleneck, how would you do that Peter?”
Peter looked at the 2 pictures a couple of times, he was a smart kid, young but smart, he wasn’t going to give the wrong answer. After 30 seconds, he went
“Well to add lanes it means that the rest of the team needs to help Rick and Jane with what their cards until the backlog of cards is gone and the flow can continue. But this can’t make sense, I am not a tester, Rick and Jane are testers, I am a developer”
Gus swallowed hard, paused for 10 long seconds of total silence and said “Folks, for the moment let’s start like this, all of you guys go into a room with Rick and Jane where they will explain what needs to be done. Once you are up to date, you will help and assist in any possible way they want you to help until the bottleneck is gone. When the bottleneck is gone and flow is re-established we will have a chat about who tests, who develops and what being a cross-functional team means.”
“But I am a developer, I don’t test” said Peter. “Come on Peter, this is an emergency, don’t you see? There is car wreck on our board, we got to clear the lanes, this is making our customers wait? We’ll talk about responsibilities later” said Mike
It sounds like we will have an interesting conversation, Gus thought.
How will the conversation go? Will Gus manage to convince the developers that they need to help with testing? Will Peter win and get to write code only? Stay tuned and find out in the next episode of “A knowledge worker’s tale”
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.