Agile PM Process Grid-5.10 Verification and Validation


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.

The Agile PM Process Grid–5.9 Risk Burn-Down Charts


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.

 

Agile PM Process Grid-5.8 Risk-Based Spikes


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.

 

 

Agile PM Process Grid-Process 5.7 Continuous Integration


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.

 

Agile PM Process Grid-5.6 Problem Solving


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.

Risk management in agile project management begins with the science of simplicity, which means maximizing the amount of work not done by:

  • eliminating what doesn’t need to be done
  • focusing on ONLY what is essential

The idea is that by doing the above in each iteration, the customer/proxy will be able to clarify what the key functions of the product are from the standpoint of the customer.   In this way, the cost and risk associated with developing possibly unneeded functions is postponed until the need for those functions is established.

In short, if a feature isn’t essential to the product, it doesn’t get built!

The next post covers process 5.7 Continuous Integration.

The Veterans PMP Program at PMI Chicagoland (Updated)


In 2015, I volunteered for the Veterans PMP program at the Chicagoland chapter of the Project Management Institute (PMI).  Run in conjunction with Black Diamond Charities, it is a program that helps veterans or those who are active duty military personnel who are thinking of pursuing a career in project management.   Last year on Veterans Day I wrote about the program, but because yesterday we started our 4th version of the program, I wanted to update the post with some of the new features that we added.

The Veterans PMP program actually started out at Fort Bragg, North Carolina, and there were members of PMI Chicagoland who were veterans themselves and thought, “hey, we’re one of the largest chapters of PMI in the world; we could reach a lot of veterans if we ran the program in the Chicagoland area!”   And that’s what happened:   Aisleigh McGann, the VP of Community Outreach, was approached by several veterans, some of whom had connections with Black Diamond Charities, and a pilot program was run in the fall of 2014.

Black Diamond Charities (referred hereafter as BDC) goes to where active duty military or veterans are likely to be in the Chicagoland area, such as the Great Lakes Naval Station or the U.S. Army Reserve Training Center, and recruits those who might be interested in the program.   Once they express interest and are enrolled in the next group of candidates for the program, BDC coordinates with the PMI Chicagoland director of the program, Antoine Taylor.

The Veterans PMP program consists of the following three phases:

  1. PMP Instruction (5 weeks)
  2. PMP mentoring (2 weeks)
  3. PMP study group (12 weeks)

This is the fourth round of the program and we got 20 people enrolled in the program.

PMP Instruction

This phase gives 35 hours of general instruction in project management, and is given by a team of about half a dozen instructors, including myself.     Besides the instruction, the participants are split up into four teams of 5 people each and given the assignment of creating an idea for a project, and not only doing all of the project documents (such as the project management plan), but doing a presentation to the group on the final day of class explaining the project and showing those documents to the project sponsors.    It not only gives them the theoretical foundation through the classroom instruction, but also gives them a hands-on example of what doing a real project is like.

Some of the topics are not from the PMBOK, but are related to the subject of how a military person can interact with civilians on the same team with the knowledge that the civilians don’t have a military background and therefore may not have the same values.  “Why don’t they just do what I tell them to do, like we had to do all the time in the military”?

The final day of the workshop is presentation day, when the groups present their projects to actual senior-level executives who come in to observe the presentations and ask the kind of questions they would ask in their companies.   This is a level of realism which we think adds to the depth of the participants’ experience.    We heard the last class refer to this as this week as “Shark Tank” week, but everybody ends up coming out a winner from our program!

PMP Mentoring

We had a mentoring session in the past where we brought in people to talk on various topics that would be of interest to people pursuing a career in project management.   This part that focuses not on technical knowledge, but on practical knowledge on how to pursue a particular job or how to upgrade one’s own current position.   This year we’re turning it up a notch:  we borrowed a page from the general Mentoring Program at PMI Chicagoland and this time we have 10 chapter volunteers so far to act as volunteers to be one-on-one mentors with the people in the program.   We are looking for more volunteers, but the ones we have so far are really committed to getting to know the members of the class, and to see what resources the chapter can bring to bear into helping them get to where they want to go.

PMP Study Group

For those that are serious about going on to take the exam, I ran a PMP Study Group last summer which covered one chapter of the PMBOK Guide every week.    This not only presents the material in detail, as opposed to the high-level introduction that was done in the PMP Instruction phase.    This time around, besides myself, we have two additional volunteers who specialize in instruction of the PMP material, so we’ll definitely be able to get this done.   We will make sure that everyone in that group who wants to pursue a PMP will make it to the finish line.

Last year we ran two programs, but word is spreading about our program in the military communities in the state of Illinois, and if it continues in popularity, I would love to see our chapter put on three programs, or even run two programs simultaneously.

Conclusion

We’re not just doing this Veterans PMP program out of charity towards veterans who are both deserving and underserved; we’re doing it because of the conviction we have that the business community in Chicagoland needs managers who are also leaders.   Fortunately, I am the Director of Executive Outreach for the PMI Chicagoland chapter this year, and it is my mission to help companies to see that the veterans coming out of the military as a tremendous potential asset to them!

Agile PM Process Grid—Process 4.7 Coaching/Mentoring and 4.8 Conflict Resolution


The processes that support or nurture team performance are 4.7 Coaching/Mentoring and 4.8 Conflict Resolution.    The reason why I am combining these into one post is because, in my mind, they are both part of the “soft skills” you need as an agile project manager.

You may know the phrase “lead, follow or get out of the way.”   As a project manager for an agile project, your job is not so much to lead, and it is definitely not to follow, but rather it is to get things out of the TEAM’s way that may prevent them from getting the work done.

What are some of those impediments?   They fall into two groups, internal and external impediments.

Internal impediments include those elements within the team itself that are preventing work from getting done:

  • Lack of commitment to the iteration goals
  • Interpersonal conflict between team members
  • Vague communications during daily planning meetings
  • Lack of coordination or synchronization between team members
  • Ineffective use of influence in getting support from key stakeholders

External impediments include those elements outside of the team but within the company that are preventing work from getting done:

  • Department (operational) work or other project work overwhelming the capacity of a team member
  • Management behavior that is not consistent with agile principles and behaviors.
  • Compensation incentives not aligned to either teamwork or individual work by team members.
  • Managers exerting inappropriate control over team members.
  • Organizational churn causing frequent changes in the team.

The following are five of the best practices for removing these impediments and nurturing team success:

  1. On-going training
  2. Maintaining osmotic (open and transparent) communication within the team
  3. Top management support as a champion of the project within the company
  4. Team member interaccountability regarding measurable progress towards achievement of iteration goals
  5. Standards for supportive team behavior

One way of making sure the team is on track is to use agile metrics, which is the subject of the next post.

Agile PM Process Grid-3.19 Wireframes


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 group of agile processes that support the “adaptive planning” knowledge area that are completed during each iteration of the project.   Process 3.15 was Burn Down Charts, Process 3.16 was Task/Kanban Boards, Process 3.17 was Test-Driven Practices, Process 3.18 was Agile Modeling, and this post is dedicated to the last of this block of processes, Process 3.19 Wireframes.

What is a wireframe in the context of an agile project?   It is a visual guide starting with a framework and layering on facets of the desired solution.   Think of a blueprint for the construction of a building.   The “wireframe” might be considered the physical structure of the building, which obviously has to be built first.    Then you might have a layer for the electrical system, the hydraulic system, the transportation system (elevators and/or stairs), etc., overlaid on top of the wireframe that contains the building’s structure.

Wireframes generally contain the following:

  • Categories of information to be communicated
  • Prioritization of functions
  • Range of functional choices to be managed
  • Guidelines on how information is shared

Let me use an example from a Certified ScrumMaster class I took a few weeks ago.    Our job as a team was to come up with a flyer or poster describing our new product.   We were not to create the product itself, but merely to visualize the product to the extent that we could create a poster with information describing the product for potential customers.

Our team chose to develop a product of designer gloves, that is, gloves that were specifically designed to each specific user by the use of a hand-scanning system that could be accessed at various selected clothing stores.

What information would be come up with in order to entice customers into trying our product?   We divided the poster “real estate” into various sections and those that had priority were on the top of the flyer.    So we put the functional features on the top with a picture of a sample product.    Celebrity endorsements and other emotional appeals were put farther down on the flyer.    We were in effect creating a wireframe of the poster.   We had the categories of information to be communicated which we put in the various spaces of the poster, “feature list”, “product photograph,” “celebrity endorsements”, “contact information,” etc.    Then when we came to producing those elements, we put them in the “wireframe” model.    Every once and a while, seeing the visual placement of the elements made us rethink the way we did the original layout.

So it gave the team the ability to get a visual “reality check” on our approach to an emergent design solution.   That is what wireframes are good at, and I found it to be effective in our “mock” project environment.   I’m sure it will be helpful when I use it on an actual agile project!

The next post starts the next set of processes, 4.7 Coaching/Mentoring, and 4.8 Conflict Resolution, that relate to the Team Performance knowledge area and are used repeatedly during the Iteration phase of an agile project.

Agile PM Process Grid–3.18 Agile Modeling


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 group of agile processes that support the “adaptive planning” knowledge area that are completed during each iteration of the project.   Process 3.15 was Burn Down Charts, Process 3.16 was Task/Kanban Boards, process 3.17 was Test-Driven Practices, and this post covers process 3.18 Agile Modeling.

Here are the basic principles behind Agile Modeling (AM).

  1. Create multiple models in small increments–this is because any given model is bound to include some inaccuracies, and having multiple models will more likely produce code that ends up actually working
  2. Create an abstract representation of the software–then prove or disprove its performance with code that either works or does not work
  3. Use the right artifacts from each model–team improves its understanding of the approach to the solution
  4. Follow a continuous forward match–iterating to the next model after one model is verified
  5. Get active stakeholder participation in AM–project stakeholders know what the result of a successful model will be and can provide crucial feedback needed to improve between each model
  6. Use applied simplicity–focus on the practice of only creating models for the current facet of the problem; this goes hand in hand with principle 1 above of creating multiple models in small increments, avoiding large, detailed models.   Do just enough modeling to understand the scope of the problem and the architecture of possible solutions.
  7. Use open communication–display models on walls or Wiki’s, embrace collective ownership of artifacts, and use group-based model development.

These principles allow a team to do modeling in such a way that possible solutions are suggested, tested, and then improved upon in subsequent development iterations.

The next post covers the last of the processes related to the adaptive planning knowledge area, namely, Process 3.19 Wireframes.

Agile PM Process Grid-3.17 Test-Driven Practices


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 group of agile processes that support the “adaptive planning” knowledge area that are completed during each iteration of the project.   Process 3.15 was Burn Down Charts, Process 3.16 was Task/Kanban Boards, and this post covers process 3.17 Test-Driven Practices.

Let’s use as a point of departure the four columns used in a typical task or story board:

  1. Backlog
  2. Development (WIP)
  3. Test
  4. Completed

The basic idea of Test-Driven Practices is that “emergent designs” required by agile will be created when the tests (the third category above) are specified BEFORE stories are moved from the backlog (first category) to development (second category).   So in reality the flow of work is

  1. Backlog
  2. Specify Tests
  3. Development
  4. Test
  5. Complete

The reason why test-driven practices are used in agile is because they reduce both technical risk (i.e., through reduction in defects) AND market risk (i.e., through rapid delivery of product into the market).

And just in the way that development work is decomposed, work on tests are also decomposed so that you start with the top-level acceptance test and decompose it into unit tests.

One of the processes that promotes such decomposition in both testing and development is process 3.18 Agile Modeling, which is the subject of the next post.