Chapter 6: The Agile Project Team

A project team that "gels" can be a joy to work on. A cohesive team is, very possibly, the key between success and failure in the agile environment. Most of us have had the good fortune to have been part of such a team at least once in our careers, but we probably have many more stories of mediocre and even dysfunctional teams. Numerous dynamics may combine to make a team "click". This chapter is not about overall team dynamics; rather, it explores some of those characteristics common to the successful agile project team. If you are selecting your next team, then this chapter should give you some ideas about what to look for in your members. If you're already part of a team, this chapter may give you some ideas to make your team more agile.

Common Skills

The so-called soft skills are a critical common denominator of agile team members. These skills include the ability to create and maintain relationships, interact with various levels and functions within the organization, flexibility, adaptability, and generally being a team player. These traits are commonly referred to in most discussions on team dynamics and, indeed, they are invaluable to any team.

In the agile environment, the value of solid interpersonal skills is amplified. Agile projects tend to pursue multiple simultaneous pathways. The agile team needs to be able to operate within and evolve this network of pathways to advance the overall project. The networked nature of the agile project team requires the average team member to interact directly with many more people in the organization than may be necessary in the classic environment, where members have well-defined and compartmentalized roles.

Broad technical skills are also a must for the agile team. This may seem obvious, but again, the need for technical know-how is some-what amplified in the agile environment. To maintain their responsiveness, agile teams are generally smaller. Fewer people per team means team members must be able to wear multiple hats. All relevant areas of expertise for the project must be covered, but there isn't room for much overlap. If you're responsible for a certain functional contribution to the team, then you must be able to carry the ball in that area. Others are available to collaborate with you, but you must be able to make the final determination. In other words, it is difficult for a rank novice, who is still learning on the job, to play a core role on an agile team.

Agile Strategy

Discourage everyone from wanting to work on the high-visibility tasks, because that creates internal competition. Instead, show there's value in contributing to other areas of the project. You can do this by painting the "big picture" and carefully defining team member roles and responsibilities.

This does not mean that you should assemble the top experts across your organization for an agile team. In fact, that may be detrimental. Too many experts may create unhealthy tension in the form of posturing for leadership or high-visibility tasks, excessive debate, and one-upsmanship. When this happens, the project manager must address the situation quickly before the team dynamics start to spiral downward. As discussed in Chapter 5 on the role of the project manager, creating well-defined roles and responsibilities is a good tactic for mitigating this problem. On the other hand, while the agile team is not necessarily a good place for someone with novice-level skills and experience, it is a great place for someone with intermediate-level skills. Today's businesses require well-balanced team members in all areas. The agile team, being on one extreme of the spectrum, is a great training ground for the person who has mastered a specific functional skill and is ready for exposure to other functional areas. Certainly, experts are required on the team in the core technical and business areas, but mixing people with intermediate-level skills into the support areas of the team tends to create a good balance.

Agile Strategy

Select a mix of expert and intermediate-level skill sets to create a healthy balance on the team, and provide a training ground for broadening individual perspectives.

Uncommon Skills

The soft skills required in an agile team member go beyond just being able to get along with people, being a team player, and participating in a network. Individuals on the agile team must be able to initiate the networks that make up the agile project. They actively seek out others for collaboration and information. They help other team members become engaged when they are in a rut. They go out of their way to offer their services and assistance to others. They create a barrage of ideas to investigate rather than focusing on just one. And their strong interpersonal skills enable them to do all of this in a positive light.

Very few people have the uncommon skill to be able to create the networks of ideas and people necessary to drive innovative projects forward.

Many of the problems of uncertainty encountered in agile projects are addressed by exploring multiple simultaneous pathways versus the single path common in classic project management. Being able to generate and then link various idea networks is crucial. This lays out the team's options before them, facilitating decision making in the face of the unexpected. More than the actual ideas themselves, the people who brainstorm these ideas, and subsequently commit to executing them, become part of the project network. Often the individuals who get pulled into the network of an agile project are not even formally part of the team, yet they make significant intellectual contributions to its success. Many people have the skills to join and contribute to a network. Very few people have the uncommon skill to be able to create one. Certainly, not everyone on an agile project team needs to be a network creator, but at least someone must assume that role. It could be the project manager or the technical leader, but ideally, someone on the core team. You may find that no one is instinctively adept at this skill. That's okay, as long as you recognize it. In that case, the key players on the team must put additional conscious effort into the network creation process.

Agile Strategy

Look outside of your specific technical area to identify where your efforts intersect those of other team members, as well as those who are not even part of the current project plan. In this way, you will be creating a network of ideas that will help drive your ideas forward.

Throughout this book, I have discussed the effect of operating a project in an uncertain environment—specifically, an environment where the project requirements are expected to change many times over the project's duration. The project will most likely change schedule and scope multiple times, but it may also change team members, roles of team members, sponsors, and leadership. These resource-related changes often originate within the project and, in turn, force the surrounding organization itself to change.

Being able to manage a project through uncertain territory is a challenge in itself, but dealing with the effects of organizational change surrounding the project is quite a different thing altogether. A common occurrence on an agile team that affects the surrounding organization is when team members move outside of their traditional roles. I like to encourage this behavior on the agile team; however, individuals who don't subscribe to this philosophy will inherently resist and perhaps pull their functional management into the project realm to protest. This happens when their functional management has erected solid barriers around their territory and in stilled in people the idea that they shouldn't be working outside the barrier and others shouldn't be working inside it. When people move outside their traditional roles, it may cause organizational conflict because it appears to be a prelude to organizational change—which, in a way, it is. So, in addition to being a methodology for managing projects in an uncertain environment, agile project management is an influence on organizational culture to break down the so-called silo mentality.

Agile Strategy

Break down the silo mentality by presenting the big picture of the project, depicting the networked pathways to functional management. Explain to them why functional boundaries need to be crossed.

Let's take a step back and clarify that we are now talking about organizational change, where previously we were discussing project change. Project change is something that we have to deal with because we are breaking new ground and we don't have a template or map to lead us. Organizational change is something that we must drive, if necessary, to make the agile project successful. If your business is running a project in an environment of uncertainty, then the business itself is in the same environment. The project will undoubtedly change directions on its way to completion, and the organization may very well have to change with it. This can be scary for some people, but remember, the project is the business (Chapter 3's lesson). It is very difficult to move the project forward if the organization is stalled.

The agile team must be able to deal with changes in the project and must be able to drive changes in the organization.

You want people on the team who not only can tolerate change, but also thrive on change. Ideally, you'll find individuals for your team with that very uncommon skill of being able to drive organizational change. Let's call them organizational architects. This reinvention may be at the department or the division level or somewhere in between. The agile team is not afraid to challenge the organization to transform itself, especially when the transformation is necessary to stay competitive in the changing business environment.

Agile Strategy

Add an organizational element to the project plan describing the benefits of new organizational roles and responsibilities, both to stimulate team discussion and provide a basis for discussion with management.

These organizational architects can visualize the impact of the shifting business environment and craft new ways for the organization to adapt. Furthermore, they can communicate their vision to decision makers in management (since they usually do not hold formal authority to dictate an organizational change) and convince management to take action. While many people are skilled at incrementally improving business processes, few are skilled at crafting improved organizations. I've seen many job advertisements for business process analysts, reengineering experts, or process engineers, but never one for an organizational architect. Yet you want people with these skills on your team. These people know that having an agile project team is only part of the battle. It doesn't matter how agile the team is if it is continually being weighed down by a business organization that's incapable of changing. To complement an agile team, you need agility in the over-all business. Creating organizational agility will be paramount to business survival in the future. Driving this change from the project perspective is a very effective means, since projects are the vehicles dealing with current real-world scenarios.