Practice: Process and Practice Tailoring

Practice Process and Practice Tailoring

Objective

The objective of this practice is to tailor a process and practice frameworkdriven in part by a self-organization strategythat defines the approach the team members will take in working together.

Discussion

One of the characteristics that defines high-performance teams is their approach to doing their work. Approach rivals vision and objectives in importance because it determines how a team will execute, how it will deliver results (Katzenbach and Smith 1993). Since APM stresses execution, the team's approach to that execution becomes vital . Part of the self-discipline required of a team is that it agree on an approach and then actually use it. Either failure to agree or failure to execute indicates lack of self-discipline.

Process and practice tailoring defines the approach that the project team will use to deliver a product. This approach starts with the organization's standard framework, and then the project manager and team tailor it to their needs within the framework's constraints. For example, a company might use the APM high-level process framework with organizationally mandated checkpoints ( approvals ) at each phase. Within this process framework, the company identifies a set of required practices and deliverables (a streamlined set). The team then tailors the required practices and adds additional ones it deems necessary.

Self-organization strategy concentrates on how people work together, how they collaborate, and the mechanisms for that collaboration. Processes and individual practices concentrate on what people actually do. Although the strategy and process seem to overlap, they are actually complementary. For example, the practice of daily team integration meetings describes the concepts and mechanics for conducting short daily meetings to coordinate team activities. But if there are multiple subteams, the project needs a strategy for using these meetings effectively in larger groups.

Finally, processes and practices evolve . In the Envision phase the team may develop a general plan for its use that will undoubtedly be revised as the release plan details are developed in the Speculate phase. Then, as each iteration and milestone reaches completion, the processes and practices will be adapted to the feedback from the project itself. Nothing is static in APMneither the product nor practices. Teams are encouraged to adapt everything except the bare essential policies and process framework to the reality of the actual situation as it unfolds.

Self-Organization Strategy

The term "self-organization strategy" sounds like an oxymoron, because self-organization implies that "stuff happens" without planning and forethought. Some consultants and practitioners have interpreted the ideas of complex adaptive systems to mean that self-organization happens magically within groups of people. All groups self-organize, but if we want effective self-organization, we have to think carefully about how to create this type of environment.

Project managers often perpetuate a hierarchical, command-control management philosophy in their project organizations by focusing on organizational charts , detailed process and activity identification, and documentation requirements. Thinking about a self-organizing strategy attempts to break this mindset by having the project manager and project team focus first on interactionshow everyone associated with the project will play together. The strategy establishes the team's approach to communications, coordination, collaboration, decision making, and other individual-to-individual and team-to-team interactions. Teams need to ask questions such as:

• How will we collaborate with customers?
• How will members from different feature teams collaborate with each other?
• How will the team in Atlanta collaborate with the team in Seattle, or Bombay?

Once we figure out how people are going to collaborate, then, and only then, should we figure out the organization, processes, and practices that will support that collaboration.

Most project management approaches include a communications plan. The Project Management Institute's A Guide to the Project Management Body of Knowledge (Project Management Institute 2000) includes communications management as one of its key knowledge areas. However, communications is not enough. Communications is basically one wayI send you information (even if you send some back). Collaboration is much more than communication; it involves interaction to produce some "joint" result. Collaboration integrates your ideas and mine into a whole. We communicate status reports to management. We collaborate among project team members using practices such as whiteboard brainstorming sessions to create a design. Throughout the product development world, in industry after industry, the rising tide of cross-functional teams speaks to the need to collaborate.

When formulating their self-organization strategy, teams should ask the following questions:

• Who needs to talk to whom when?
• How are these people who talk to each other going to make decisions?
• Who is accountable for what?
• What practices are they going to use to facilitate the above?

While this early focus on self-organizing strategy may appear to be a throwback to a serial approach to project management, the fact is that anything and everything in an agile project should follow the philosophy of start quick, do something, get feedback, and adapt. The practices in the Envision phase, this one included, are no different. The larger the project, the more time will be spent in developing a self-organizing strategy, but implementing and adapting the strategy in subsequent phases will ultimately be the critical success factor.

Process Framework Tailoring

Even in an agile project, the broad process framework will be shaped by the organization. For example, product development organizations often employ some type of stage and gate lifecycle framework that products must follow. At each stage certain information, features, or artifacts must be available and approved. In order to balance structure and flexibility, this common framework should be as streamlined as possible, enabling a degree of consistency from a senior executive perspective with flexibility at the project team level. The APM process framework, shown in Figure 4.1, should be integrated with the company's broader product development lifecycle. However, if the company's product lifecycle is overly prescriptive, approval oriented, and documentation-centric, integrating the APM framework will be difficult.

The process framework should strive to identify the barely sufficient (or minimum acceptable) standards for an organization for the project, although "minimum" may be different for large projects than for small ones. The greater the "weight" of this frameworknumber of process elements, number of required artifacts, number of decision gates, greater documentation formalitythe less agile the project team can be.

Because this guiding framework should be designed using the "barely sufficient" criteria, there shouldn't actually be much tailoring by the project team. When project teams begin approaching management with requests for exceptions to the standard framework, it should be a strong signal that the framework has crossed the threshold from bare sufficiency to bureaucracy.

Practice Selection and Tailoring

Agile development and project management are built on an underlying premise that individual capability is the cornerstone of success, and furthermore, that individuals are unique contributors. It follows from these premises that rather than molding people to a set of common processes and practices, processes and practices should be molded to the team itself. While an organization might insist that project teams follow a guiding framework, there should be flexibility as to what individual practices are used to meet the needs of each phase. The team should discuss what practices are going to be used or not used. Just because a practice is a good one doesn't mean it needs to be used in every project. There should always be a discussion about how to approach each iteration; what was done in one may not be required for the next one. With individual practices, each team will tailor them in different ways according to the capabilities of the team members, the size of the project, the number of customers, and many other factors.

There are four fundamental questions the team should ask itself about the practices they select and tailor for a particular project:

• What practices are required?
• What supplementary practices do we need?
• What modifications do we need to make to the selected practices?
• What level of formality or ceremony should be used for documentation, approvals, changes?

In addition to a barely sufficient process framework, organizations may also specify a set of barely sufficient practices for each project phase. For example, developing a feature-based, iterative release plan is a requirement, not an option, for a company applying APM, although the practice can be tailored for characteristics such as iteration length. The practices in this book can be viewed as an initial cut at a barely sufficient set of practices. There may be supplemental practices that teams need to employ, but the 18 practices discussed in this book approach a minimum set.

The 18 practices of APM focus on delivery activities, but as previously noted, every organization also has compliance activities and deliverables that need to be added to the set of required delivery practices. While project managers can attempt to reduce these as much as possible, at some point the team just has to accept some level of compliance work and add those practices to the required set.

The best trigger for implementing supplementary practices is to note when something isn't working through an iteration or two. If problems or risks are getting lost, for example, an issues recording and monitoring practice may need to be instituted, although project teams may add this to the supplementary list during the Envision phase. Team members and project managers need to fight the tendency to add supplementary practices earlythey need to wait until a specific and significant need arises.

"Significant need" is an important qualifier. Too often, reasonable mistakes (after all, innovation requires both successes and mistakes) are followed by knee-jerk reactions to add controls or new reports or new restrictions on the development team. For a large number of these "mistakes," much more time and energy goes into processes and procedures to prevent them from occurring again than would be spent on a "fix on occurrence" strategy.

As with adding supplementary practices, teams should usually wait to modify practices until after they've tried them for an iteration or two. If the practice itself has been defined using the barely sufficient principle, it will usually get the team started. In large projects, the team may determine early that a practice isn't sufficient and enhance it.

The implementation of documentation and approvals is often what separates bare sufficiency from bureaucracy. The breadth of things that are documented, the formality or ceremony of that documentation, and the review and approval processes for the documents can determine whether a practice, or process, is streamlined or not. For example, a change control practice (which in traditional projects often becomes a change resistance practice) can be a simple activity of discussing changes and documenting them minimally , or it can be an elaborate process of documentation, analysis, and review that eats up both time and paper. Author Michael Kennedy (2003) relates the view of documentation in the Toyota product development system: "At Toyota, specifications are the documentation of the results, not a recipe of the plan."

When tailoring their documentation practices, teams should consider distinguishing between permanent documentation (which is consistently updated because a budget has been established) and working papers (which don't need to be updated). They should also contemplate the level of ceremony they needrough notes work fine for many, many documents. [11] In order to use key engineering staff effectively, project managers should offload nearly all compliance documentation to administrative staff. The issue isn't zero or burdensome documentation, it's first what documentation contributes to delivery (today and in the future) and second what documentation is required for external compliance (regulations, for example). Colleague Lynne Nix has a great mantra for documentation: "A little documentation goes a long way if it's the right documentation." [12]

[11] For example, new Xerox copiers can take hand-written notes, create a photocopy, and e-mail it to you. This is a nice way of getting electronic document and storage with little or no effort.

[12] For additional information, see (Rueping 2003).

In the early to mid-1990s knowledge management practices placed an emphasis on explicit (written) knowledge, but in more recent years the pendulum has swung toward an emphasis on people and tacit knowledgeknowledge shared through interaction. When the critics of agile approaches decry the "lack" of documentation, it's enough to make one scream, "The issue is not documentation; the issue is understanding." Understanding requires a blend of interactive conversations and documentation. The agile philosophy is that when documentation is used to replace conversation, it is misused. When it is used to complement conversation, it is used correctly.

Early Planning

There are always activities that need to be identified, and often planned, prior to the Explore phase. For example, end-of-iteration customer focus group reviews require the attendance of customers who may not work with the project team on a day-to-day basis. It therefore behooves the project team to schedule these review sessions early (at least for the first three to four months). Waiting until a few weeks before the session to invite participants usually results in poor attendance. The team needs to review all of the practices in the Speculate and Explore phases to ascertain if any "preplanning" needs to occur.