Scrum Master, currently working with an agile coach. The coach has recommended to Senior management that developers should also train to be visual designers in an effort to make the team more 'agile' and vice versa. Senior management seem to think this is a good idea.

I am strongly against this idea since it:

  • negatively discriminates against talented Visual designers who cannot code at a high enough level professionally (with training), as well as the developers who are have in depth knowledge but are not creative enough to be Visual designers

  • Feel that this is unrealistic, many people are not going to be polymaths or have the time to develop the depth to be good at both, which from experience is roughly 3-4 years per discipline. By expecting people to learn both is undermining the complexity of both fields.

  • Feel that the quality of work being produced will be impacted, where at best the results will be a generalist team without any depth impacting quality.

Why do agilists think this is a good idea, and that on the whim they can create teams where members can do every job role with ease. The only time where I can see this working is if people are learning a sub set of their own skill set since it is directly related i.e. a developer learning a new programming language.

  • 1
    Note that the very term "T-shaped" refers to the actual shape of the letter T, with a broad base and a narrow depth. That's not what your agile coach is describing.
    – Erik
    Nov 15, 2018 at 6:40

4 Answers 4


Your understanding of T-Shaped skillsets does not match mine. What you describe is trying to make everyone an expert, which is absolutely unrealistic. I feel a more accurate example of T-shape in what you describe is that the developer may learn some basic design principles in order to make better decisions when faced with them and I would create a shared understanding of the style guide so that many of the basic design decisions covered in the style guide can be acted on by anyone.

On the other hand, the designer should probably understand a lot about the Human/computer touch-points. If you are making a web application, I would expect the designer to understand HTML and CSS. Not knowing these is sort of like a painter not understanding how to effectively work with different types of paints.

T-shaped skillsets do not require deep understanding of all skills. Further, they don't require that every person has every skill in the team. It requires overlap in skillsets so that priority of work can be based on value delivery, not on skill availability.

  • That is not what the coach proposed, coach proposed a dev to learn design skills and switch between the work seamlessly, which requires an in depth understanding of both to deliver quality.
    – bobo2000
    Nov 14, 2018 at 21:38
  • I can't speak for them, but I would definitely ask if they mean that the designer and developer should go back to college and get 2 new degrees to build the foundational knowledge to start becoming equals in each others' jobs. I can teach someone enough to cover basic coding or design tasks in a few weeks, and those would be done a at a professional level of quality, but only basic tasks which would free up time for the expert to focus on the more difficult tasks.
    – Daniel
    Nov 15, 2018 at 2:44

In the spirit of T-shaped skill sets, you may have a point. The whole point of a broad skillset is to encourage a team-first mindset. It's essentially there to encourage flexibility and resiliency in the face of working outside your comfort-zone as a team. Getting trained in a particular skillset, while valuable for cross-function, can cause distraction.

Ideally, formal training shouldn't be necessary. Instead, as always, the team should understand the WHAT and HOW during sprint planning. WHAT do we plan to work on next? and HOW should we plan to meet our goal? In the event a different skillset is identified during planning, the team should also identify how to incorporate that skill into the sprint. If that means re-organizing a new member with expertise in that particular skillset, great. If that means consulting with that expert to get just enough training to meet the goal, great. If comprehensive, formal training is absolutely needed, great. But tradeoffs should be taken into account and made abundantly clear when planning the sprint. Is the opportunity cost of training greater than building towards the sprint goal? If so, training may not be the best route.

In my experience, a team that strives for T-shaped skillsets embody the Scrum values inherently well. But that doesn't mean they need specific training. More often than not, that knowledge transfer happens organically by leaning on the skill experts to get what they need to build towards the sprint goal. Or, if the skill gap is too wide, they identify that and reorganize to incorporate that skill into the team. Both have merits. But it should be left up to the team who is empowered to manage their own work.

My hope is this coach worked with the team to identify the issues with skill gaps and facilitated a solution with them before going to senior management with recommendations.

  • No she didn't, it was her own recommendation based on being an agile coach. I get that was her way of filling in a skill gap, but what I didn't understand is why she didn't just propose to hire whats needed as opposed to going through the costly exercise of training people up which could take a long time before there is a return of investment - providing of course, they have the aptitude to learn the skill with the depth required to do it at the level we need. Hence,thought it was a stupid idea.
    – bobo2000
    Nov 14, 2018 at 19:29
  • 2
    What I'm more interested in is why she chose to facilitate this without team collaboration. Sounds like there's an opportunity to touch base with her to get a better understanding of why she chose to recommend process in lieu of collaborating with individuals and interactions, the tenant value of the agile manifesto. Making recommendations without team input is an anti-pattern of an empowered, self-organizing team. Doing so takes the ability for the team to solve their own problems out of their hands and directly into her's. Nov 14, 2018 at 19:34
  • 1
    Good point, I don't have the answer to it; I suspect it is because she felt that as an agile coach its her responsibility to make recommendations. As far as I know, it hasn't been actioned on, but if it does it will definently cause a lot of problems with the org from people affected disagreeing with it.
    – bobo2000
    Nov 14, 2018 at 19:39
  • 2
    I'm wary of agile coaches that make recommendations without the team's input. I'm more open to agile coaches that poke the team with questions no one else is asking or willing to ask in order to facilitate problem solving with the team. From what I know of the situation, your concerns sound reasonable. I hope it's addressed so as not to impact your team adversely. Nov 14, 2018 at 19:43

That sounds frustrating!

Why do agilists think this is a good idea, and that on the whim they can create teams where members can do every job role with ease

As others have said, this is not what T-shaped means. The T shape indicates deep expertise in one area, and shallow expertise ("working knowledge") in other areas so as to be able to pitch in as needed.

The agile team (and particularly the scrum team) is supposed to be self contained in terms of the skills necessary to deliver the product. Ideally, that means that if the project needs a visual designer, there should be a visual designer on the team. That would have been my first choice recommendation.

But it's not always feasible to do that: maybe there isn't enough work on the project to fully occupy the expert, or maybe there are experts in house but not enough to support every team. In that case, one possible solution would be for other team members to acquire enough knowledge of the expertise that they can work under the direction of an actual expert who would be available for consultation, or available part time. That would have been my 2nd recommendation.

If neither of those was feasible, then I would point out the risks of building a product without the necessary expertise to do it well. The risk will depend on how important the expertise is to the success of the product.

It would be interesting to know whether the coach was given any constraints when she started the job. (eg, no new hires, preference for growing teams rather than hiring in)

As SM, it is within your role to raise concerns that are inconsistent with Scrum or would negatively impact the team. Sending people off to train would split their focus and reduce their capacity for an extended period of time. The proposed solution cannot be executed in a short time horizon, and is in that sense not agile (long investment needed before return). And you still don't have a needed expertise.

Good luck!

  • Like you alluded to, even if there is a skill shortage for a short period of time, I just don’t understand why she didn’t suggest hiring a contractor. The risk is less from no training cost. Just mental. By the way from experience having a shallow understanding of a skill is great for collaboration and being mindful but not good enough for doing the work at the level needed professionally. The coach had no recruitment constraints, she just felt it was the right approach when team building.
    – bobo2000
    Nov 15, 2018 at 11:59
  • I find it puzzling, too. Do you have the opportunity to ask her? Nov 15, 2018 at 12:00
  • No not yet. To be fair on her, I have heard other agilists interpretate T Shaped teams this way I.e. teams where people are multi skilled in completely different disciplines.
    – bobo2000
    Nov 15, 2018 at 12:02

I think you have to first clarify with your Scrum Master the definition of a T-shaped individual and ask many questions to fully understand what are the expectations and how it is going to get implemented. As some have mentioned the definition of T-shaped doesn’t seem the right one.

In my experience being a T-shaped individual has several advantages:

  • People are much more cooperative, and they can take tasks that don’t require mastery in a different discipline if it is needed.
  • They understand better the work of others and empathize with their work, difficulties, etc
  • People tend to be more open-minded about new ideas and find it easy to adapt and learn new things

I don’t think it is a must have, or even a nice to have. Some people are T-shaped, some love doing their core discipline all the time, but having a mix, can prove to be healthy for a team. One last thing to comment, I think you have to give people options, but not enforce them (which seems to be the case of what your Scrum Master is planning).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.