Second, the definition of the term “roles and responsibilities” is often unclear and varies from person to person. Like many miscommunications, this one is often caused because people are hesitant to ask what a simple and common phrase like “roles and responsibilities” means. Agile teams will recognize this confusion and get together to hammer it out. They won’t kill themselves to nail down every last detail because they know the team’s dynamics may change, but they will come pretty close. Here are two simple definitions of roles and responsibilities that can be used as a starting point for discussion with your team:
Your role defines what you do.
Your responsibilities are what you decide. This does not include discussing information, performing analysis, or otherwise contributing information to make a decision. Responsibilities are only those areas that you regularly make decisions on for the team.
Agile Strategy Since members of agile teams always have multiple roles, break them down into primary, secondary, and tertiary groups.
Primary Role refers to something that you do regularly and for which you are considered the owner and are held accountable for.
Secondary Role pertains to activities that you contribute to regularly.
Tertiary Role pertains to activities that you contribute to occasionally.
Do not confuse your role with your time allocation. Time spent on a task does not necessarily affect your role in the project.
Agile Strategy Break down the responsibilities of team members to avoid confusion regarding decision making in various project areas.
Primary Responsibilities are those things that you regularly decide yourself. Someone else may perform analysis or make a recommendation, but you make the go/no-go decision.
Secondary Responsibilities are those things for which you are the technical/business leader and primary recommender, but where someone else makes the ultimate decision.
Tertiary Responsibilities are those things for which you are on the committee making the recommendation.
Decision making can fall into many categories that often interact with each other, so it’s important to think through decisions critically. Common categories include business decisions, technical decisions, administrative decisions, and strategic decisions. It is also a good idea to define decision making at the milestone level, since it is here that many critical elements come together. Agile teams will find that decision making is spread more or less evenly throughout the team and mostly coincides with their primary roles. In general, the agile team will want to push decision making down to the lowest logical level, to avoid decision bottlenecks at the executive management level. Oldstyle teams will find decision making consolidated into a few higherlevel managers where almost everyone, including the project manager, is a recommender. Decisions must be pushed up through the hierarchy before anything substantial is decided (see Figure 4-3). Obviously, this is not the most agile approach.
Figure 4-3: Decision making in an agile versus classic environment.
The primary reason that classic PM tends to push decision making up through management is that the project team usually does not have the information to make informed higher-level project decisions. As discussed in Chapter 3, making the project the business is a way for the project manager and project team to gain a higher-level perspective so that they are better able to make these decisions. In all likelihood, truly critical decisions will still be brought to senior management. However, even if intermediate-level decisions can be handled at the project team level, it will reduce management bottlenecks and increase agility.
Agile Strategy Handle intermediate-level decisions at the project team level to increase agility. These are the decisions that fall in the gray area between the project team and management, thus usually making for longer and repetitive discussions leading to an actual decision.
As you’ve guessed by now, when defining the team’s roles and responsibilities, you very well may have to define them for certain areas of management as well, since almost by definition managers are involved in decision making. Having this discussion with management can be a valuable exercise. Most agile managers want to push decision making downstream, but they may be uncomfortable in doing so. Nonetheless, the project manager and his team will take a powerful step toward agility if they can convince management to let go of some decision-making authority.
Agile Strategy Discuss the project decision-making strategy directly with management to get their buy-in and make them comfortable with the idea of letting go of some authority.
Escalations
The process of resolving conflicts around decisions through escalations is a subset of decision making that’s worthy of additional focus. This is an area that naturally crosses functional boundaries and, as such, can greatly facilitate agility—provided the process is properly worked out during the definition and planning stages of the project, rather than during a crisis in the execution stage. Many teams prefer to focus on defining “roles” and eliminate the discussion of “responsibilities” because they feel that the two are so closely aligned. That’s fine, if by the team’s definition, they are indeed aligned—however, this often isn’t the case. There is usually alignment when responsibilities lie cleanly within a single role or functional area, but the alignment diverges when project complexities force responsibilities to cross multiple roles or functional areas. In these situations, making a decision that rightfully falls within the purview of your responsibilities may influence other people, thus creating the potential for conflict.
For instance, making the decision to modify a product feature because of a technical obstacle may influence the ultimate market position of the modified product, the compatibility with a sister product that is under development by another division, and the overall development costs. While the technical leader should be the owner of this decision, he must realize that it involves the product manager, the technical lead from the sister product, and functional management that will have to furnish additional resources to support the modification. If these people cannot agree on the technical leader’s decision or, worse, were never asked in the first place, considerable conflict may arise. Who is going to unravel this mess?
The best way for the agile team to gain traction on this subject is by defining an escalation process—namely, how the team will handle conflicts in the decision-making process. If the team does decide to document responsibilities, then the escalation process should be woven into that definition. If it decides to forgo the definition of responsibilities, then the escalation process should be defined separately for the team, perhaps in the communications plan. (A detailed communications plan template is furnished at the end of this chapter.)
Agile Strategy Define the process for escalating conflicts on the various types of decisions your team may encounter, either as part of the team responsibilities or in a separate document.
Note: Escalations are focused on conflicts or disagreements about a decision and not the decision itself. Agile teams will want to push the core decision making down to the lowest level and reserve management involvement for conflict resolution.
Often the best escalation process resolves a conflict before it actually has to be escalated at all. To this end, the agile escalation process should include a mediation step, facilitated by a third party, before bringing the problem to management. The project manager is logically this third party and therefore should be fairly skilled in conflict resolution. In fact, conflict resolution (as part of escalation) should probably be listed as a formal role of the project manager.
Agile Strategy Include a step in the escalation process where the project manager works with the involved parties to resolve the conflict before it is actually escalated to management.
Helping the Project Team Define Its Roles and Responsibilities
Try this exercise. Document your team’s current roles and responsibilities as perceived by the individual team members themselves. Have each individual write down what they think their roles and responsibilities are. While this may seem like a straightforward exercise, you are probably going to experience some confusion and debate over what a role is and what a responsibility is. The facilitator of this exercise must have a very good understanding of the differences herself in order to help the team through this question. It is not imperative that you stick strictly to my definitions, but modifications must be defendable and consistent.
Based on your particular team’s dynamics, you may decide to create these definitions as a group or one-on-one. I like to have individuals create their roles and responsibilities separately and then present them to the group for discussion because it removes the potential for groupthink. In a group atmosphere, people may feel that they need to confine their roles and responsibilities to things related directly to their functional area. In reality, though, they may see other areas where they can add value. Remember, getting people to expand beyond their usual functional area, to move outside their comfort zone, should be encouraged in an agile environment. This is an opportunity to get individuals more engaged as a team, by making them think about where they can and want to contribute.