When you start with a cross-functional agile team, you have to work with what you have, but IMO, the team/organization should have a vision of what it wants to be and what it values in its people.
In the last company where I lead an agile initiative, client dev engineers had tech specialties and code ownership was cut up equivalently. After just less than a year, the team eliminated the boundaries and we had common code ownership which greatly reduced bottlenecks.
I gave the problem of the bottlenecks to the agile team to solve. They decided to start pairing, and formed a guild with the apprentice to journeyman to master pattern. It was the responsibility of the masters in certain areas to assist in the development of the journeyman. Likewise it was the responsibility of the journeymen to assist the apprentice in their development (of course the masters would assist as well). This is an investment in organizational capability and resilience.
Now it is true that certain specialties, like say an Oracle DBA (more like a religion are more likely to be shared between teams than having multiple, equally capable folks. However, some of what they do can be learned by others to lessen the dependency each team has on them.
It is usually the case that folks have different interests in learning new technologies. This can be leveraged by letting the team members work out what their learning goals are, and pair up with others who are more skilled in the areas of interest. Pair programming, shadowing, code reviews, and other techniques help enable the knowledge and skill development.
Having single individuals on agile teams who are the only ones that know a technology is a very risky model from a business perspective. Having devs, testers, UI designers and others who are motivated to learn and extend their pallet of skills is ideal for an agile development organization. The benefit to the individuals is that come hard times like now, they are the ones who will keep their jobs because they are multi-dimensional.
It isn’t difficult to demonstrate to an organization’s leadership the benefits of investing in the development of the breadth of skills of their cross-functional agile teams. The key is reminding them and getting them to commit to the fact that this isn’t free. However, if it is part of the culture of the cross-functional agile software development team(s) and it doesn’t have to be imposed on them, the benefits to the organization and the individuals will far outweigh the cost.
The post Specialized Resources on Cross-Functional Agile Teams appeared first on VersionOne Blog.