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.
Working Together, Working Alone
Individuals on the agile team must be able to thrive in environments of both collaboration and solitude. They are self-starters who can assess the situation and determine for themselves which work mode they should be in, and then get themselves (and perhaps other team members) into it. As the project progresses through its lifecycle, the need for individuals to be working together or working alone will flip-flop many times. In some cases, team members may be working on parallel tasks and have to work in both modes simultaneously. The uncertain nature of the agile project creates this flip-flop between the optimized work mode (collaboration or solitude) and places a higher emphasis on the team’s ability to efficiently switch between modes. This concept is similar to trying to determine how many different projects one person can effectively contribute to simultaneously. There are inherent “switching” inefficiencies as a person transitions from one project to another. If you give him too many projects, the inefficiencies become greater than his effective contribution. In the agile paradigm, you may be working on a single project, but whether you work alone or with others is changing frequently. If you cannot effectively change work modalities, your switching inefficiencies will negate your contributions, essentially making you an ineffective team member.