What About Me?

We've spent the better part of the past few decades building software organizations around individuals with very specialized skillsets. 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.