Cross-dysfunctional teams

Every agile enthusiast will tell you how powerful an empowered, self-managing, cross-functional team can be. Once you have one, it brings complete team accountability from product idea to customer support, it naturally grows with continuous improvement, and finds self motivation in innovation and delivery of customer value.

It’s a beautiful and powerful concept; the practical implementation sometimes is not so beautiful and more often than not what you get, is a cross-dysfunctional team.

Let’s have a look at the cross-dysfunctional examples I have experienced.

Pseudo specialist cross-dysfunctional teamfarm-silo

Developer: “I am a developer I am not meant to test, the testers test!”

Tester: “I don’t need to know anything about how the product is designed, I only care about how the customers use it!”

Business Analyst: “I am not technical, I can’t help you guys!”

devops“As Long As It Works for us” cross-dysfunctional team

Developer: “It works in our environments, it’s operations responsibility to make it work in production”

Tester: ”Listen, it worked in UAT, it must be a configuration issue, or a missing firewall hole and nothing I could have spotted during testing…”

Customer: “Hello! Nothing works here…”

Abdicating cross-dysfunctional teamheadinsand

Developer: “The architect told me to do it like this”

Tester: “Feck it, let the Test manager deal with it”

Business Analyst: “I don’t think there is any value in this story, but the Product Owner wants it, so get on with it and develop it!”

no-thanks-were-too-busyContinuous Decline cross-dysfunctional team

Developer: “No point in doing retrospectives, things are always the same”

Tester: “We DON’T HAVE TIME to try new things!”

Business Analyst: “We do it like this, because that’s how we do things here, and that’s it!”

Disintegrated cross-dysfunctional teamWorked-Fine-In-Dev-Ops-Problem-Now

Developer: “My code works perfectly, it’s their system that doesn’t work, who cares”

Tester: “We have 100% coverage, all our tests pass and we have no bugs, if the developers of system X are idiots, there is nothing we can do about it”

Customer: “And still, nothing works here…”

ihazsuperiorityNazi cross dysfunctional team

Developer: “Testers are failed programmers, they shouldn’t be called engineers”

Tester: “Developers are only able to produce bugs, the world would be better with more testers and less developers”

Business Analysts: “I don‘t know why I bother talking to testers and developers, they are total idiots”

Do you recognise your team in one of the categories above? What have you done until now to help your team change? Little? Nothing? But you are still bitching about it, aren’t you?

Remember, you are very powerful and can become the change that you want to see.

Be lean, ask “why?”


Your best piece of code is the one you won’t have to write.

Yes I am serious, and no, I am not intoxicated, let me tell you a story.

It was a sunny summer day in Dublin and “the three amigos” (Tester, Developer and Product Owner) were discussing the next user story to deliver.  It all started as usual with the Product Owner explaining what we were meant to do and as the story was quite small and easy we were soon starting to write our examples that would become acceptance tests and eventually code.

Everything was going smoothly, we had already agreed that we would add a field to our payload with the new information, until out of the blue, the tester said:  “why? I mean, why do we need to do this?”

The product Owner said: “Because we need to send extra information to customer A!”

The tester insisted: “But why do we need to send it to customer A?”

The product Owner said: “Because we always send it to system X so that it can create product Y”

Then the tester said: “But customer A doesn’t use system X and doesn’t sell product Y, so why do we have to send it?”

The product Owner said: “You might be right, but Mr. SuperBoss said he wants to send it!”

The tester said: “Well, we need to ask Mr. SuperBoss WHY he wants to send it”

The product Owner stood up, went straight to Mr. SuperBoss and asked him.

The fact is, there was no reason, we were wrongly assuming that customer A would need it.

Would you agree with me that the code we didn’t write is super clean, extremely cheap to develop, test, deploy, maintain and sunset?

It only ever costed a conversation, and a few whys, I bet you can’t do it much cheaper!

If you don’t see the business value of what you are delivering, ask for it, you might get a nice surprise and find out you don’t need it at all.

The wrath of the mighty metric

Reasons why some software delivery teams don’t give a damn about their customers

It feels like a century ago, but once upon a time, less than a century ago, I was leading a traditional test team in an organization where 3 separate teams of Business Analysts, Developers and Testers were delivering software in an incremental iterative death march style. Each of the 3 teams had its own leads and managers and each of the 3 teams was measured by specifically tailored metrics. My team’s efficiency was to be measured based on the mighty DDI Defect Detection Index calculated as DDI = (Number of Defects detected during testing / Total number of Defects detected including production defects)*100. The DDI had to be greater than 90% otherwise our team would have been deemed inefficient, bonuses dropped and the test team itself branded as a bunch of losers.

Yes you guessed right, the other 2 teams were measured in a similar way, their efficiency was also based on number of defects, the lowest the better.

God I am glad this is only in the past. Even remembering this makes me sick in the stomach. Sick like every time a production defect was detected, sick like every time a defect that our team detected was rejected, sick like every time I had to go to the triage meetings and inevitably have an argument either with the BA lead or the DEV one because that defect that we found was not seen as a possible improvement for the product but as a threat to some team’s metric. I’m not even going to describe to you the awful discussions that followed the acceptance of a defect as valid when a decision had to be made on whether the defect was due to bad requirements or bad code.finger-pointing

The funny thing was that no matter which was the efficient team and which were the inefficient ones, the software delivered was the same, no change whatsoever, the customers were constantly quite unhappy. The real value that the metrics gave to the department was the ability to point fingers based on numbers. They say numbers never lie, maybe numbers don’t lie but how many lies can we tell to fabricate numbers?

Since then many things have changed in my professional life and today I don’t have to fight stupid battles to fabricate numbers in order to define efficiency so I can, funnily enough, use my time more efficiently.

Why calculating confrontational metrics doesn’t work? The problem is in the fact that we are humans; if you attach prestige and monetary value to a metric, the metric becomes the goal of the team and the battle can begin. The test team doesn’t care how useful the product delivered is, all they care is opening as many defects as possible so that the mighty DDI doesn’t go under 90%, if this means opening defects that are absolutely no harm to the customer but only to the development team and the schedule it doesn’t matter. The same logic can be applied to development and the BA teams that will spend their time obfuscating their requirements and defending their code from the stupid defects opened by the test team. All this creates a climate of tension, distrust and hostility. Nobody really cares whether the customers are happy as long as the individual teams metrics solemnly declare their efficiency and fingers can be rightly pointed :-(.


The funny thing is that it is very easy to resolve this problem and put the focus back on the customer. Create a cross functional self organising team able to analyse, develop, test and deliver a complex software project and judge the team on how well they satisfy the customer needs. The team lives as one, produces quality as one, delivers customer value as one, succeeds as one or fails as one. The goal of the team matches the goal of the company and failure or success of the team determines failure or success of the company, it’s called agile team, try it out!