What About Me?
We’ve spent the better part of the past few decades building software organizations around individuals with very specialized skill sets. We have people that do the analysis and design, others that do the coding, another group to do the testing, and yet another to do the doc.
We have a specialized group of people to manage the people with the specialized skillsets and to manage the complex interdependencies all this specialization creates. We have project managers, and program managers, configuration managers, deployment managers, and release managers.
Agile software development basically calls for two roles… the product owner and the team. Okay… Scrum has three… product owner, team member, and ScrumMaster. As agile methods become mainstream we had better understand what we plan to do with everyone else.
Specialized skills are not required on the project all of the time. Specialization requires us to understand when folks are needed and when they’ll be free. Answering these questions leads us down the path of predictive project planning and complex portfolio models to manage the interdependencies.
Eventually we start thinking more about matrices and less about teams. If we are truly committed to the idea that great teams can deliver more than a collection of talented individuals, specialization presents a real problem.
Our teams needs all the skills required to deliver working software. In an ideal world we have people that are capable of performing in more than one role. This flexibility allows the team to adjust to the changing needs of the project. Less specialization leads to less constraints, and therefore, less complexity and faster delivery.
Traditional software teams need to address this issue head-on as they consider adopting agile methods. Business analysts, quality testers, and technical writers should be full time members of the development team. Team members should be encouraged to diversify their skillsets so they can help in other areas as necessary.
Do we know what is all of this going to mean for the individual, their development plans, and their career path? If not, we owe it to our people to figure it out.
Some team members will want to stay specialists. Often, what we do becomes part of who we are and change can be uncomfortable. Like any kind of organizational change, this change needs to be managed. We need to shepherd people through the transition, get them the tools they will need to be successful, and encourage them along the way. Some will decide agile is not for them and leave in spite of your best efforts. Wish them well.
We must be intentional about helping everyone make the transition to agile, otherwise we will create a vocal group of detractors that will oppose our efforts to lead change. Let’s define the path, point the way, and hope everyone is willing to come along for the ride.
Comments (3)
Jurgen Appelo
By sheer coincidence I published an article yesterday called Specialization is Good
I think specialization has proven to have its merits. As agilists we have to do better than just throw away all we have learned about specialization.
Mike Cottmeyer
Hi Jurgen,
Thanks much for your comment and the link to your article. I enjoyed reading your post.
IMHO, specialization is neither good or bad, it is just a reality that most organizations are going to have to deal with. I want us to come up with some more inclusive messaging to help everyone make the switch to agile. Given the history of the movement, agile can come off as very developer centric and I believe that we are going to alienate people that don’t write code for a living.
While some specialization is necessary, I do believe t introduces some problems. If you are only looking at one project at time, or you are in an environment where there is one team and one product, the impact of specialization is not as readily apparent. When you start building organizations around specialized skillsets and have a portfolio of 20-30 projects (or more), the complexity that comes from specialization is mind-numbing.
I have been a part of several large IT shops organized around groups of specialists matrixed into project teams. The amount of effort required to manage who is supposed to be on what project, when they are supposed to be on, and at what level of effort, is well… again… mind-numbing. I don’t believe anything that leads to that kind of complexity is sustainable in the long run.
So… at the end of the day, it is not really one or the other.
In general, I would rather optimize for team rather than specialization. That means that the team must have all the skills required to deliver the project. Within the team I would expect some specialization. I would also expect the team members to diversify their skills so that they can contribute continuously as the project’s skill requirements evolve.
The term ‘specializing generalist’ comes to mind.
I would also allow that there are some skills might be better optimized for specialization. Simon Baker posted a blog this weekend talking a bit about ‘generising specialists’. Apparently there are a few of us contemplating these issues this weekend:
http://www.think-box.co.uk/blog/2008/04/challenges-for-product-stream-concept.html
I would want the teams of specialists to be the exception rather than the rule. Optimize for team first and then handle the exceptions as necessary.
I am interested in your thoughts. Thanks!
Jurgen Appelo
“Agile can come off as very developer centric and I believe that we are going to alienate people that don’t write code for a living.”
Mike, I think this is exactly the problem I have with generalization. If I only had to work with developers, then I don’t see many problems. In fact, our developers *are* generalists, but *within* the discipline of software development.
But products are not just built by developers. We have interaction designers, graphic designers, consultants, content developers, etc. I would never dream of having one of our developers doing the graphics of our products. So why force them to become “generalized specialists”? Customers would kill me.
Cheers, and thanks for the inspiration!