Day 3 of 100 Specialization Exists - Honor It

April 24, 2013 — Posted by Al Shalloway

 

Continuing with the  100 Things You Must Know to Be Effective In Software Development.

Scrum talks about self-organizing, cross-functional teams. Let me make it clear, this is the best team structure I know.  Some folks have construed this to mean - teams of generalists.  That is not what it means.  It means the team has all of the skills and knowledge required to create valuable software.  Having everyone be generalists is not a good goal in my mind.  Some things require specialization so as to be an expert at it.  For example, your domain expert should not be a generalist - that is, they won't know everything about everything. People may not necessarily have different roles but they do have different skills, abilities and experience.

What needs to be recognized is that for organizations that are small, one or two teams, achieving cross-functional teams is not too difficult.  But when organizations get even just as large as about 100 in the development group it gets to be fairly challenging.  Some folks turn out to be in short supply.  These are primarily:

  • Subject matter experts (try hiring someone with 10 years expertise in your domain with knowledge of your product and train them in 2 weeks)
  • Skills or maybe just plain smart people (e.g., architects, PhDs in metallurgy)
  • Legacy code knowledge (e.g,. someone who was around when the code was written 5-10 years ago)
  • Stakeholders who can make decisions for the team

XP and Scrum's team model obscures the fact that at the enterprise there are typically not enough of these folks to go around.  And in many cases, e.g., architects, you don't need one on each team anyway.  One must acknowledge the fact that true cross-functional teams, while a great go-for, is not going to happen at scale.  In "four shades of Agile teams" (another topic coming next) I'll show different alternatives to the pure cross-functional team that works in the real world.

The lack of acknowledging specialists causes serious problems in scaling Agile in organizations. What happens is we might create a few Agile teams totally utilizing our folks with special skills, knowledge, etc.  Then management sees other folks available and says - what can they do?  We start another project but it tends to be a burden on our already constraining folks.  Before long our best folks are seriously overloaded.  It is this simplification of people's skills that leads to How Successful Pilots Often Actually Hurt an Organization.

Alan Shalloway
CEO, Net Objectives

Take the 100 in 100 Challenge. I'm committing to add one entry each day.  I'm asking people to accept the challenge of reading them.  If you accept this challenge, please enter a comment on the blog that started it all and tell me why you are taking up the challenge - that is, what you'd like to learn.

 
Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban