Great agile teams have diverse skill sets and share a common vision.
This is the fifth in a series of posts about building great software using agile techniques. The series started here.
If you read any books on agile software development, you’ll see references to multidisciplinary teams. That means the development team is largely self-contained. The developers have the ability to get the job done without excessive reliance on outsiders. Why is that important?
Enterprise organizations like specialization. They create many workgroups that focus on narrow areas of expertise. If anyone wants to do something covered by one of those specialized areas, they are required to issue a request to the appropriate workgroup.
For example, enterprise IT departments have database administration (DBA) groups. They include people who have the knowledge and authority to create and modify database structures. If anyone wants to create a new database or make changes to the structure of an existing one, they must request assistance from the DBAs.
There’s a good reason for that. If the enterprise has multiple systems relying on a database, changes have to be reviewed and coordinated. Making a change for one team could cause another team’s software to crash. Centralized control makes sense, right?
Until, the concept is taken too far. What’s too far?
- Applying the rule to every database even if it’s used exclusively by one software system.
- Applying the rule to development and QA environments, even if those environments are isolated (e.g. sandboxed).
- Applying the rule to every database change, no matter how small.
[I don’t mean to single out DBAs for criticism. I’m merely using them as an example to make a point.]
Now imagine that there are several such specialized groups that every software development team must use. Each time they need assistance, they have to issue a request, enter a queue, and wait for availability. Does that seem agile to you?
Being Multidisciplinary Demands Vision
Agile software development teams have to be multidisciplinary by definition. They need team members who have multiple skills so that delays and wait times can be reduced or eliminated. They need an enterprise organization that gives them the independence to do whatever the team needs during the course of the project. Only then can real agility be achieved.
Having independence and using it wisely require that teams have a common vision. The team members have to work together with a shared purpose and a unified commitment. In this way, they’ll develop trust that, in turn, fosters collaboration. So through a common vision, the team will develop the strength to be independent and work as a unit.
Swarming won’t work without a common vision (see my last post). Even simple tactics like pair programming, will devolve into pair arguing without the joint commitment and shared ownership that derive from a common vision,
I’ve never said that enterprise software development is simple. While it’s fairly easy to be good, it’s difficult to be great and impossible to be perfect.
Is your team multidisciplinary?
Does your team share a common vision?
How would you characterize your team — good or great?
I’ll wrap up this series of posts on what it takes to be a great software development team in my next blog entry.
[The next post in this series is here.]