Leaders and bullies

Many moons ago, my confidence was at its lowest. For a few years my leader had convinced me that I was worthless. I remember the feeling of hate I had for my job and at the same time how lucky I felt to have that job, because I was so useless that nobody in their right mind would give me another chance.

If you know me well and read this, you’re probably thinking that this is a fictional story, in fact I am an extremely (too much some say) confident person. But no, this is the truth, I was at my lowest and the reason was that my leader had bullied me into a ghost.

When, after years of pain, through the help of a colleague and the support of my friends I saw what was happening to me and realised the psychological violence I had been subjected to, I decided that leaving the company was not enough and I wanted to do the right thing by coming clean on what had happened.

I went to talk to my leader’s boss and explained what happened. By then I had an overwhelming amount of data that unequivocally proved that systematic psychological warfare had been used against me. Not only me for that matter, other people were receiving the same treatment.

My leader’s boss was very sympathetic and said that I was not the first one that reported that behaviour. He also ensured he was going to act upon my complaint.

Little I knew, he was playing a game. He delayed and delayed his intervention, once even faking that his flight had been cancelled on the day we were meant to meet Human Resources (I checked with the airport and no flights had been cancelled that morning). That Same day i had to go to a doctor, because my depression had reached a point in which I was unable to face going to work.

Eventually, tired, disappointed and broken, I decided to simply leave it as it was as I knew i was trapped between a bully and a spineless bully enabler.

That was that, i left and life went on.

Nobody loves a bully, bullies are massive problems for organisations, but worse than bullies are unhelpful knowing managers that by not acting and stopping the bullying perpetuate a culture that accepts it.

If people are afraid to talk about things, true leaders will investigate and find out why it is happening and when they find out that the problem is a bully, they will act promptly. If I found out that one of my people was a bully, i would try to help him trough coaching, and if it didn’t work I would have to defend the other people and the bully would have to go, no two ways about it.

When a leader does not act firmly, also sends a signal to his people that bullying is ok. When this happens, bullying becomes part of the organisational culture. Leaders, it is your responsibility to make that not happen.


How a little man from Japan helped Team X focus on their customers


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





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


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!




How a highway car wreck can help us improve collaboration

A knowledge worker’s tale 5th episode.

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.

“Oh Damn!” Gus thought, “non-testing developers alert…”

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.

Read until you find it, it’s subtle


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”

The new episode is out, find out what happens!


Not doing something useless is very valuable


The first thing we tried to do once we had set the WIP limit (see last episode) was to start working on 5 only of the 60 cards we had on the board.

A few suggestions were thrown in, Gus mentioned a possible approach where if something is closer to the right of the board, i.e. is closer to be finished and delivered to production, then it should get precedence. This way the team could take the 5 rightmost cards and start working on them and ignore the other 55.

This sounded like a decent idea and got some nods from the team, but Fritz the business analyst had a secret that was breaking his heart, he slowly raised his hand, head slightly down and said “Lads, I don’t know how to say this, but,  since we visualised the work on the board and I can actually see what you guys are working on, I started to realise that there is a bunch of irrelevant cards. Some of them are outdated, some other are plain wrong, I am so sorry”

The team were not happy, Mike, a senior developer, said “What do you mean outdated? Wrong? Why did you give us wrong and unnecessary work to do? Do you know how busy we are?”

new-meme-i-am-going-to-kill-you-now_o_153496Fritz was blushing and wasn’t sure how to answer that question, he gathered his thoughts and then said “Folks, don’t take it out on me, but you well know that when the customers came brandishing tickets, we just took them on and started working on them, no attention was given to whether they were there to improve some older card or made them irrelevant. Our inbound pipeline is running wild! Before we had WIP limits and visualisation I didn’t even know how to tell the customers they had to wait”

Mike was furious “Are you saying that half of the work I do every day is irrelevant? This is unbelievable, I am going to kill you!”


“Hang on, hang on, hold your horses Mike” said Gus “where you see something bad I see a massive opportunity for improvement. Listen to me carefully, here’s the plan: we take one hour to look at the board with our customers and identify the irrelevant cards. Removing them is a massive value added activity, imagine all the work you will save by not having to finish them! This is great news! After this we will have less cards left and choosing the most important 5 to start with will be much easier. It’s not an issue it’s an opportunity to improve our work stream. Fritz, thank you so much for being brave and showing the problem to us! ”

“And don’t worry Mike” Gus added “I will not forget that we have a problem managing our incoming work, we will fix that straight after”holdyourhorses.jpg

Fritz was a bit relieved, Mike still not too happy.

We got on to it, and we soon found out, that the problem we had was even bigger than what Fritz described. Within 40 minutes we had removed 22 irrelevant or wrong cards, that would have represented at least 2 weeks work if we kept on working on them.

Some of the cards on the board were so old that the customers didn’t even remember what they were about…

While removing cards, the team, including Mike, started focusing on the positive, i.e. the work that they didn’t have to do because of the removed cards, rather than the work that they had already done on those.

The atmosphere improved substantially, from death threats, to group high fives every time we took a card off the board. The board itself started to look a bit cleaner and all we had to do now was to identify the 5 most important cards to work on, easy peasy lemon squeezy.

Once we finished,  Fritz, finally freed from his secret, said “Folks, I would have never been able to do this cleanup job using the digital backlog, seeing the tickets on the board opened my eyes”

“Well” added Mike “after all it looks like, a picture” pointing at the board “is better than a thousand words in Jira”.

The team had a laugh and got back to work with a smile on their faces.

The 5th episode is out, what are you waiting for? Read it here!




Limiting WIP should wreck your head

Previously on “A knowledge worker’s tale”: team X were able to convince Zach the customer that he could not have new tickets worked on until the ones he had in progress were completed, unless the new ones were more urgent and replaced the older ones.

stop-starting-and-start-finishing-6Having the ability to talk sense into Zach with little effort felt good, the team was energised, they had a new tool that could help them talk to their customers, but the initial problem still stood, the board still contained 60 in progress tickets and it was not going to clear on its own.

They were still in front of the board after the conversation with Zach when Gus said, “guys, do you remember when I suggested we visualise the work in progress and you didn’t want to waste time doing it because you were too busy?” “Yes” said Rick the tester.

“You didn’t believe me back then, but you made an effort and trusted me. Things worked out well back then” said Gus. “Well I need you to trust me again, because what I am going to tell you now will feel very strange and some of you will immediately think that I have gone insane”

The lads looked at each other and silently agreed to listen, after all, he was right before, let’s give him another chance.

Gus started “How many people are in this team excluding me?” The lads looked around and mentally counted when Rick said “8, we are 8, 5 developers, 2 testers and 1 analyst”.

Gus said “Fine, then let’s start with a Work In Progress Limit of 5, this means that the team can only work on 5 cards at the same time, no exceptions, I mean you can’t pick up a 6th card if you haven’t finished one of the first 5, never, absolutely never. Did I say no exceptions already?”

The team looked around to each other with quizzical faces, they could not believe their ears, from the board they saw they were working on 60 items at the same time, and that was certainly too much, but 5? Five cards was ridiculous.

How team X saw Gus when he said “well, let’s start with a WIP limit of 5”

Rick went “Come on Gus, are you joking? Five cards? It’s ridiculous, we’ll never finish, will we?” Jimmy added “Also, if we can work on 5 cards only there will be 3 of us that do nothing every time, how do we justify this to our customers?”

“Very good questions lads” Gus said “Let me answer them in order. Rick, you say we’ll never finish, instead I say we will finish more cards. In fact setting a WIP limit low, forces the team finishing a card instead of starting a new one. In order to start a new one, you need to finish one before that, this will force you to complete the work. Your new motto will be “Stop starting, start finishing”. Does this make sense?”

“As per Jimmy’s question, not exactly. There won’t be 3 people doing nothing at the same time, because you guys will be pairing and working together on tasks. Pairing on a card, no matter what activity you are doing, has 3 great effects, you share knowledge, the quality of the card is higher and the card gets done quicker. And remember, it is not important to be busy, it is important to be doing the right work at the right time. Stop focusing on whether you are busy or not and start focusing on the most important work to be done.”

Gus went to the board and wrote on the very top a big 5, that meant only 5 cards could be at the same time on the board NO EXCEPTIONS.

The team started to understand what that meant but still felt uneasy. Rick said “this is not going to work Gus, I am very worried about this”

“That’s perfectly OK Rick” said Gus “if you weren’t feeling uneasy I would be surprised and also worried, WIP limits are a traumatic change for a team, you will find it difficult at first and it will cause a lot of discussions within the team, even some heated ones. Believe me or not, these discussions are necessary, because you need to change the way you work so that you can start finishing and stop starting”

“You know what?” added Gus “let’s give this a try, if it doesn’t work for you, we will go back to picking up as many stories as you want, but you need to give yourself 2 weeks with this experiment, are you with me?”

“Let’s do this” the team said.

Will team X be able to respect the WIP limit? What will they discover while they try to adapt to the new reality? The new episode is out! Read and find out.

The magic talking board

This is the second episode of the adventures of team X, if you haven’t already, read the first part of the story

Things looked slightly less grim now. We had visualised the work that was coming through and at least we could see how deep the hole we had dug for ourself was.

For a team of 8 (programmers testers and analysts) we had something like 60 work items in progress, it was gigantic, daunting and scary.

But that was huge progress, because now we knew it was there. Now that we could see it and show it, we could do something to stop it from happening again.

messy-deskLittle we knew that what we had created was not only a board, what we had created was a living and talking entity, you don’t believe me? Read on.

The morning after we built the board, Zach appeared, he was the most unreasonable customer in the Northern hemisphere, known for his famous saying “take this ticket, if you finish it last week you are late”. He walked hurriedly to the team area with his usual bunch of new unbelievably urgent tickets to work on.

While he was walking, I swear, I thought I heard the music from “The good the bad and the ugly” such was the tension in the air.

Jimmy, a developer, told him: “Hey Zach, yes, we will work on them but we need to finish these first” pointing at the board.

Zach wasn’t happy, squinted and said, “but this is urgent! I need it now!”.

Jimmy was relentless, looked at the cards that Zach had already in progress on the board and said “that’s fine Zach, no problem, have a look at these cards on the board, they are your 6 tickets already in progress, if your new two are more urgent then let’s replace them”.

Zach eyes widened with disbelief, looked at the other cards and said, “but, but, but… I, I, I… need, need , need… …well no, those are more urgent, work on these new 2 only once you are done with the old ones”, he said goodbye and went back to his office.

From Top to Bottom: Jimmy, Gus and Zach

Jimmy the developer had defeated Zach, the fastest ticket-slinger in the company!

The team X guys looked at each other, high fived Jimmy and noted that the board had told the customer what they had been trying to say for the last 2 years, i.e. “we are too busy we can’t take more work”, but for some magic reason now that the work was visible, that conversation was much easier and Zach was not shouting anymore, miracle!

This small event made the team determined to always make sure that their work was visible on the board, the board was a silent ally, they won’t forget to feed it!

If Zach had been brought to reason, what else could the board help them do?

Gus said, now the fun starts, let’s talk about setting a WIP limit…

Wanna know what happened next? Is the WIP limit going to make the team even more powerful? Stay tuned for the 3rd episode to find out what Jimmy and the team X lads get up to!

The new episode is out!