Does running an agile squad mean that all squad members can do any work, or work should be divided based on skill set?

Question

Consider a new PO running a brand new Agile squad where squad members have different skill sets:

• one developer (who works with the code)
• one tester / QA person
• one application architecture
• one designer
• one data engineer

Does running an agile squad mean that everyone should be trained to do everything? OR should project stories should be divided based on skill set?

1. If we cross-train everyone, then what is the point of having subject matter experts on the squad when everyone can do everything?

2. If we do not cross-train everyone to do everything, does that mean we are limiting project stories we can work on in a given sprint? One developer can only work on X items, one data engineer can only work on X items, and so on.

Any advice?

Answer 1

Cross Functional has more than one layer of meaning.

At the lowest level, a cross functional team simply means that all skills needed to deliver a usable increment are present on the team. At this level, work clearly goes to the person with that skill. And if that person is not present, then the work can’t be done.

While full stack engineers do exist and a dev on such a team could take on any work the team faces, this is what I think of as the highest evolution of cross functional and is still relatively rare in my experience.

In the middle you have the concept of “T” shaped engineers. They are deep in one skill and shallow in several others. The Business Logic person might also be skilled in UI and while not able to do the most complex tasks can handle easier tasks freeing the deep UI expert for that work or be able to cover if the UI expert is out.

There is still a need for Subject Matter experts and architects in Agile. They just move out of the team as the team becomes more cross functional. An architect’s job is to create the guard rails the teams can work within. (A bigger conversation than this question is looking for).

I have worked with the first and later kinds of teams many times and one of my mentors had one of those middle, full stack teams.

Answer 2

First, let me say your team is incredibly unbalanced. You have one architect, one designer, one UX expert and one data expert per developer. That is ridiculous. Those roles are multipliers. They are brought in to make your developers be more efficient in those areas by bundling and streamlining tasks. There is no way an architect can make a single developer work twice as fast (which they needed to, to be worth their salary, otherwise you could have just hired a second developer instead). The same goes for design, UX and data. With all those people involved, you'd expect your developer to work at 3x the normal speed. How would that ever work?

For your team to be efficient, you would need 5-10 more developers. That is how you build stuff. You don't build a house by hiring one architect, one interior designer, one marketing expert, one garden planner and then one single poor sod whose job is foundation and construction and plumbing and electricity and painter and gardener and tiling and roofer. Do you get an idea that this one person might be slightly overworked in your setup? How long do you think this construction will take? Keep in mind you are paying all of those fancy planners for each hour the poor sod takes to build the house. The others still get paid every hour for sitting around watching. You don't send them off unpaid, like you would with a real architect whose work is done. That is not how regular employment works.

So if you don't want to fail this project with a loud bang and a lot of money wasted, your people need to take over jobs that actually making your project come to life. Not just planning. Planning is important. But 3-4 people making plans for one worker is a travesty. When the planning is done, they either need to pick up some of the work and actually do it, or they need to be on contract basis and stop getting paid while the worker goes through with their plans.

Side note here... if each of those jobs is important, then your team will be dysfunctional a major part of the year. In theory, in my region, considering PTO allowance and average sick days and weekends and public holidays, if timing is bad, with 6 people you may not have a full 6 person team on any day of the year. With PTO taken most likely during school holidays, not randomly spaced out, you may have a full team for a few weeks in between while it's totally broken if two people are missing. So again, if you don't want to fail, your team needs to be cross functional. You cannot just hope that you get lucky once in a while; your people need to be able to cover for each other in case of absence.

Now to counter a common misconception: you don't need to train everybody to do everything. But you need to train people that each job can be done by multiple people. So for example, the designer can get a refresher in UX work. The architect surely has programming experience already (if not, hire a competent one). Literally everyone can be taught to use the Q/A tools to test. Maybe not to build new tests, but at least to test the already established cases that need to be tested before every release.

If we cross train everyone when what is the point of having subject matter expert on the squad if everyone can do everything?

Well, who do you think can cross train the others? You need at least one expert, to even start cross training, don't you think? And cross training does not mean the others become experts. They become "good enough" so they can pick up work and do it without the project failing.

if we do not cross train everyone to do everything, does that means we are limiting project stories we can work on in a given sprint? as one developer can only work on X items, one data engineer can only work on X items and so on..

If you do no cross training at all, you will fail unless you hire 5-10 more developers. Your money will run out before you even produced an increment worth showing to customers. You have a huge overhead of "planners" to "workers". If you don't cross train them into "workers", you are doomed anyway. Don't get me wrong, you have the right amount of specialists... but you are seriously lacking in worker bees to make it happen. And you have a bus factor of 1 for each specialty.

Either hire more, or train your specialists to be useful outside their narrow specialty.

Answer 3

Having a cross-skilled team gives you flexibility. It means you can take in different types of stories and still maintain a good utilisation (nobody overworked, nobody with nothing to do).

However, when building a cross-skilled team there are other considerations:

• Do all the team members want to learn every skill? Keeping the team members happy and motivated is important, so we don't ignore their preferences
• Do some team members really enjoy employing a particular skill? If they do, it would make sense to make sure they get to do it often
• Do the team members have an aptitude for each skill? There is little point in forcing a team member to do something they really struggle with

Given these considerations, building a cross-skilled team will involve a lot of inspection and adaption. Try things, adapt and move towards an approach that works well for your particular team.

Answer 4

TL;DR

Does running an agile squad means all squad members can do any work or work should be divided based on skill set?

You are creating a false dichotomy. People are not cogs in a machine. They are not interchangeable parts. The goal is to create a cross-functional team with T-shaped people rather than populating a group of random individuals with I-shaped skills.

Analysis and Recommendations

Analysis

You currently have a group of assorted people who are I-shaped. They are each so specialized in their skills that they cannot really be expected to:

1. Fill the role of [product] Developers on the Scrum Team.

   Scrum has no team hierarchies and no other roles besides Scrum Master, Product Owner, and Developer. Your team seems to have a surfeit of people, but they were not selected to collectively be "Developers" in the Scrum sense.

2. Take collective ownership of the product development because they lack the cross-functional skills to collaborate on a single Sprint Goal at a time.

   Scrum requires that each Sprint has a singular, unifying Sprint Goal. The whole Scrum Team is collectively responsible for delivering it. Two or three of your Developers are unlikely to see their role as collaborative or take ownership of a common product increment; I-shaped people usually function best in organizations where people "toss work over the wall" at each other, or work on independent and unrelated activities. There is absolutely no downstream work within a Scrum Team, but you've hand-selected a team that most likely expects to work sequentially and then pass their work downstream to the lone programmer and then the unfortunate single tester. That is in no way "agile," much less Scrum.

3. T-shaped people aren't interchangeable. They're simply sufficiently cross-trained to collaborate on the same work increment rather than forced to work independently of one another.

   In Scrum, the idea of assigning work to people in sequential or parallel silos is antithetical to the process. The Scrum Team may have many different skills required to deliver each Increment, but they are expected to self-organize and self-manage the work needed to reach each Sprint Goal. If you have "designers" and "architects" who can't program or don't understand test-driven development, how can they work as equals with your programmer and tester to deliver each Sprint Goal?

   The short answer is that they can't. You will have people estimating only their own personal contributions, rather than the level of effort for the team for each vertical slice of value. They will also we working on a narrow piece of what each person knows how to do rather than swarming over the singular objective for each Sprint.

Recommendations

You have a very unbalanced team. If you can, refactor the Developers on the Scrum Team so that you have:

1. Developers with programming skills and at least some TDD/BDD skills.
2. Developers with design skills who understand how to work incrementally, and can iteratively collaborate with the rest of the team on just-enough and just-in-time design to meet the unifying Sprint Goal each Sprint while understanding the level-of-effort involved for the whole team to meet the Definition of Done.
3. Developers who understand that agile architecture is about emergent design, and know enough about testing, programming, and UX/UI to delay architectural decisions until the last responsible moment and create just-enough architectural runway to support the current unified Sprint Goal and its associated Definition of Done.

In other words, you have to rethink whether this is a team or a collection of specialists. What you have now is not agile. You can either refactor your team's composition from the beginning, or expend time and effort—yes, this will carry a cost to the project whether you acknowledge it in your project plan or not—by putting cross-training and whole-team agility training as evergreen Product Backlog and Sprint Backlog items until your team is actually able to function as a Scrum Team with T-shaped Developers.

• If you use the team you have now, you need to apply a fudge factor to any estimates to account for the whole team of Developers lacking cohesion and to give them the time and opportunity to learn enough of each other's jobs to estimate per-Sprint outputs (rather than just their own) and to collaborate effectively on a single, coherent objective each Sprint.
• If you replace the team you have with more cross-functional people, then your Scrum Master can instead support them in finding their own collaboration patterns with the foreknowledge that they can assist one another and work together on a common set of deliverables that form a single overarching Sprint Goal. Each Sprint Goal is an incremental or iterative step towards a single Product Goal, and if the team can't do this collaboratively then they can't be collectively responsible for delivering the product Increments that collectively define each Sprint Goal.

If you can't fix your team, or restructure your project to actually be agile, then you have an organizational problem that you need to address.

Fix Your Organizational Processes

Scrum Teams are intended to be long-lived teams that work on multiple projects over time. This allows them to be a team and not a collection of individuals.

If you are trying to adopt Scrum ab initio, you often get "teams" like the one you're describing. This is basically putting lipstick on a pig and doing traditional waterfall development but slapping a hip new agile label on it. Real agile adoptions require changes to the way teams are composed, work together, and get managed by line management and senior leadership.

You can't undo years of hiring for I-shaped people, but you can make the costs of using I-shaped people or building teams without cross-functional skills visible to stakeholders. Scrum doesn't promise you will do anything faster; it just promises to make the cost of work, change, and process visible and transparent so that the organization can continuously improve.

Without executive support for the values and principles of agility, and without their support for switching from utilization- to outcome-based metrics, the project will not produce the desired results. This will ultimately be blamed on the members of the Scrum—deservedly so if they don't take ownership of their own team composition or don't raise process issues like team resources and the (lack of) availability of framework training or cross-functional skill development—while management often thinks Scrum is a technical thing and refuses to change how they leverage the framework, interact with the Scrum Team, or measure the progress of the project.

Senior Leadership is Always Responsible

In the end, executive management is always 100% responsible for the success or failure of a project. Tone at the top is essential to agile adoptions, and real agile transformation requires changes in leadership style as well as spooning around new names for existing roles.

In short, Scrum is a framework with room for both the Scrum Team and the parent organization to continuously inspect-and-adapt. Unless that happens, the process will break. If executive leadership breaks the process, then they get to keep both halves. Q.E.D.

Do your best to support this transformation, but if you need help get buy-in and support from your leadership team. If your organization is struggling to adopt Scrum, then hire an agile coach or make routine framework seminars, lunch-and-learns, or other ongoing training part of your routine cadence. In many cases, poorly-implemented Scrum will actually be less effective than poorly-implemented waterfall. Don't set your team up for failure this way; sweeping obvious problems like this under the rug is why more than 68% of IT projects fail. Don't be a statistic!

Answer 5

The Agile team is supposed to be "self-organizing."

If you only have one project, then yes, team members will need to step outside of their specialties in order to speed up the project (or just not work).

Given the composition of your "squad," it's likely that your members will be working on multiple projects in parallel and possibly working during different phases. Your architect will probably do a lot of work for Project B while your Tester is testing project A.

In practice, team members typically stick to tasks that they specialize in. If there are no (remaining or upcoming) tasks that they specialize in, they will usually be assigned to a new project.

They may also be given tasks that they don't normally specialize in, as a sort of On-The=Job-Training (or just because the company is desperate for time). An example would be asking a frontend engineer to take on some backend tasks, because understanding the "full stack" is desirable. The key here is that they will be asked to completed a task that isn't incredibly inefficient (like having a $1M architect to go out and buy the team coffee, or requesting the UI expert to write machine learning modules that would require the UI expert to study full-time for a few years just to get started on).

---

*Agile teams are supposed to be "self-organizing", but that doesn't mean that there isn't a "Scrum Master" or "Agile facilitator" who has some say in who does what.

Answer 6

The above team setting is a failure. There are only I shaped professionals working within a same team and one person to be a T-shaped leader.

Generally speaking, the fundamental purpose of agile team is to create cadence and display demo at interim meetings. Communications within domain and cross-functional teams is the prerequisite to drive out silos, create a psychosocially safe workplace and cross-check the works.

TO be specific,
For each domain there shall be at least 2 people to be:

2 developers (who works with the code) 2 testers / QA person 2 application architecture 2 designer 2 data engineer

You can argue only 1 application architecture is necessary.

Answer 7

In your team, there is one team member per role, so cross-training is not possible. It is not possible to expect a tester to do data engineering work, or an application architect to design a UI/UX.

Cross-training comes into play when you have 2 or more team members working in the same role. For example, if you had 2 software developers, the best practice would be cross-training these 2 team members for the modules that they are more exposed to.