The official T-shape

In Agile, for a very long time, there is talk about T-shaped people: people who are good in a specific skill, but also do have a lot of knowledge, but only in a small amount, about other stuff. While this would make Agile a lot easier, it very often doesn’t work like that. How do problems like this work? Well, in reality, problems with knowledge and skills are handles with another T-shape: the shape based on trust.

What is the difference? Let’s first have a look at the goal of T-shaped. The goal is that more people in the team can handle a job in the team. While there might be one expert, there are people who can often take over or help out. That is if the job is prepared or just doesn’t ask that much skill. This creates a more stable team, that doesn’t have to stop with every problem.

In reality: yes, it could work. I’ve seen it work. I’m a tester and I’ve been in situations where team members were willing to help with testing. I’ve trained and helped developers becoming better at testing. But, if they can, they will take every possibility to not do this task. Because they don’t like it. In good teams, they understand it’s needed and do it anyway. In normal teams, they will arrange that testing isn’t needed. For example by just delivering less or nothing in that sprint. In a bad team, they will just not do it and let the mess keep happening.

You see the same when it comes to other shared responsibilities: making a sprint planning, giving an estimation for a story. They will do what they need to, but they will skip or avoid it when possible.

I don’t like that. But I’ve learned to accept it. So if no one in a team will test, a sprint planning is made by the product owner, or any other responsibility is only done by 1 person, I no longer protest. Also because I learned about the real T-shape in Agile

The real T-shape

I learned that the real T-shape is not based on knowledge or skills, but based on trust. Problem is, that due to Agile and team habits conflicting, trust and no trust very often look very much the same.

Let’s take the most difficult subject: a product owner that creates the sprint planning. Something that almost everyone with Scrum knowledge disapproves of because the sprint planning should be done by the whole team. Why is that? This is the belief that a reliable planning can only be made if every one of the team can give their input. And let’s be clear: I still believe this is true.

And I saw what happens if this knowledge isn’t used. Sprint plannings that were never reached. The product owner promised something, planned accordingly, and then didn’t get it. Because the goals were unrealistic. Because the team didn’t feel they could give input on the planning.

So why not share it? Why not use T-shape as a guideline: let the product owner give the main part of the planning (with his/her knowledge of the backlog) and then create the planning with the team? Because of what I also noticed: people started caring less about the planning when they were forced to spend time on it. They saw it as an obligation and no longer as something they could give important feedback on. Just something to get through, to get back to the real work. It became a waste of their time. And no, that did not lead to reliable sprint plannings.

So, what then? Well, I noticed something in good Agile teams. Everyone was doing of course, what was part of their job. Certain tasks, like planning, but also some research or devops jobs, were done by only 1 or 2 members of the team. They became experts and didn’t automatically share their knowledge. And as long as there was no problem, this continued. As long as the trust was present that a person would do a good job, that person could continue. When not present, the work would be adjusted accordingly.

That is until a problem started occurring. A person would not be trusted anymore by the team. Not as much at least. Mainly for two reasons: a person got overwhelmed with work. Or he wasn’t good at his job.

What would happen? People would start compensating. In a good team that is. (the bad team I will mention later). If the skill wasn’t shared, other people in the team would start learning the skill. If possible, less work would be planned for that person. And if a person was just not capable, other people would take the more difficult work and leave the easier work for the struggling person.

So back to the planning. As long as the planning worked, management wasn’t complaining and the team also had no reason to complain, no one minded that a product owner did the planning. It saved a lot of time because the planning session was a lot shorter. And it caused no problems. But when it wasn’t….. other team members started giving remarks. What was missing. What was unrealistic. Planning sessions got longer, but it was the team that wanted that. So there was almost no one that complained about that. It was seen as something that was needed.

What I’ve learned myself

A lot of best practices and rules in Agile and Agile methods are based on bad experiences. Situations, like mentioned before, where people weren’t able to give their input on planning, even if they wanted. Or weren’t able to help with testing, even if they wanted. So based on that they became things you should do to be seen as a good Agile team or Scrum. The problem is: forcing people to do what they don’t want isn’t creating an Agile team. And because of that, the result isn’t good planning or good testing. They should want it themselves.

A team will not do something if they see that someone in their team is willing and capable to do a job well, often even better than they can. Why should they spend time on that? Their time is better spent on what they are good at. And the strange part is: if you let them, there will be almost no problems.

If there are problems, a good team will handle them. They will find a solution and solve it. By dividing the work, changing the planning, giving their input.

A good team

But what is a good team? A good team is a team that wants to deliver a good product on the promised deadline. So it cares about more than their own work. A good team is a team that can talk to their management about problems with team members, lack of tools, lack of time, etc., and do not get the message ‘just deal with it’.

If the team doesn’t care about time or quality in general, they will continue with their work. And don’t want to solve the problems. If management doesn’t help, the team will lower the expectations of their work. So they don’t expect to be done with their work before the deadline. Or don’t expect a good product at the end.

When team members trust a person to do the job, give that person that trust. Even when you are not in the team. Even if it’s against everything you heard or read about Agile. When that trust starts disappearing, take it seriously and help them find a solution. Yes, it might have downsides sometimes, but in general, it’s better than the alternative: a team with persons that are just doing their job. 

Motivate the team to finish before deadlines and deliver a good product. If they do not seem concerned about it, trust that they are right. If they are concerned, give them the tools to do something about it. No matter if you are in or outside of the team.

Trust the trust and give the trust. So long as you have no reason to do otherwise. So you can create a good Agile team, even if it breaks some known Agile methods rules.