4squareviews

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first blocs of processes, those in the first process group (the Initiate process group) and the first two knowledge areas (External Stakeholders Engagement and Value-Driven Delivery).

Now, I am embarking on a description of the third block of processes, those in the first process group (the Initiate process group) and the third knowledge area (Adaptive Planning). Adaptive Planning might be better termed “Juggling the Constraints”.

I covered the first two of the four processes in this knowledge area, Process 3.1 Team Acquisition and Process 3.2 Project Kick-Off Meeting, in previous posts.  This post will cover the last two of the four processes in this knowledge area, namely Process 3.3 Incremental Delivery and Process 3.4 Timeboxing.

The first two processes in this knowledge area of agile project management share features with the tools & techniques used in traditional project management.   For example, team acquisition can be done in both agile and traditional PM through a) negotiation (with functional managers for team members within the company), b) acquisition (for team members outside of the company on a temporary basis), and pre-assignment (for team members designated as being desired on the project in the project charter itself).   And the kick-off meeting is important in both agile and traditional PM environments, although the agile version contains more emphasis on elements of team-building exercises.

With Process 3.3 Incremental Delivery and Process 3.4 Timeboxing, however, agile comes into its own.

Process 3.3 Incremental Delivery

To explain how incremental delivery works, it might be best to review the three categories of project lifecycles as set forth in Chapter 2 of the PMBOK Guide.

Project Lifecycles

1. Predictive life cycles (aka fully plan-driven) are predominant in traditional PM, where the project scope, and the time and cost required to deliver that scope, are precisely determined as early in the project life cycle as practically possible.   For the image of this, think of a series of blocks connected on a straight line, which each block representing a phase of the project.
2. Iterative life cycles are predominant in traditional PM, where the project scope is developed at a high-level in the first iteration, and the detailed scope is elaborated upon in subsequent iterations.   Sometimes this process is referred to as progressive elaboration.   A special form of this, which I personally refer to as “progressive elaboration on steroids”, is rolling wave planning, where the detailed scope of the initial phase of the project is completed and the project is started while the detailed scope of the subsequent phases are still being elaborated upon.   This is like laying the tracks of the railroad while the train is starting to come down the tracks.   Although it captures some of the flavor of the agile PM process in terms of iterations, it is still considered as part of the toolkit for traditional PM because of the assumption that eventually the scope of the project will be precisely determined.  An image that I find helpful here is a helix, which is the pathway you take around a cone that narrows to a point.  It starts out with wide circles that gradually narrow as you get closer to the point, which represents the place where the scope ends up being completely defined.
3. Incremental life cycles (aka agile or change-driven) are predominant in agile PM, and these share the feature with iterative life cycles that iterations are used.   However, the iterations are rapid (2 to 4 weeks in duration) and are fixed in time and cost.   The major shift is in mindset, because incremental life cycles are used for when there are high levels of change, when requirements and scope are difficult to define in advance.   An image that In find helpful here is a spring, which goes around and around in circles that are always the same height.   Of course the spring does end, but it is not at the point where the scope ends up being completely defined, rather it is the point at which the customer is satisfied with the value delivered at the last iteration when either the time or cost constraint has been depleted.

Incremental delivery focuses on delivering value to customers at the end of each iteration.   In order to do this, the next process 4.4 Timeboxing serves to define that iteration or timebox.   For the sake of brevity, I will use the scrum term “timebox” for “iteration” in the explanation of the next process.

Process 4.4:  Timeboxing

Here are the various elements that go into defining the timeboxes that will be used for incremental delivery to the customer.

1. Defining the length of time for each timebox–since each timebox begins and ends with specific planning and review activities, there is a specific “overhead” that is fixed at each end of the timebox.   Usually timeboxes are specified as to be 2 or 4 weeks in duration.   Having a two-week timebox gives more flexibility and opportunities for customer engagement, but essentially doubles the “planning and review” overhead for the span of the timebox as compared to a four-week timebox.
2. Defining the vision of the project–this will guide the types of work the team will be required to accomplish in each timebox
3. Defining the human resources–team members must have the right knowledge, skills, tools and processes to accomplish the work in each timebox.
4. Defining the environment–the environment is preferably collocated, but even for those members who work virtually on the project, the right tools and workspace need to be defined so that the team members can work together as a team to accomplish the work in each timebox.
5. Defining the communication protocols–communication requirements are defined so that members can transmit ideas to other members of the team transparently.   This is opposed to the “need-to-know” basis that some projects use as a guiding principle, which often translates to “if you’re on the team, you don’t need to know.”
6. Defining the high-level architectural outlines of the timeboxes–since the iterations often fit into higher-level cycles such as release plans (corresponding to project-level plans in traditional PM) and roadmaps (corresponding to program-level plans in traditional PM), you must define the architecture of the timeboxes, i.e.,  how the timeboxes fit into the larger cycles so that it deliver values to the customer incrementally AND serves the emergent design of which the iterations are a part (at the project and program level).

Because timeboxes define the work environment for the entire project, that is why so much care is given to their definition.   Just as in the same way that “ground rules” for collaboration are set up at the kick-off meeting when team members meet each other for the first time to work on the project, ground rules for the iterations or timeboxes within which they will be doing that work are also essential.

This concludes the discussion of the third knowledge area, Adaptive Planning, in the Initiate process group.  The next post will start the discussion of the fourth knowledge area, “Team Performance.”

Filed under: Uncategorized |