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.

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 »

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 five processes that relate to risk management which are done on a repeating basis during each iteration of the project.   The first four of these processes are 5.6 Problem Solving, 5.7 Continuous Integration, 5.8 Risk-Based Spikes, and 5.9 Risk Burn Down Charts.   This post will cover the last of these process, 5.10 Verification and Validation.

For agile projects being executed in the government sector or healthcare industry, there may be a requirement for independent verification and validation to be done at the end of the project.   Some people get confused about verification and validation.   Here’s a way to get them clear in your mind.    Let’s say you are visiting a client and you have to park your car in an massive, underground garage.     What’s the first thing you would do when you leave the car?   If you are like me, and are somewhat “directionally challenged”, you may write down or VERIFY the parking space before leaving the area.

Now let’s say the appointment with the client is done and you want to go to your car, but you want to avail yourself of the opportunity to get the parking fee waived.   You would go to the front desk of your client and VALIDATE your parking.    In a similar way, your company verifies the product internally against the requirements and the customer validates the product externally against the requirements.

If this process is externally driven by government or industry regulations, then the steam must integrate these requirements into the usual agile procedures and activities.   In other words, as in everything else in agile, the team must … adapt.

This concludes this block of processes, and the next post will cover the next knowledge area of Team Communications during the Iteration Process Group.

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 five processes that relate to risk management which are done on a repeating basis during each iteration of the project.   The first three of these processes are 5.6 Problem Solving, 5.7 Continuous Integration, and 5.8 Risk-Based Spikes, which were covered in previous posts.   The process discussed in this post is 5.9 Risk Burn Down Charts.

A risk burn-down chart shows the risks that are still in play in a given project.   Most risks are tied to specific processes which, if passed through without incident, are no longer a problem for the duration of the project.

Here’s how it is constructed:

1. Construct a risk list, sometimes referred to as a risk register.
2. Assign a probability value to each risk–this value can be on a scale from 1 to 10, or something more general, like Low/Medium/High.
3. Assign an impact value to each risk–this value is the estimated number of days that would be lost if the risk materializes into an actual problem (also known as an issue).
4. Take the two values obtained in steps 2 and 3, and multiply them.   The result is a single value, known as the risk exposure.   Add up the total risk exposure of all risks listed in the risk register.
5. Plot the total risk exposure on the y-axis and the number of days in the project on the x-axis.   The total risk exposure should gradually decrease so that the graph looks like a line going from upper left to lower right as the project goes forward.
6. After each iteration, plot the ACTUAL risk remaining against the planned remaining risk created in step 5.   Then you can see whether the risk is being reduced as planned or whether there are lingering, unresolved risks that need attending to.

The next and last process related to risk management done during each iteration is 5.9 Verification and Validation.

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 five processes that relate to risk management which are done on a repeating basis during each iteration of the project.   The first of these processes is 5.6 Problem Solving, which was covered in a previous post.    The second of these processes is 5.7, which is Continuous Integration.    This post relating to risk management in agile projects is process 3.8 Risk-Based Spikes.

In earlier discussions on estimation, such as in the Planning Poker game, there were certain stories that you may not be able to get a consensus around regarding what their story “size” is, i.e., their estimated duration.    This is usually because the team doesn’t have information to determine a rational estimate.

A risk-based spike is an experiment designed to assess the probability of an event occurring.   The purpose of the spike is replace speculation with concrete data about triggering events and the need for mitigation planning to develop alternative project plans as a risk response.  This gives the team real data about the probability of making progress within a specified duration.

Ultimately, risk-based spikes are an agile learning technique that helps clarify the team’s understanding of the risk factors involved in the overall design.

The next post is on process 3.9 Risk Burn-Down Charts.

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 five processes that relate to risk management which are done on a repeating basis during each iteration of the project.   The first of these processes is 5.6 Problem Solving, which was covered in a previous post.    The second of these processes is 5.7, which is Continuous Integration.

The problem with the introduction of Continuous Integration into a team’s work is that some members may think they should would be adding more value if they started working on coding the next feature rather than spending time making sure that the code that they have just completed is integrated into the already existing code.

However, continuous integration reduces the risk that time will be wasted later on in rework, so it actually does add value.   One of the ways of reducing the probability of hidden defects is to make them easier to find, which may require more innovative and elegant solutions.

Continuous integration works better with smaller teams on independent subsets of the control system.

The next process is 5.8–Risk-Based Spikes, which will be covered in the next post.

Filed under: Uncategorized | Leave a comment »