8

AGILE WORK PROCESS: ANYPLACE, ANYTIME

THE VALUE OF AN ALL-PURPOSE FRAMEWORK THAT CAN BE CUSTOMIZED

In Chapter 4, I unveiled the Silicon Valley Approach to Collaboration and explained the three levels: individual skills, team tools, and company practices. When it comes to the team level, it’s helpful to have a process to help organize how multiple employees work together.

Having some sort of “scaffolding” is as crucial for teams working on a project in an organization as it is for construction crews building a skyscraper. Although the specifics will vary from project to project, in general team members need a shared understanding of:

   Overall project goals and how they contribute to company- wide objectives.

   How the elements of the project need to be combined to achieve overall goals.

   Who will be involved and what they will do.

   Methods for capturing and sharing important information.

   Types of meetings and communications that will occur.

   Metrics for measuring success.

Mike Kavis summed it up well in his blog: “I would typically scoff at project charters, team structure . . . [etc.]. But [when a] project consists of . . . multiple teams on various systems . . . there has to be some order to the chaos.”¹

The concept of “process” has become a dirty word in some organizations. As one Process Improvement professional recently blogged: “I’ll bet many of you, upon reading ‘I hate process!’ feel just a little better inside, relieved and thinking ‘yes, someone finally said it!’.”²

Why does this simple concept have such a bad reputation? One leader I interviewed explained that the staff in his company believe that as companies grow, so does chaos. In order to stop the chaos, companies tend to develop processes and procedures. But when companies need employees to invent new ways of doing things, they find that staff following rigid processes have lost the ability to be creative and figure out how to do things differently.

How do they deal with this dilemma at his company? They differentiate between good and bad processes. Bad processes create rules for the sake of efficiency rather than effectiveness. They impose rigid bureaucratic requirements that seem to have very little purpose. Good processes, in contrast, are the ones that help skilled staff get more done. His company concentrates on creating good processes that offer just enough structure without imposing unnecessary layers of bureaucracy.

Several of the leaders I spoke with, work at companies that have created good processes that guide projects without stifling creativity. A number of the others bemoaned the lack of such a framework at their company. There was agreement across most of these folks that having a great, flexible all-purpose process is a good thing. These leaders know that teams that don’t have a customizable process available to them will have to pause and create one from scratch at the start of each new project. Creating such a process is a waste of valuable brainpower that could have been spent working on the content of the project.

Is there a good all-purpose process that can offer just enough guidance and structure to meet the needs of massively different projects? Yes. It is Agile Methodology.

AGILE METHODOLOGY AS YOUR PROCESS

Agile was developed in the early 2000s as a framework to guide the work of software development groups. Because then, a few innovative companies have realized the value of Agile for teams and projects that have nothing to do with software. Some leaders in those companies have customized this methodology for broader use at their firms.

This is a great idea, and I have encouraged many companies to use Agile more broadly. Since then, a few have done so yet, there are not many resources available to guide the use of Agile in non-software projects. I would like to rectify that by devoting this chapter to the translation of Agile concepts for a broad array of projects across your company.

AGILE FUNDAMENTALS

Agile starts with four general values, which are known as “the Agile Manifesto.”³ I have adapted them for your use with non-software related projects.

1. Having real, ongoing collaboration with customers is more important than simply enforcing contracts in a rigid manner.
2. Having results that work is even more important than spending lots of time carefully documenting how those results were achieved.
3. Fixing problems is more important than sticking with the original plan.
4. Quality interactions between staff are even more important than sticking with rigid processes.

These are not simply nice-sounding platitudes to be hung on a poster and promptly forgotten. These philosophies are meant to guide how work actually gets done.

There are 12 “Agile Principles” that expand on the four values.⁴ Adapted for non-software projects, they are:

1. Our highest priority is to satisfy our customers by delivering segments of work that move us toward our project goals.
2. We try to deliver small segments frequently and get feedback from customers to determine, as quickly as possible, if there’s a need for any changes.
3. The primary measures of progress are that those segments thrill customers and contribute to overall project success.
4. We are willing to change what we are delivering even late in the project if that helps to meet the customer’s needs, as long as the costs of such changes are acceptable to all.
5. We involve motivated individuals, give them the support they need, and trust them to get the job done.
6. We set the stage for those individuals and teams to work together throughout the project.
7. The most effective and efficient means of communication and interaction will be used to ensure that the work is done right and the results are optimal.
8. Agile processes promote a pace of work that should be sustainable indefinitely.
9. Continuous attention to good design and content excellence enhances project results.
10. Simplicity is valued over complexity. The idea is to do the work as simply as possible while achieving the project’s goals.
11. Teams are empowered in ways that make sense for this company and industry.
12. Every so often the project team reflects on how to be more effective. Then, it fine tunes its behaviors.

In my work with companies using Agile, I have developed other important tips for getting work done in an Agile environment.

   Create just enough structure to guide the project without imposing unnecessary constraints.

   Do just enough up-front planning to effectively launch the project.

   Use iterative processes to design and deliver the project in segments or pieces. (With an iterative approach, a small amount of work is performed, tested, and tweaked before proceeding with the next portion of work.)

   Conduct detailed planning right before you start working on each new segment to integrate lessons learned and changes made in previous segments.

   Involve customers and stakeholders in the project.

   Managers are mainly guides, coaches, and barrier-busters. Team members are empowered to make many decisions related to the work and are given sufficient information and context to allow them to make the right decisions.

   Foster a spirit more akin to Apollo 13 than the ill-fated Challenger space shuttle (speaking up, listening, willing to share unpleasant information about things that aren’t working).

   Generally, assign roles based on expertise while also fostering a willingness to pitch in to help others get the job done well.

   If the project’s parameters change, evaluate them against time and cost constraints.

   Everyone should own accountability for the entire project, in addition to their portion of the work.

   Use regular, quick check-in meetings and other appropriate methods of interaction and communication.

   Perform the most critical and hardest work first.

   Openly share project information with any interested employees or customers.

UPFRONT PROJECT PLANNING

Some project management processes encourage a staff person to lay out detailed plans for the project before any work begins. That person creates goals for the project and uses those goals to spell out the objectives and detailed steps outlining how the work should be done to achieve those objectives. Then they estimate the staffing, financial, time, and other resources that will be needed to achieve the project’s objectives to make this happen. Next, they determine what people will be involved in which parts of the project. Sometimes they even outline who is responsible for making what decisions. This detailed planning is based on the belief that having a very specific road map will help the project run smoother, minimize changes as the work proceeds, and constrain unnecessary costs.

Unfortunately, detailed, up-front planning like this can create more problems than it solves. It often does minimize changes as the work goes on, and that’s the trouble. Planners usually cannot know enough about the project upfront to accurately estimate all those details. They do the best they can with what they know. But, as the project proceeds, the plan usually needs to be changed. If the up-front plan is treated as sacrosanct, then necessary changes are prevented from happening.

Agile projects put just enough detail in the up-front plan so that the project’s sponsors and owners know what they are committing to. Project planners work with leaders to determine how the project will contribute to company-wide directions, the goals of the project, and a reasonable estimate of the people and other resources that are likely to be needed. Other details emerge in mini-planning sessions that kick off the work on each segment.

Instead of doing all the detailed planning on their own or with just a few others, the project planners create an agenda for a kick-off session. From that point on, planning is a team sport. The members of project teams are invited to this initial meeting along with the project’s customers. Together they turn project goals into a Project Charter that outlines the scope, major work segments, deliverables, and people to be involved in that segment of work. They agree on metrics that will be used to measure success and they uncover opportunities and risks that need to be monitored.

During this initial meeting, participants hear important messages directly from leaders. They learn how this project helps the company and they engage in a dialogue that puts the work in context. This conversation leads team members to feel personal ownership of the project and its success. It also allows individuals to get to know others in ways that build trust, respect, and the desire to help others succeed.

User stories are a great tool to guide project work; they can be created in this initial kick-off meeting. User stories describe the desired end state of a project and specific elements within it. These stories are often created by customers and employees assigned to this project, working together. The amount of detail included in the stories varies depending on the complexity of the project and the newness of ideas involved. The customer starts by describing the problems that led to this project. Then they describe what success will look like for various aspects of the project. For a complex project in which staff will be innovating new ideas, the customer desires are usually drawn out in greater detail. Those details can be part of the same story or can be split into mini-stories.

While they are in the same room, the teams not only work out the plan for the whole project, they take some time to outline the work of their own teams within the project. Then they can negotiate what they think they will need from each other while they are face to face. This gives the project a much smoother start than is possible for projects in which each team does their own segment-level planning separately.

The group determines the order in which the work segments should be completed. One of the differences between Agile and other project-planning processes is that in Agile the toughest work with the highest risks is done first. Other processes often leave the hardest parts for later. Unfortunately, when the tough areas are finally tackled, previously unknown issues may arise that require work to be redone. In the Agile universe, the best way to reduce rework is to do the tough stuff first.

Other important aspects of the project can also be discussed in this kick-off session. For instance, if certain work needs to be done in a certain order. Other items to be discussed are specific to the needs of that project. A general principle of Agile is to keep procedures to a minimum, providing just enough structure to get the job done without unduly constraining employees.

INITIATING THE WORK

DETAILED PLANNING

Because Agile requires less up-front planning, there is a need for more planning at the start of each work segment. The people with the expertise to plan that segment effectively should be brought together to conduct that planning. If possible, customers should be included in these sessions.

The group decides what work components need to be completed as part of this segment, the priority of those components, and who will be involved. At this point, they also detail the budget and estimate how long it will take to do the work.

As part of this planning, the group develops the criteria they will use to determine when a piece of work will be considered complete and measure the quality at which that work needs to be done. If you are designing and manufacturing parts for an airplane you will want to ensure that your work is error-free. That level of perfection is not required when creating a software game. In general, Agile tries to be thorough and accurate while not going overboard or seeking perfection. But the desired level of quality should depend on the particular project.

If the work is complex and/or of a large volume, the segment is split into manageable pieces, because a core principle of Agile is that sections of work be delivered frequently. Rather than create one large segment that might take months to complete, that work should be split into sections called “sprints.”

PERFORMING, TRACKING, AND COMMUNICATING ABOUT THE WORK

Once work begins on a sprint, no additional changes can be requested. Although the goal of Agile is to remain flexible to customer needs, at some point the plan needs to be stabilized in order to allow employees to complete their best work.

If complications arise during the work, ideally the budget and time estimates will remain fixed and the work will be adjusted as needed. Some of the planned work may be put on hold if problems are encountered in achieving it. That work may be resumed at a later point if possible or everyone may agree to drop that particular part of the project.

Another principle of Agile is that staff pitches in to help others even when a particular task is beyond one’s usual job description. This can require a culture change at companies where staff hold rigidly to their role and consider it stepping on another’s toes to reach out to help. In Agile cultures, employees are rewarded for stepping outside their formal roles when it benefits the project.

A number of tools are available to help manage and communicate the status of the work in Agile. They’re often called “information radiators.”⁵ For instance, a task-board is a visual display of progress made by a team during a sprint. The board shows what is being worked on, progress, and any issues that have arisen. Another tool is a “burndown chart,” which is a graph that represents work and time remaining. These tools are available to anyone who is interested in knowing how the project is going. The team should hide nothing from itself or from visitors. It confronts issues openly and directly.

At the conclusion of a sprint, the work produced during that period should be provided to the customer. Rather than just dropping it off and considering it completed, a dialogue then takes place. Customer feedback from that dialogue helps uncover any possible issues or desired changes. Although the work was closed to changes at the beginning of the sprint, alterations can be considered at this point if they will improve the project. One of the fundamental principles of Agile is that it is iterative and integrates lessons as work proceeds. Although this may slow progress a bit at times, the result will usually be a higher quality and more pleasing to the customer.

One leader explained, “If you design and build what the customer thinks they want before you begin the project, then you often design and build something that really isn’t what they wanted. Through an iterative process, you pull out what the customer really wants that they cannot articulate up-front.”

MEETINGS

STAND-UP MEETINGS

“Stand-up meetings” are a feature of the Agile framework. Team members are brought together on a regular basis to share progress they are making and resolve any issues. The frequency of these meetings depends on the needs of the specific work segment.

The meetings are designed to be quick check-ins and the concept of standing up is literal. With everyone standing, only crucial topics are discussed, encouraging team members to be efficient. Stand-up meetings often discuss the following kinds of open-ended questions:

   What have we accomplished since the last meeting?

   What problems are we having and where might we need help?

   What have we learned that might help others?

   What do we plan to achieve by the next meeting?

   What might we need to change, let go of, or accelerate?

Team members need to understand what others are working on and how it fits into the overall project. This will help staff make the right decisions on both small and large issues. These meetings are not intended to be status updates between the project owner and each participant. Instead, in a typical stand-up meeting you go around the room and everyone summarizes their work and answers questions. The group then decides if any changes are needed.

One of the goals of the stand-up meeting is to identify and fix failures earlier in the process. Achieving this goal depends on a culture of openness in which it is appropriate to speak freely about things that are not working well. There should be no sacred cows or undiscussables in these meetings.

In the words of one leader, “In an Agile environment where you hire smart people, they assume expertise in others and don’t start from a cynical place where they are judging others negatively. They recognize what others can contribute and listen to those other ideas.”

RETROSPECTIVES

Every so often, either when work segments are completed or at big milestones, Agile brings together all the employees working on the project and their customers. They examine how the work is going, and identify improvements they want to make as they move forward. This is known as a retrospective meeting.

This is not intended to be a “blamestorming” session; there is a delicate balance between speaking up on tough subjects and recreational whining. Because it’s often a fine line, you may want to have these meetings run by trained facilitators who are experienced in discerning that difference and can help attendees accomplish these goals.

MANAGEMENT ROLE

Managers play an important role in Agile; it is different than the role they play in other kinds of projects. One leader with whom I spoke affirmed: “There is a strong role for the manager. But it is not so highly prescribed that it looks exactly the same in all companies or even across different projects in the same firm.” For instance, in some project teams, the leader facilitates the stand-up meetings. In other teams she or he sits back and encourages others to take that role. It depends on the style of the leader and the culture of the team.

The following list summarizes some of the more important roles for managers in Agile projects. ⁶

   Hire and retain great employees who are motivated to grow their expertise and do the best they can.

   Provide a connection between organizational direction and current projects. Do this regularly, not just at the initiation of a project. Provide the context that enables employees to make appropriate decisions at their level.

   Partner with the team to create inspiring goals for the project.

   Create an environment that promotes continuous learning and growth. Host learning sessions and recognize employees who learn on their own.

   Create an open, transparent environment.

   Support teams in problem identification and solving, and teach employees how to fix problems more effectively. The teaching role is key, because it helps employees learn how to fix the problems themselves rather than doing it for them.

   Remove barriers standing in the way of employees doing better work.

   Be available to staff when needed, without doing the work for them.

   Help determine and obtain the resources that enable the team to do their best, and that reflect organizational commitment to this project.

   Build partnerships with others in the company. Reinforce the right level of connection with other teams.

   Protect the team from unnecessary distractions.

   Be a career coach and advisor for employees, assisting them in ongoing professional development. Provide performance feedback and rewards that encourage employees to do their best and that reinforce appropriate career paths for each individual.

The difference between the managerial role in Agile and in other project management methods is that in Agile, managers are no longer assumed to be the one and only project sponsor or owner. It is their job to ensure that employees understand how they are contributing to overall company goals and continue to provide information and set the context throughout the project. It is also their job to partner with employees working on the project to maintain crucial relationships with others teams. Additionally, it’s their job to retain great employees by continuing to work with them on career goals. It is also their job to work with employees who are underperforming or otherwise not contributing to project progress.

(Management roles in collaborative environments will be discussed further in Chapter 10.)

MANAGING SCOPE CREEP

“Scope creep,” for those who might not be familiar with the term, refers to continual expansion of project goals through uncontrolled growth and by adding work that was not part of the initial scope of the project.

Because Agile defines fewer details of a project in up-front planning and because it has a philosophy of remaining open to appropriate change as the project proceeds, some fear that this project management methodology leaves it more open to inappropriate scope creep than other processes. The crucial distinction hinges on the definition of “inappropriate.”

Imagine that your team is producing your company’s next version of a highly popular, low-priced digital camera. Suddenly a competitor introduces a camera with picture clarity that is much better than yours. As soon as this becomes known, some staff panic. They feel that the project teams should pause their work and determine how to increase the picture clarity of this camera so it will be competitive. They argue that if the camera is completed with the old specifications then nobody will buy it. It will be obsolete before it’s even released.

Other employees argue that the changes would have to be massive and that because the work is so close to being completed (the camera is 90 percent complete) it doesn’t make sense to integrate such a big, new goal at this point. They feel that the costs would be prohibitive and spell the failure of this project.

If teams are rewarded only for producing what they agreed to do up-front, at the cost that was estimated, then leaders will decide in favor of those who are resisting the changes. If teams are rewarded for producing what the company actually needs, then leaders will decide in accord with those who believe the project should be paused to come up with better picture clarity or some other improvement to give the camera a competitive edge over the one that’s just been released. In Agile, it’s much more likely that the latter will happen: that the project will be paused to determine how to make the camera better.

What makes Agile useful is not that it accepts all changes proposed at any point. It attempts to teach employees how to do tradeoff analyses and how to make those tough decisions. Here are some tips for making those trade-off decisions⁷:

   It is not scope creep if detailed planning has not yet begun.

   It also is not scope creep if it creates no additional work.

   It is sometimes acceptable scope creep if these changes could not have been known at the start, and if the delivered product better meets expectations regarding what is needed.

   It is usually acceptable scope creep if those important changes fall within the “contingency allowance” that was set for the project.

   The ultimate goal is the integrity of the project.

THE TAKE AWAY

Agile is not anti-planning. Nor is it anti-documentation. Agile recognizes the need to capture how things are being done. It also recognizes that many project management processes make documentation one of the chief priorities. In doing this, they place capturing how things are being done above actually doing the work. This is not a good thing.

Leaders are sometimes concerned that Agile might not be applicable for larger projects. In practice, I have found that its flexibility allows the inclusion of as many or few project segments and work groups as are needed.

Agile is also accused, at times, of being undisciplined and lacking accountability for project results. The short, defined sprints with distinct deliverables counter that complaint.

Agile is not a magic bullet. It doesn’t fix all the problems that other project management methodologies encounter. It has plusses and minuses as well. It doesn’t anticipate or provide everything you need for every project, but it is a useful tool for project management across a wide array of projects that a company undertakes.