Back in the days of waterfall, everyone had their one and only job. Business analysts would write the hundreds of pages of specifications. Architects would design the layers of the application. Database administrators would create the database. Software engineers would write the code. And finally, QA engineers would test.
Of course, that’s when everyone realized they were 100% behind schedule. Oops!
There had to be a better way.
In January 1986, a breakthrough article was published in the Harvard Business Review. The New New Product Development Game, by Hirotaka Takeuchi and Ikujiro Nonaka, pointed out that the traditional approach of sequential product development—a hallmark of waterfall—simply doesn’t work:
The traditional sequential or “relay race” approach to product development…may conflict with the goals of maximum speed and flexibility. Instead, a holistic or “rugby” approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.
Inspired by the rugby analogy, “Scrum” was coined in the early 90’s. Instead of long, specialized phases, Scrum focuses on teams doing a little bit of everything all the time, producing a potentially shippable product increment by working iteratively and incrementally.
Does Specialization Work?
Scrum teams are cross-functional; they collectively possess all the skills necessary to do the work. This is great—it means the team can get things done without depending on anyone else, which often slows teams down. Each team member typically has something they’re good at—their specialty.
Because we still have what I call a “micro waterfall” for each user story—some code must be written before any testing can be performed for example—it seems at first that specialization is just fine.
Let’s take the example of completing a new user story for a web app. An architect can design the technical framework for the story, a back-end software engineer can write the server code, the front-end engineer writes the code that runs in the browser, and a tester can put the story through its paces.
In a perfect world, this can work. There are just a few requirements:
- Work is perfectly balanced. The amount of time required for architecture, back end, front end, and testing work is the same, so everyone is busy all the time. This happens sprint after sprint, so no one is ever idle.
- No one ever gets sick. Everyone is healthy all the time, so their specialty work can always be completed without slowing the team to a halt because no one else can do their work.
- No one ever takes a vacation. Like getting sick, no one ever takes any vacation either.
- The team is never interrupted. No production bugs ever happen that may need the attention of one or more team members. No other issues ever come up to distract the specialists from their work.
Will this ever be the case? I doubt it!
Enter The Real World
First, work is seldom balanced. Each user story has different requirements for architecture, front end, back end, and testing work. Trying to artificially balance the workload across specialties often results in cherry-picking user stories from the backlog based on the amount of each type of work, instead of priority.
“Let’s take on a front-end heavy story and a back-end heavy story this sprint, plus a few others that are kind of balanced.” This flies in the face of the need for the product owner to order the backlog in a way that delivers maximum value.
Next, is it realistic that no one will ever get sick or want to take a vacation? If that’s the environment, few employees will stick around the company for long.
Finally, though ScrumMasters do their best to protect the team from outside distractions, something always seems to come up. Even a small interuptions can throw off a perfectly balanced level of effort.
Just Throw More Bodies at the Problem
“Just put more specialists on the team,” you might say. For example, two architects, two front-end engineers, two back-end engineers, two testers, etc.
There are two problems with that approach. First, the company might not have the budget to have that many people on the team. Second, you may quickly run into the 10-member Scrum team limit. This approach seems attractive in theory, but it might make the problem worse in practice. Instead of one specialist of each type who may run out of work, now you have two!
The problem isn’t the amount of people on your team, the problem is over-specialization.
The End of Sprint Challenge
There’s another issue with over-specialized teams, which I call the “end of sprint challenge.” In the last one, two, or three days of the sprint, it’s typical that user stories are nearing completion. This most likely means coding is complete, and testing and the product owner acceptance process are getting wrapped up.
Because most of the specialists are “done with their part,” they tend to have nothing to do. Inevitably they’ll start drifting their focus down into the product backlog, starting work on user stories that are not in scope for the sprint.
These are items that were typically not discussed during sprint planning, so they may be unclear, and work proceeds in a more ad hoc manner as opposed to with a planned approach.
Many teams end up in the predicament of one or two people madly trying to finish stories while others are distracted. This hardly feels like a team approach, and often threatens achieving the sprint goal.
Avoid Having Only One Person Who Can Do the Work
There is nothing wrong with team members having a specialty. In fact, it’s critical to the team’s success. If no one on the team has solid skills in each required area, it flies in the face of the “cross functional” concept of Scrum teams.
What we want to do is enhance the team’s ability to get everything done every sprint. “Emily is the best person to do this work” is absolutely fine.
The problem comes in when you have a situation where “Emily is the only person who can do this work.”
That’s what you want to avoid.
A Better Approach: T-Shaped Teams
If you want to give your team a leg up and avoid the problems I outlined above, strive to create a T-shaped team.
T-shaped team is actually a bit of a misnomer. It’s really more about creating T-shaped people. A T-shaped team member has deep expertise in one functional area, discipline, or specialty, but also has an ability to work outside their core area.
As an example, one of your team members is amazing at coding the back end, but they can also write front-end code. Another team member is a front-end developer but has been learning more about back-end coding. He’s at the point where he can step through back-end code and fix bugs, which is a huge help.
One thing to remember is not every tester can write code, but all software engineers can test. It might take some time for your tester to write some basic test plans to better leverage everyone’s time, but having the entire team help wrap up testing toward the end of the sprint can be a game changer.
Helping Your Team Become More T-Shaped
There are a few things you and your team can to do become more T-shaped.
First, and most important, is the attitude of the team. As the Three Musketeers said, “All for one and one for all.”
An approach of “We will complete our sprint goal” instead of “I will do my work” is the foundation for driving the kind of teamwork that is at the heart of the Scrum framework.
Once that’s in place, you can use a variety of approaches to increase the ability of each team member to work outside their core area:
- Online courses. For team members who lack any knowledge in a particular area, online courses such as those offered by Pluralsight, Udemy, and more, can be immensely helpful. You as a team can decide what skills make sense. Upskilling your team is a win-win; If your tester has always wanted to learn how to code, they may become a new secret weapon for you!
- Pair programming and mob programming. In both pair programming (two team members) and mob programming (more than two), there’s a huge opportunity for learning. Pairing one specialist with others who are learning can drive knowledge transfer. Unlike online courses, all the learning will be within the context of your team and your product, driving higher value more quickly.
- Code reviews. Having less experienced developers review code with a more experienced developer can help drive learning, through exposure to the new code written for each user story.
- Fixing bugs. My personal favorite way to learn a new codebase, fixing bugs is usually much easier than writing brand-new code for a user story. Plus, the bug fix made by a less-experienced developer can be reviewed by more-experienced team members to help with the learning process.
The Critical Success Factor
I mentioned it above, but I can’t stress it enough. Being a high-performing Scrum team starts with attitude. An approach of “We’re all in this together and we’ll do whatever it takes to achieve our sprint goal” is what the best teams employ.
Before the days of virtual teams, there were occasions when everyone stayed late at the office the night before sprint review to drive that last story to done. When one team member felt like they couldn’t help, I asked “What if you ask the team if they’d like you to go get some pizza?”
The point here is anything that helps achieve the sprint goal is on the table.
Encourage your team members to ask “What can I do to help” if they feel like they’ve run out of work. You might be surprised with what your team comes up with.
Think your team is ready for an agile assessment? Use our free Agile Assessment Template and get insight into how your people, processes, and tools are functioning.
If you need help building your T-shaped Scrum team, watch Dave’s live presentation here or schedule some time with our team.
