Top Reasons Agile Didn't Work for Us: #3 Couldn't form Cross-Functional Teams

Anthony Mersino
April 29, 2016

This month I’ve been writing about the reasons that various organizations have found that Agile didn’t work for them.  I explored culture change and lack of co-location, and I contended that the true "failure" was unwillingness to change rather than a shortcoming of agile.  In this post I want to explore the lack of cross-functional teams.

An ideal Scrum team can take a backlog item all the way to done within a sprint.  In order to do this, they need to be cross-functional, that is, they need to have all the skills needed to get things done.  This may include analysis, development, testing, and domain expertise.  It could also include UI or database expertise.  To be effective, organizations need team members who bring all the required skills. 

Many organizations are able to create these cross-functional teams, but some are not. Why not?  Here are two of the main reasons I have bumped into:

  • Lack of Awareness - In some cases, the organization is just not aware that they need cross-functional teams.  They are accustomed to specialization, or it mirrors the organizational structure.  I remember meeting with a potential client last year who proudly announced that he had just formed two agile teams, a front end team and a back end team.  The front end team handed work off to the back end team.  Neither team was able to get things to done within a sprint, on their own.  The reason for the back end and front end teams, was that there was a manager for each.  And so the team structure mirrored the organization structure.  
  • Perceived Efficiencies - Other organizations believe that they can gain efficiencies by creating specialized teams such as business analysts, front end developers, DBAs, or testers.  Or they may be specialized by component. The specialists have their own language, process and tools.  They develop elaborate rules to "protect" them from others, like "testing will take 5 days after code freeze", or "no one outside the team can change our private code".  It is a form of local optimization and it creates a handoff and bottleneck.  The manager of the specialist team helps to enforce the bottleneck and protect the turf.

My personal favorite of these specialized teams is the Testing Center of Excellence.  I've been in so many counter productive discussions with QA Managers or others who fight strongly for centralized control of testing and just as passionately against agile. We have the same debates about long test cycles, restrictions on the licensing of tools, and who is actually responsible for quality.  (Hint: They believe they are responsible for quality).  I’ve heard some pretty unbelievable things from TCOE or QA managers:

“We need 10 days for a complete test cycle - there is no way we can do it in less time."

“I need to review and approve all the test scripts."

“We cannot have developers test because we are accountable for the quality."

And my personal favorite, "Developers make lousy testers".  To which I retorted that I thought lousy developers made lousy testers.

Developers make lousy testers.

— QA Dept. Manager

 

Let’s be clear, this is all about power and control.  Agile approaches threaten the power structure and weaken your power base.

So what is the harm of these specialized teams vs. true cross-functional teams?  

  • Sub Optimization - Specialized teams like testers may be more efficient, but the overall, end to end process is slower.
  • Handoffs, Queues & Bottlenecks - With handoffs come knowledge scatter and relearning.  Queues and bottlenecks result in delays and the 10-day test cycle.  Everyone may look busy, but the work is piling up and not getting to done.
  • Unnecessary Turf Battles - With specialized groups come battles over turf in the form of private code, private tools, and unique processes.  I've sat through my fair share of meetings to review the updated "business analysis process".
  • Lack of End to End Ownership and Visibility - Specialized groups don't worry about getting things all the way to done.  They get their individual part done and ignore whether the results are useful, delivered on time, or mesh well with other groups.
  • Lack of Imagination and Creativity - As soon as we create specialty groups, we begin to stifle creativity and innovation.  Do we really think the silo called the testing center of excellence is pushing the envelope on new ideas?  And if they were, would we need to call them the center of excellence?

How to Create True Cross-Functional Teams

One good approach to creating cross-functional teams is to first allow people to choose what to work on, and second to promote cross-training.  A few organizations actually do let people choose what to work on.  They describe the skills needed for each team and then they allow the team members to pick the team they want to work on.  I had the opportunity to co-facilitate a team formation exercise at Bank of America for 60 people forming 7 teams.  Here is an article describing a similar exercise done at BofA with other teams.

The second thing that will help create true cross functional teams is cross-training so that we reduce dependency on one person within the team.  Team members should be encouraged to share what they know and learn from each other.  This "multi-learning" is what builds the strongest teams and organizations.  

This runs counter to how many organizations work today where employees seek security by specializing and striving to be irreplaceable.  After all, if I teach others what I know, what would stop you from getting rid of me?  

If we look at the image for this blog post, it is all about the individual technologies I used in the eighties - the telephone, fax machine, camera, and calculator. I still remember that one of my most prized possessions when I started my first real job at IBM in 1985 was an HP Engineering calculator.  I loved that calculator and it's crude programming abilities and reverse Polish notation.  

But that wonderful HP calculator is pretty much worthless today.  Our modern smart phones can emulate that calculator and thousands of other things.  To maximize effectiveness, we need team members that are more like the smart phone than the HP calculator.  We want to encourage T-shaped skill sets.  We prefer full-stack developers to the one-trick ponies who only do front end development.

I love the humor of the image below from the new employee handbook at Valve, a video game developer.  Apparently Valve wants team members who are great at heavy weaponry, but also skilled at sandwich preparation and Russian folk dancing. 

Valve T-shaped Model

So why don't we have more cross-training and team members with T-Shaped skills?  I believe it is the managers of the specialty teams that most commonly rail against cross-functionality.  They view it as a threat to their importance and their power base.  It goes back to Craig Larman’s first law of organizational behavior:

Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and “specialist” positions & power structures.

— Craig Larman

What is your experience with forming cross-functional teams?  Do you find it helpful to have employees with T-Shaped skill sets?  I’d love to hear your experience.

About Anthony Mersino

Anthony is passionate about helping technology teams THRIVE and organizations TRANSFORM.  He loves partnering with organizations to help teams with Agile thinking and the Scrum Framework.  He teaches Agile and Scrum as well as the cultural elements that are necessary for an organization to gain true business agility. Anthony has  authored numerous articles and two books: Agile Project Management, and Emotional Intelligence for Project Managers.

Comments