The contradictions between agile approach and the growth of individual team member

Question

Agile approach in project management has become more popular than ever, where it emphasizes T-shaped talents in the team and value cross-functionality a lot in team members. I wonder does it contradicts with, or at the expense of, the expertise development in individual team members? For example, a software engineer can be assigned to UX design tasks in the name of agility; however, from career growth aspect, if one's target is to be very specialized and an expert in a single field, is agile not healthy for that individual? Thus, the questions stemming are:

i) that's based on what I've seen in the industry. Is this agility malformed?

ii) if not malformed, how can that ambitious individual handle the situation other than quitting?

Thanks in advance.

Answer 1

Let's unpack this a bit:

For example, a software engineer can be assigned to UX design tasks in the name of agility.

Agility is something people want to achieve because they can respond faster to changes or new information, and because they can create value faster and in a more continuous manner. It's a mindset. It's how you approach the things you do. It's what's guiding you.

Many companies unfortunately don't understand this. They approach Agile by starting to do practices from Agile, without actually understanding what they mean. All of a sudden, everyone is a developer now, because the team needs to be cross-functional. So the backend developer needs to pick up UX design, right?

Not at all!

Cross-functional means that the team members have all the skills necessary to create value and deliver the product or product increments without depending or waiting on others to do their thing. It doesn't mean that everyone does everything. You still can have specialized skills within the team, but the team as a whole has within it all the skills it needs.

And these people collaborate with each other and work closely together. And when that happens well, you end up with T-Shaped developers, because inevitably you need to understand what someone else is doing. It's a collaboration. You don't throw work over the fence at each other, like "I've done my job. Now it's your job".

So inevitably you start to understand what others are doing, thus the breadth of knowlege. But you still retain your depth of knowledge if there is specialization. Agile doesn't say to get rid of this.

But the collaboration forces you to learn new things. If people want to be purists within their field of specialty then most likely they will not like Agile or won't be properly engaged within the team. And yes, there is the risk they will quit.

And if things are forced upon them (like a back-end developer having to pick up UX tasks) then most likely they won't like it either. And yes, there is the risk they will quit. But this has nothing to do with Agile, but with making bad decisions about how work gets allocated within the team (which needs to be decided by the team, by the way; not by someone external to the team saying that anyone can pickup UX design).

To be Agile you need to work in a certain way that makes you step out of your specific skills zone, but that doesn't mean you need to sacrifice your individual expertise for it. It's not one or the other, it's both.

Answer 2

T-shaped skills mean that skills are shaped like the letter T: deep in some places, shallow in others. That is, skills are expected to be specialized, but with some sufficient understanding of adjacent disciplines to allow for effective collaboration. There is no contradiction between T-shaped skills and specialization. T-shaped skills imply specialization.

And with that, let's take a look at the travesty that you call agile:

a software engineer can be assigned to UX design tasks in the name of agility

In agile, developers aren't "assigned" work, let alone in the name of misunderstood buzzwords. In agile, developers form a self-organizing team. That means the team discusses who should do what. If, during this discussion, somebody suggests that Peter, the experienced software engineer, do UX design tasks, Peter is likely to speak up and mention that he knows little about UX, and that it would be more efficient and effective if somebody with better UX skills did the work.

Now, it might still happen that Peter doing UX work is the best call. Perhaps the UX guys are swamped because one of them has the flu, so there isn't enough work for the software guys. But if this is a frequent occurrence, and in particular if Peter doesn't like UX work, Peter will likely speak up at a retrospective, identify this as inefficient (or annoying) and ask the team to explore ways to improve. And the team, being judged on its ability to produce working software, has a strong incentive to do so.

In short, the situation that people are assigned work they aren't qualified for, in pursuit of the management buzzword of the day, doesn't tend to occur in agile practice, because the imbalance of power that makes it hard for Peter to point out how asinine an idea this is doesn't exist within an agile team. And if the team fails at organizing work in a way that makes effective use of the available talent, agile process frameworks give teams both the incentive and the opportunity to fix this.

if one's target is to be very specialized and an expert in a single field, is agile not healthy for that individual

Depends on how specialized you want to be. An agile team has a limited size, and must encompass all skills necessary to deliver the solution, and in sufficient redundancy. This limits the number of different specializations a team can have. However, depending on the nature and size of the project, the set of skills needed may be very diverse, and specializations comparatively broad, or rather specific and comparatively narrow. For instance, if a team of 2 writes a full stack application, you likely need two "jack of all trades" devs capable of doing UX, implementing UI, business logic, database access, deployment and support. If however a team of 12 is tasked with replacing a set of webservices in a particular application domain, then database, security, business logic developer, domain expert, deployment and support may all be separate specializations. So if you want to specialize, look for big projects focused around your area of expertise.

And if you want to be extremely specialized ("the world's leading expert on this particular area of this particular framework"), it might be better to exist outside project teams, to be consulted only if they have a problem in your specific area of expertise.

(None of this is specific to agile processes, by the way. Even the most old-school waterfall project will want the team to have all the necessary skills, and insist on sufficient skill redundancy to ensure business continuity.)

The only time agile has any bearing on specialization opportunities is with misunderstood agile. Specifically, if the absence of formal hierarchies within an agile team is communicated as "everybody should be equal", but understood not with respect to the social hierarchy, but with respect to skill sets.

Answer 3

All organizations value specialist skills. I think the question here is about how narrow and exclusive any specialist should be. To succeed in the technology professions requires almost constant adaptability and willingness to relearn. These aren't just the expectations of agile teams, they are the necessities of working in a very rapidly changing field.

If your specialism is too narrow then your usefulness is limited and your market value is diminished. If you lack knowledge outside your specialism then you are bound to be missing insights into the bigger picture. It follows that working as part of any team will become more difficult.

Answer 4

Agile methods tend toward small, cross-functional teams. This means that the team has the cross-functional skills needed to deliver the product or service on which they are working.

Depending on your framework, there will be different definitions for "small". Scrum Teams are "typically 10 or fewer people" (as of the November 2020 Scrum Guide). DSDM Solution Development Teams are "seven +/- two people". Extreme Programming calls for a team no larger than 12.

When you have between 7 and 12 people on your team, it could become easy for a single person to become a risk. If you have cases where a single person has the knowledge or skills to carry out a specific type of work, what happens if that person is unavailable for an extended time (such as vacation or sick leave) or leaves the company? It's less about agility and more about risk management to make sure that the team has at least 2 or 3 people who can do any given type of work.

Answer 5

however, from career growth aspect, if one's target is to be very specialized and an expert in a single field, is agile not healthy for that individual?

No, it's indeed not. "Agile" tries to form people into collaborative problem solvers. That requires understanding everybody else's role on the team.

Once you have walked a mile or two in the UX developers shoes, you will know why certain decisions are made. And whatever your specialty is, it will be better for it.

Otherwise, you will become that specialized person nobody wants to work with, because their work is technically superior, but really sucks, because it's difficult to use for the intended purpose.

Like a bakery that has perfected the art of making walnut cake, but somehow never knew half their potential customers have nut allergies. It does not matter how great your cake baking skills are, if you don't understand what it is supposed to solve.

Keep in mind, your job is not to produce technically perfect software. You job is to make a company money by producing software that is easy to use, so others can be more productive, and in turn make the company more money.

Career growth is your goal. If you want to be that single minded, ivory tower person, you will have to find a company that still employs such individuals. But beware, that probably means you will work with a lot of those types.

Answer 6

Where does it say that agile projects have to consist of T-shaped employees, and everybody has to do everything?

This is most definitely not a feature of "Agile", and not of SCRUM either.

Check out the https://agilemanifesto.org and 12 Principles of Agile Software DEvelopment. Both make no mention of properties of individual team members whatsoever, much less roles they have to fulfil.

For SCRUM, if you read the chapters about the Team and the Developers in the SCRUM Guide, you will note that it is very generic. Specifically, it says nothing whatsoever about individual people. Some quotes:

• "...the members have all the skills necessary to create value..."
• "...Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint."
• "...specific skills needed by the Developers are often broad and will vary with the domain of work..."

It is clear that what is meant that all the developers as a team combine these skills. It says nothing about every single developer having specific qualities like T-shapes.

Note that the whole SCRUM Guide document does not contain the words "code", "coding" or "software". It has exactly one occurrence of any variation of the word "develop" (but not in the context of developing software, but more in developing the sprint goal).

In the preface, it specifically states that SCRUM is not only for software projects, and it says:

We use the word “developers” in Scrum not to exclude, but to simplify.

Also note that almost every occurrence of "Developers" is spelled with a capital "D", denoting it as a formal role description (on the level of "Scrum Master", "Product Owner").

Sometimes people think that the items in the sprint backlog should not be attached to individual people, and that everybody should be able to pick up every task during the sprint. I do clearly remember reading about this kind of backlog in the (very distant past), but the current SCRUM Guide certainly says nothing of the kind. In practice, it is totally normal to have I-shaped people, and stories reflecting that; i.e., stories being assigned to individual people right form the start. This may or may not be super optimal for obvious reasons, but that has nothing to do with the process, neither with SCRUM nor Agile.

It also might be a confusion with DevOps, where at least one interpretation of the concept could imply that the same individuals possibly do both Dev and Ops work. But this has nothing to do with Agile or SCRUM per se; and it is by far not the only possibly topology of a DevOps team - DevOps has plenty of space for I-shaped people as well.