4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, in the second chapter called “Introducing Agile Project Management”, he tries to strip down the essentials of what constitutes agile project management into something he calls the “Agile Process Map”.

The Agile Process Map

The agile process flows at a macro level from the first steady state to a transition state and then to a second steady state.

When I thought of this general process, I thought of a “Turing machine”, a mathematical model for an idealized computing device that consists of a paper tape which is divided into squares going through a read/write head.    When a square of the paper tape goes through the read/write head, it registers a “0” or “1”, and then the paper tape moves one step forward, with the next square being read by the machine.    The reading of the first square is like the “steady state” described in the graphic above, and then there is a transition state to the next square, which is read during the next “steady state” of the operation of the Turing machine.

Let’s go to the next level in abstraction and talk about what each of the states consist of that are referred to in the above diagram.

Steady State #1

Here are the elements that comprise Steady State #1, labeled whether they are people or documents (“artifacts” in the language of agile)

• Product Owner (person):   this person receives, analyzes, and prioritizes product features required for a successful solution to the requirements given by the customer
• Product Backlog (artifact):  this is where the product features are listed by the Product Owner
• Iteration Backlog (artifact):   this is where the product features are chosen out of the Product Backlog that the Team will work on during the iteration.
• Team (persons):   this is the group of people that will take the features listed in the Iteration Backlog and develop them during the next Iteration.

The reason why this is referred to as the Steady State #1 is because the list of product features in the Iteration Backlog does not change during the iteration.

Transition State

In the Transition State, there are two constants:

• the duration of the iteration
• the goal of the iteration, which is to take the features listed in the Iteration Backlog and develop them towards a potentially shippable product increment, which is a deliverable that adds value to the feature that is recognized by the customer.

Everything else in the Transition State is in a constant state of change.   Here’s how the team shapes its daily meetings to synchronize and plan the activities during the Transition State:

1.Each day when the team meets, each member briefly explains what they have done since the last meeting, what they will do before the next meeting, and what impediments are interfering with their ability to be productive.

2. The team uses the information in the above meeting to self-manage the team’s daily activities:

• each member makes reasonable progress towards the agreed-upon iteration goal; by having daily results that are measurable, external controls are unnecessary because each member holds other members accountable for achieving progress towards the goal
• each member synchronizes hand offs of work to other members as needed
• each member rallies to the support of other members who need assistance
• each member meets with the Product Owner as needed to clarify questions or concerns about features they are working on

Steady State #2

• The team has a review meeting to go over the work done on the Iteration Backlog to make sure it meets the definition of being complete.
• The team has a retrospective meeting  which focuses on the process and not the product to see how the process of creating value can be improved.

Then the Product Owner adjusts the Product Backlog, takes those features needed to be done in the next iteration and puts them on the Iteration Backlog, and you have new Steady State #1, after which the above cycle continues.

Now that is an overview of the agile process.    The rest of the book goes through the individual agile project management processes, of which there are 87, divided into 5 process groups and 7 knowledge areas.

This concludes the material in chapter 2, “Introducing Agile Project Management.”   In the rest of the chapters, the processes are introduced by process group as follows:

Chapter 3:  Initiating Projects

Chapters 4 through 6:   Planning Projects

Chapter 7:   Iterating Projects

Chapters 8 and 9:   Controlling Projects

Chapter 10:  Closing Projects

There is an eleventh chapter on how to pass the exam.

The next post will start on the material in chapter 3, “Initiating Projects.”

Filed under: Uncategorized |