4squareviews

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post concerns the process of controlling agile contracts that were entered in process 2.3.

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed the three different types of contracts in traditional project management to give a contrast to the agile contracts discussed in this post.

Traditional PM Contract Types

As a recap, here are the three types of contracts used in traditional PM.

Three Types of Contracts in Traditional PM

The three types of contracts in traditional project management are:

1. Fixed price
2. Time & material
3. Cost reimbursable

In terms of cost risk, you can list the three types of contracts in the following way, where a higher cost risk to the seller is to the left, and a higher cost risk to the buyer is to the right.

Fixed Price –> Time & Material –> Cost Reimbursable

Fixed price contracts tend to be used when the scope is predictable, and thus a fixed price is readily obtained for the component.   Cost reimbursable contracts, on the other hand, are used for when the scope is NOT so predictable, and thus the cost of the component cannot be so readily obtained.

Inherent in the fixed price and cost reimbursable contracts are the tension between the seller and buyer in terms of cost risk; fixed price favors the seller and cost reimbursable favors the buyer.   That is why there are mechanisms in place (ceiling price, incentive fee, etc.) to make the cost risk more equitable on either side.

Agile Contracts Types

In agile contracts, on the other hand, all three types try to balance the cost risk between seller and buyer, and the difference comes to not how they are structured in terms of cost, but how they are structured in terms of time.   Agile iteration contracts are done for the duration of an iteration.  Time & Material contracts are done for an arbitrary period of time.  Phased development contracts are done on a quarterly basis.

One feature that agile contracts have in common with traditional PM contracts is that they tend to be risk management tools.   In the case of traditional PM, the focus is primarily on cost risk.

1. Agile Iteration Contract–this is based on each team delivering agreed upon features to defined quality standards by iteration end.   NOTE:   The Product Owner is NOT allowed to change the iteration backlog DURING the iteration.
2. Time & Material–this is based on a customer continuing to pay a customer during an agreed-upon time period until such point that the customer doesn’t see value being added, at which time the customer stops paying and the contract ends.
3. Phased Development–this is based on the team achieving a successful release of the product.

In agile contracts, cost risk is a factor as well, and the time period of the contract is chosen based on the needs of the customer and the size of the project, but the agile contract helps manage other areas as well.   Here is a chart showing how the four areas of scope, risk, communication, and cost management (related to issues of invoicing and payments) are dealt with in the three types of contracts listed above.

The overall point to remember with agile contract is that the relationship between the customer and team is paramount; the contract is merely a formalizing of that relationship and a way of dealing with risks that may occur in the future so that the customer and team can essentially put them aside and focus on their working relationship in the present.

Controlling Agile Contracts

The first word that should come to mind when thinking of the word “controlling” in project management is the companion word “monitoring”.   First you monitor to see if the contract is being carried out as planned, and then if it isn’t, THEN you control the situation, either bringing it in line with the contract or modifying the contract as necessary.

The key point is that, just with traditional project management, a contract divides the shared risk between the parties and thus defines what the pressure points of trust are between them.

The best practice in monitoring a contract is to define a small number of high level user stories that include acceptance criteria that are the conditions of satisfaction for each story.   The conditions of satisfaction need to be discussed during the process 2.3 so that the development risk can be seen as adequately being covered and equitably being shared in the course of the agreement.

Any effort spent defining the conditions of satisfaction will pay for itself in the time and cost avoided having to mitigate any undefined requirements later.

Another element of good contract control is good estimating, so that both parties can realistically determined the amount of risk each party is sharing.

Periodically monitoring the contract is not questioning the trust of the parties; it is building a solid foundation so that such trust can be built upon during the course of the project.

The next post covers the issue of earned value management in agile projects.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

This post covers Accounting Control, one of two parts of process 2.12 (the other one is Contract Control).

Accounting control is measuring performance against a cost baseline, which is created in the following steps:

1. Create a release plan
2. Forecast cost per iteration
3. Establish a cost baseline

However, at the end of each iteration, just like the grooming of the product backlog, the cost baseline should also be reviewed before each iteration and re-calculated based on any changes made to the product backlog (which may effect step 2 above) or the release plan (which may effect step 1 above).

If an earlier cost estimate has been decided to be mistaken, then the team needs to alert the Product Owner or customer/proxy to discuss the implications so that proper decisions can be made.   Any changes must be negotiated with and approved by the customer/proxy.

For most organizations, doing accounting control at the release level is not enough; it must be done at the story level in order to get control of the cost baseline.

The other type of control that must be maintained is that of Contract Control, which is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now covering the set of processes done in the control process group of an agile project, specifically those processes that have to do with the knowledge area of Value-Driven Delivery (equivalent to the “Quality” knowledge area in traditional waterfall project management).

In the last process 1.11 Product Demonstration, a validation process is done prior to a Release of the project.   Thus it has the same goal as a Review meeting, but is obviously at a higher level of importance because it is done prior to the Release of the product to the public.

Well, if you show the stakeholders the product, there are two possible reactions:

• hey, that’s just what we asked for!
• wait a minute, that’s not exactly what we asked for

And I suppose a third possibility is, “hey, that’s just what we asked for before, but since then we’ve changed our minds.”   In any case, if there are certain features of the product which do NOT meet the satisfaction of the stakeholders, then the process 2.11 Product Feedback gives the stakeholders the chance to stake specifically what needs to be changed in order to meet their expectations.

This will send the team back to revise the product according to the new shared understanding of the requirements as set forth by the customer and interpreted by the team.

The next post will go to the next knowledge area, that of Adaptive Planning, to see what takes place in an agile project during the control process group that is related to that area.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now writing about those processes that occur during the Control process group.    The first process is one that deals with the first knowledge area, that of Engaging External Stakeholders.

In process 6.7 Review Meetings are done at the end of each iteration.   Product demonstrations are, like review meetings, product-centric presentations of completed work products.   However, they are done not at the end of each iteration, but prior to a Release.    The purpose is get feedback from the stakeholders that validates the value that the team has created for the end user.

Like the review meetings, features are demonstrated that were actually completed, and any features that were not completed are documented, along with the reason why they were not completed.

The purpose of the meeting is to align the team and the stakeholders so that a sense of trust is fostered which allows the team to remain focused on the goal of the Release.

The next process is actually part of the same Product Demosntration, but done for a different purpose, for value-driven delivery.  That is process 2.11 Product Feedback.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

The previous posts have covered the “Initiate”, “Plan”, and “Iterate” process group of an agile project.   Tomorrow I start on the “Control” process group, but I first want to define what I mean by that term of “process group”.   Why do I use this instead of the word “phase”?    Phase implies a sequence that goes more or less from one set of processes to another.   In reality, after the initiate and plan process groups, an agile project actually shuttles back and forth between the “iterate” and “control” process groups.   In an iterate process group, you’re working the plan.   At some point you want to take a step back, monitor the work you’ve been doing, and see if you are conforming to the plan.   If not, you have two choices

1. Re-adjust the work to the plan, i.e., get back on track
2. Realize that it is the plan, not the work, that needs to be changed.   Here you are changing the track itself.

In any case, this series of “course adjustments” goes on continuously in an agile project.

The first process in this control process group is one which covers the knowledge area of “External Stakeholder Engagement”; it is the process 1.9 Product Demonstration, and is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

In process 7.4, I discussed the process of Metric Definition, which is set up during the Planning phase of the project.   In the Iterate phase, it is necessary to track the metrics that were set up in process 7.4.   This is the process 7.5 Metric Tracking.

The team must help set up the metrics, and then once they are set up, to have the discipline to track performance against those metrics.   Many of these metrics will be the data points to be discussed during the Review and Retrospective meetings, and the better the data, the better the discussion at those meetings.

This discipline forms the daily practice of continuous improvement on a project, which should always be a goal in an agile project.

The next post starts the Controlling phase of a project.

Filed under: Uncategorized | Leave a comment »

John Stenbeck in his book “PMI-ACP Exam Prep PLUS Desk Reference” creates an agile project management process grid with 87 processes divided into 5 process groups and 7 knowledge areas.

The block of processes I am covering now are those in the Communication knowledge area that are done during the Iteration phase of an agile project.    This process is 6.9 Osmotic Communication.

What is osmotic communication?    Generally there are three main forms of communication:

• Interactive or face-to-face (one-on-one)–when information is exchanged between people
• Push (one-to-many)–when information is sent from a centralized location to those who need that information
• Pull (many-to-one)–when information is put in a centralized location, and those who need that information pull the information from that location when it is needed

Osmotic communication is a form of pull communication when members pick up information from a centralized location, but rather than having the source be a static set of files, the information they are overhearing is in itself interactive communication, i.e., conversations occurring in a common area.

The top form of interactive or face-to-face information is recognized as THE most effective channel available.   If these effective communications are occurring in a common area, then a second level  of benefit can be gained by having people overhear those interactive communications and thus being made aware of current insights on the project.

Of course, osmotic communication presupposes colocation in order for it to work.   What are some of the constraints on the effectiveness of osmotic communications?

Have you ever been to a networking function with more than 50 people?    In order to hear your own conversation without being drowned out by those of others, you need to breakaway into a quieter corner if you are to have a meaningful conversation amidst the din of the background noise of everybody else trying to have a conversation.   This points to the fact that osmotic communication works best with small teams.

However, if teams are larger, than just like in the example of the networking session, it is good to have breakout spaces or even a private office available for conversations that need to be held in private without the possibility of being overheard.

If teams are distributed rather than collocated, then you must work on fostering trust between team members and creating digital spaces where conversations can take place in order to achieve the best communications possible on a team, no matter where the team members may be.

The next post gets into the knowledge area of continuous improvement, and how this is implemented during an iteration.

Filed under: Uncategorized | Leave a comment »

In the past series of blogs posts, I have gone over two other types of meetings that are included in process 6.7 which are done during each and every iteration:

• the Daily Stand-Up Meeting (done every day of the iteration cycle)
• the Review Meeting (done at the end of every iteration cycle)

As was mentioned in the previous post on the review meeting, it is a product-centric meeting, which focuses its energy outwards towards the customer and other stakeholders.   The Product Owner or the Customer/Proxy is the facilitator of that type of meeting.

The Retrospective Meeting, the focus of this post, on the other hand focuses its energy inwards towards the team, and is process-centric.    The Scrum Master is the facilitator of this type of meeting.

The purpose of the meeting is to create a shared understanding by the team of how they worked together and how that affected what they delivered to the customer.   The focus is NOT on personalities, but processes.   In order to keep the conversation as objective as possible, it is important to go into the retrospective meeting with the best available iteration metrics such as:

• Features or stories completed vs. features or stories committed to
• Team velocity during iteration as compared to the average
• Any changes in team membership
• Participation rate in daily stand-up meeting (should aim for 100%)
• Data from burn charts

These data should be used to create a visual radiator of the iteration to make it easier fore the team to see any patterns.    The team should be asked to interpret the data shown in the visual radiator.

I like how John Stenbeck puts it in his book “PMI-ACP Exam Prep PLUS Desk Reference”:   he says it all boils down to answering the question:  was the team iteration exciting as hell or was everybody on the team wishing they could be extracted from hell?

The meeting should invite experiments with changes to processes during the next iteration which will improve the team’s interaction towards achieving the project goals.

Remember, even if it is a small, incremental change, it can significantly change the team’s performance if it compounded over several iterations!

This concludes the discussion of the meetings to be held during every iteration.   The last process related to team performance that is done during every iteration cycle is “Osmotic Communciation,” the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the last post, I discussed one of three types of meetings that need to be during each Iteration, namely, the Daily Stand-Up Meeting, which as the name implies is done during each day of the iteration cycle

At the end of each iteration cycle, however, there are two meetings that need to be held:

1. the review meeting, which is product-centric, and
2. the retrospective meeting, which is process-centric.

This post will cover the Review Meeting.   This actually requires little preparation, because only those products which have been completed, tested, and internally verified to meet the acceptance criteria are demonstrated at the review meeting.

Besides showing the work that was completed during the iteration, the team also discloses work that was expected to be completed by the end of the iteration, but was not.

The stakeholders have a chance to ask questions and interact with the work products.   Optionally, the team may present a review of iteration performance metrics, basically to demonstrate that the client or customer is getting its money’s worth on the project.   But the proof, as always, is in the product, and that remains the focus of the review meeting.

The results of the meeting are as follows.

1. Feedback on the product
2. Potential updates to the product backlog
3. Potential updates to the release plan.

The next post covers the process-centric meeting, the retrospective meeting.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management.   These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

I am now covering a block of two processes that relate to team communications which are done on a repeating basis during each iteration of the project.   The first process 6.7 covers several types of meetings:   Daily Stand-Up, Iteration Review, and Team Retrospective Meetings.   This post covers the first of these, the Daily Stand-Up Meeting.

The purpose of the daily stand-up meeting is primarily to synchronize the team members’ activities.   Secondarily, it provides information for documenting work progress against the iteration plan.

How is the meeting organized?

• Time duration:  15 minutes
• Facilitator:   Agile Project Manager, or Scrum Master
• Attendance:    Mandatory for every team member

Here are the three questions used to prompt and guide the meeting:

1. What have I done since the last daily meeting?
2. What  will I do between now and the next daily meeting?
3. What obstacles are impeding my work performance?

There are various methods of determining who goes first in the meeting, among which are the 911 method (those go first who have an emergency or impediment).

Here are the metrics for measuring how well a team meeting is going:

• Is every one on time?
• Does team focus on the work rather than personalities?
• Does the meeting begin and end on time?

Note that if an obstacle or impediment is identified, this is NOT the time for problem solving on ways to remove it.   That should be done  with a subset of the team breaking out to discuss the matter AFTER the daily meeting.

Many people think that agile is not as disciplined as waterfall, because it doesn’t require as much external documentation.    What they don’t understand is that it IS very disciplined, but the discipline comes not from external documentation, but INTERNAL discipline, the kind that is enforced by the discipline of the daily meeting.

The next post covers the Iteration Review Meeting.

Filed under: Uncategorized | Leave a comment »