Odtnhj

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.

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.

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.

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!

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).