Agile projects are more iterative than classic ones. At a high level, this means that instead of first developing a complete plan and then executing it, we may do a less detailed plan, execute, analyze, and then repeat. This cycle may recur many times during the course of the project. For example, planning is generally a collaborative effort since the agile project is made up of a network of related activities. Execution may or may not require collaboration, and the same is true for analysis. Furthermore, each collaborative step may require a different group of people getting involved. Adding this “work modality” dimension to the already numerous “task or functional” dimensions makes the agile project that much more interesting.
Agile Strategy Find individuals who have successfully worked remotely on projects in the past. They are likely to thrive in the agile environment because they can efficiently shift between work modes.
Identifying people who can efficiently switch work modes may not be the easiest thing to do, however. When trying to determine whether potential team members have this capability, an indirect approach may be best. I believe a place to start is to look at your organization’s remote workers or telecommuters, because their work characteristics are similar. Human resources professionals have spent a lot of time trying to figure out which employees they will allow to telecommute or work remotely. I argue that team members who can effectively telecommute also have the ability to effectively switch work modalities as necessary in the agile project environment. They are able to work with minimal guidance in an unstructured environment, they know how to use technology to their advantage, and they can deliver the results necessary to keep the project moving.
Technical Skills Versus Adaptability
When assembling a classic project team, the project manager or sponsor will generally rank technical skills as the number-one requirement for hiring a new team member. Soft skills, such as flexibility and adaptability, are not make-or-break hiring criteria, though they may act as a tiebreaker between two candidates with identical technical skills. This makes sense because once the primary planning process is complete, project execution becomes dominant, and that’s when having the right technical resources counts. The key here, though, is that in the classic environment, the project plan (including resource requirements) is generally stable.
In the agile environment, the large amount of uncertainty produces frequent changes in the plan, so project teams must be flexible enough to deal with these direction changes in an efficient manner. This fact alone elevates the importance of “adaptability” on the hiring criteria spectrum (see Figure 6-1). To take this thought one step further into the agile realm, consider that a single change in the project plan could obviate the need for a particular type of expertise altogether. If you’ve just hired someone with that specific expertise, and only that expertise, then you’ve got a problem. What are you going to do with that person? Hopefully, the people you hire are adaptable in both attitude and skills. By attitude, I mean that they are willing to work in areas outside of their primary expertise for the benefit of the team (many people refuse to do this). And, of course, they should have actual skills in other areas that will benefit the team.
Figure 6-1: The hiring criteria in an agile versus classic project management.
When selecting people for your agile team, you really want people who have broad technical skills and an attitude of adaptability. This combination of skills gives you the best chance of weaving them into the agile project team, as well as having them make meaningful and enthusiastic contributions.
This idea of adaptability may be so important in some agile projects that candidates with strong adaptability skills can arguably be elevated above those with superior technical skills. Those people who can develop and nourish the network of ideas and activities that make up the agile project are the core of your project team. They must, by definition, have broad skills and demonstrate adaptiveness for the simple reason that they are tasked with performing so many different functions. These functions include pulling together information from many sources, organizing it in the context of the project, and then turning it into the next steps that will move the project forward. Another way to look at it is that purely technical skills can be outsourced to any number of firms or free agents, but your core team cannot.
Agile Strategy Outsource specific technical activities that are not necessarily hubs in the network of the project plan, and therefore are purely support for the rest of the project.
Developing a high-performing team is never easy, but it can be exhilarating if you are successful. The agile project environment presents its own unique challenges in the team-building area. Hopefully, you’ve gained some ideas that will help your team move to the next level.
Summary
The ability to create networks is a valuable and uncommon skill for an agile team member.
The agile team must be able to deal with changes in the project and must be able to drive changes in the organization.
Find people for the agile team with the uncommon skill of being able to reinvent their organizations.
Making the organizational changes dictated by the project team will ultimately lead to more agility in the overall organization.
Agile team members will need to continually switch between working together and working alone.
Adaptability may be more important than technical expertise on the agile team.
Purely technical skills can always be outsourced.
Chapter 7: Planning for Agility
Overview
Planning is usually one of the most painful, undervalued, and even vilified project management activities in the agile environment. Why? Project managers are most likely attempting to apply a classic planning process when they need an agile one. This chapter examines some of the key characteristics of planning required in an agile environment and how to recognize them, reduce the pain, and enhance the value of planning.
Today’s projects are urgent, exciting, and critical to business success—and they provoke different spoken and unspoken feelings about planning: “We need to move fast out of the gate or we’ll risk losing out to the competition”, or “Spending up-front time planning will slow us down. I already know what to do, so let me go start doing it!”
On the flip side, you will rarely find an experienced professional who is 100 percent against any sort of planning activity. “We need a plan that will guide us to our destination. In fact, a good plan is almost indispensable”, or “I wouldn’t agree to even start work on a project without a plan”. These reflect some of the supportive feelings about planning.
So where is the disconnect? On the one hand, planning is a waste of time. On the other, it’s a must do. The answer lies in recognizing that business and projects have changed. Nowadays there’s incredible urgency to move fast. There is also project uncertainty, which makes us nervous about solidifying requirements or committing to a schedule. Our common sense tells us that we obviously need a plan, but our experience tells us that there is not enough value added for the effort expended, and furthermore, the plan may come back to bite us. We need agility—and planning seems to be an obstacle to obtaining it.
Classic planning conjures up images of large meetings, work breakdown structures, Gantt charts, resource loading, all sorts of swags, and long-range commitments. This may be a slight exaggeration, and I don’t want to belittle this type of planning because it is highly effective for managing projects in which the basic steps are well known. Installing and validating a new piece of production test equipment is a good example. We know how to manage this process, but since this is a new piece of equipment, it will be slightly different from the last installation project. In this classic environment, there is no good reason why we shouldn’t be able to create and commit to a detailed plan of this type.
But what about the agile environment, where we are trying to create something totally new and nothing similar has been done before? Does the classic planning process still make sense? Probably not. We shouldn’t be spending a lot of up-front effort planning six or more months out when a discovery or decision made in the next three weeks could change everything. This is an important point, but often it’s hard to recognize, especially when the level of uncertainty is not clear.
Agile Strategy Only extend your detailed planning into the foreseeable future, to the next milestone or decision point, but not much further. Extended plans are risky and can frustrate team members being asked to create them.
To the project manager, a new project may seem similar to previous efforts, but to the technical team it may present totally new challenges. Since the project manager is not usually the technical expert, the level of project uncertainty should be discussed and agreed to early in the planning process by all key players. By making this effort up-front, the project manager is helping to set the tone regarding the planning methodology for the remainder of the project—specifically, how frequently or infrequently planning activities will take place. Essentially, the team should be expected to have detailed plans, but only up to the point where the project direction is still clearly visible. Once we reach the point where project uncertainty starts to blur the course, we will limit planning to high-level pathways. For example, let’s say that we plan to produce a small lot of prototype circuit boards in three months. The next stage of the project is testing, which will ideally be at the final product level but may have to be at the subassembly level, and each of these pathways have specific and unique details that need to be planned out. The decision on which path to take depends on the delivery of a series of other components by outside suppliers who are running into difficulties and can’t currently commit to a delivery date. Classic PM methods would teach us that we should have a detailed task list for completion of the circuit boards, as well as for each contingent pathway (final or subassembly-level testing). In the agile case, we also have a detailed timeline for completion of the circuit boards, but we only want a high-level understanding of the requirements for doing either final product or subassembly testing at this time, not the detailed task planning. In this way, the team will not get frustrated trying to create details around something that is too far out in the future, while the project manager will still be getting solid plans for the near term. Once the uncertainty around the outside supplier clears, the team would know which path to take and create the necessary detailed plans.