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.

Get in shape to become an Agile Tester

The perfect Agile Team member as seen by Leonardo
The perfect Agile Team member as seen by Leonardo

Do you want to become a strong agile tester but you don’t know what to do and are scared by the challenge?

Worry no more you are in the right place. We are going to help you get in shape so you can become a strong agile tester and be a very valuable part of your team. We’ll get you into the shape of your life without taking any magic pills or spending half your day in the gym sweating and swearing. You will be able to eat all the food you want and even smoke and drink without losing your shape, just read this article and let your mind wonder.

FACT: There is only one shape that will make you an unbeatable agile tester, it’s called “T shaped Agile Tester”.

Let’s get you there!

What shape are you in now? If you are here trying to get better, chances are you are an I-shaped tester with one dimension only “TESTING”. You know a lot about testing, it has been the focus of your career; research and experience have made you a solid hard core tester. This is what you look like now:

I-shaped Tester
I-shaped Tester

All your research and experience has been targeted at giving you a strong TESTING body. Nobody can say you can’t test, but can you do anything else? Maybe a little but not too much because all you have been involved in has been testing, testing and more testing.

Now, listen to this; what happens when you are finished testing and can’t get anything more to test because your business analysts or product owners are behind and can’t cope with the work flow? Do you sit at your desk and research how to become a better tester? Do you simply say, “Tough shit, when I am busy nobody helps me” and carry on in your trip to testing stardoom? Yes I didn’t spell it wrong, I meant to say star-DOOM. Doom for your team that is stuck on an activity and can’t get things going because the only specialists are swamped. Wouldn’t it be better if you could sit with your BAs POs and help them do their job? Well for the teams economies it sure is.

But, how can you achieve that? Well, listen ,nothing easier. The first thing I would do is ask your BAs if they need any help. If they think you can’t help them because you don’t know what to do, then ask them to sit with them and try to learn what they are doing. I guarantee 100% that you will learn something from this activity and also earn the respect of your team mate.

What if the people to be stuck are the developers? They have been fighting with a complex technical issue and they haven’t been able to deliver anything to you in the last week. You’ve been bored to death and alternated trips to youtube to trips to the toilet and the coffee station. I bet that sitting with the developers you would have not only learned something, but you would have also enjoyed yourself helping and discovering that what they do is not as different from what you do. They would probably be able to give you some easy tasks that you can help them with and together with helping the team you would be learning new skills. This sounds good to me, how about you?

Then you could have gone back to your desk and researched the topic the developers were discussing getting some more knowledge and becoming more able to help them.

By helping and collaborating you are going to get better at the other 2 activities, analysis and development. You won’t be as good as them but not as useless as you were before. you will grow an extra dimension you didn’t have before and become T-shaped.

T-shaped tester
T-shaped tester

As you can see from the picture, by gaining experience on the other fields and researching them your legs are slowly opening making you more stable and broadening your ability to support the team. Once you start gaining some cross functional knowledge you will be able to open your arms and support the team, isn’t that great? Imagine how much more valuable you have become now that you can use your new knowledge to help the team remove bottlenecks. Imagine how much more employable you have become. An don’t discount the chance that by learning something different you might even find your real vocation!

You might say, yes, learning is fine and helping is good, but besides that and becoming more valuable, what’s in it for me? This is the easiest part and you will love it. The next time you are stuck with 100 things to test and no time, you can turn around and ask 2 people to help you, one BA and one developer, the ones you helped before! They can pair with you and help you unblock the current bottleneck and get the system unstuck.

Because there are not only T-shaped Agile Testers, but also T-shaped Agile Developers and T-shaped agile BAs and POs.

T-shaped team members
T-shaped team members


So stop being a boring I-shaped specialist that is going to be out of a job soon and become a T shaped Agile Tester, you will be more valuable to the team, more employable and best of all never stuck on your own testing like crazy because your colleagues don’t know how to help you! Welcome to the world of cross functional agile teams where there are no roles but activities!

He knew stuff about proportions
He knew stuff about proportions

P.S. Credits have to be given to the original inventor of the T-shaped Agile Tester, Leonardo Da Vinci. He initially called the concept “Vitruvian man” but soon came to realise that what he had created would change software development forever and renamed it to “Agile T-shaped team member”. You won’t find a reference of this fact in books, but I know it because he is my friend on Facebook and he mailed me last week to tell me how he wanted to use his concept to help Agile Teams. He is retired now and not much of a talker, so I told him I would help his idea spread.

P.P.S. The real credits for the T-shaped people concept go to the work of Adan Knight and Rob Lambert, see and for more details.