Agile Project Management Process Grid–Process 6.2 Participatory Decision Making


In his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” John Stenbeck has created an “Agile PM Process Grid” which contains 87 processes used in agile project management divided up into 5 process areas and 7 knowledge areas.

I’m now covering all the processes in the first process group called Initiate, and have covered all the processes in that group under the first 5 knowledge areas.   Now I’m moving on to the two processes in the sixth knowledge area of Communications, 6.1 Colocated/Distributed Teams and 6.2 Participatory Decision Making.   This post will cover the second of these processes.

Agile Project Management is successful because it provides creative and non-linear solutions to significant, complex problems.   It does this by empowering the knowledge worker to make decisions that they are in the best position to make.   Vigorous discussion and active participation by every team member is used to interrogate the problem until the best solution emerges.

Leadership in an agile project consists of facilitating the discussion between team members.   If a single solution emerges, that’s great.    If two solutions emerge and the group is split between which of these two solutions to follow, then the leader may have to come in and break the impasse.

The iteration is set up to be conductive to this decision-making process.   For example, there is a two-step iteration planning meeting where the agile team and the Product Owner discuss and then refine their mutual understanding of what will be delivered at the end of the iteration.   This process is a participatory decision-making process where:

  • The Product Owner describes user stories that should be included in the iteration,
  • The Team asks questions in order to clarify the exact meaning of each user story,
  • The Team develops specific metrics and/or acceptance criteria for each user story.

Although I have made it seem like this is a step-by-step process, like a chess game, the more apt metaphor would be a tennis match.    However, in this tennis game, the goal is not to beat the opponent, but to keep the ball in the air as long as it takes for each step to be complete to the satisfaction of all parties present.    The amount of time the ball will stay in the air is roughly proportionate to the size of the user story, meaning, the relative priority it has in the product backlog or global list of features requested by the customer.

This exact process listed above is described in more detail in the Plan process group; the reason why this tool is listed here in the Initiate process group is that everyone on the team needs to be aware of the ground rules for such interactions, so that no team member’s voice is left unheard.

That may mean that you ask the introverted or the younger team members their opinion first, because they are the voices most likely to be drowned out if they have to compete with extroverted or more experienced team members.   But however the participation is encouraged, you also need to set ground rules on how to give feedback to other team members regarding their suggestions.    Get the tone right, and you have an open mode of communication; get it wrong, and you have a battle of egos, and all of the energy that could have been spent tackling the problem is spent parrying negative comments.

The process contained in the Initiate process group in the last knowledge area, that of Continuous Improvement, is process 7.1 Identify Agile Ceremonies, and it will be discussed in the next post.

Agile Project Management Process Grid–Process 6.1 Colocated/Distributed Teams


In his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” John Stenbeck has created an “Agile PM Process Grid” which contains 87 processes used in agile project management divided up into 5 process areas and 7 knowledge areas.

I’m now covering all the processes in the first process group called Initiate, and have covered all the processes in that group under the first 5 knowledge areas.   Now I’m moving on to the two processes in the sixth knowledge area of Communications, 6.1 Colocated/Distributed Teams and 6.2 Participatory Decision Making.   This post will cover the first of these processes.

Colocated Teams

It makes sense, given the fact that agile project management depends on team collaboration, that a team that is in the same location, or a colocated team, is going to have the natural advantage as opposed to a team which is split up in different locations, or a distributed team.   A colocated team will only require the normal level of support when it comes to communication.

Distributed Teams

However, given the global nature of many businesses, you may have to have a distributed team, in which case you will require a higher level of support when it comes to communication, including the following:

  1. Synchronizing communication–shift core hours to find an overlap in which conference calls can occur, but enable groupware tools such as e-mails and wikis to provide communication BETWEEN core hour shifts
  2. Enabling collaboration–given the fact that different time zones often translates into different native languages being used, it is best to encourage written communication in parallel to any verbal communication to avoid misunderstandings
  3. Providing enough communication bandwidth-the key here is to provide enough bandwidth to achieve knowledge sharing.   These can include rotating team members across projects, features, and modules, or using groupware tools such as e-mails and wikis.

The purpose is to set up the communication infrastructure beforehand, even before planning takes place because planning itself is a collaborative process–that is why this process belongs here in the Initiate process group.

The next process 6.2 Participatory Decision Models will be covered in the next post.

Agile Project Management Process Grid–Process 5.3 Define Quality Standards


The Agile Project Management Processes Grid has been created by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference.”   He divides the 87 processes used in agile project management into five process groups and seven knowledge areas.

This post covers the third of three processes in the block of processes that are used in the Initiate process group and the Risk Management knowledge area:  Quality Standards.

The first two areas of risk analysis dealt with

–organizational practices, those risks which are inherent in the organization, on the one hand, plus those risk that are inherent to the specific project at hand, and

–regulatory discovery, meaning the analysis of governmental regulations that have a potential impact on the project

This third area is covered by this process, and this is to Define Quality Standards.

Definition of Quality

Some terms used in project management have a different definition that those terms do in everyday conversation.   Quality is a term loosely applied to a set of characteristics that show a degree of excellence, but in the project management sense of the term, quality is the set of characteristics that correspond to the customer’s needs and expectations, in other words, the customer’s requirements.

For example, if I am shopping for a new car, in the everyday definition of the term quality, an Audi might be considered a higher quality car than a Volkswagen because it is “classier” looking or it has more expensive materials in the passenger compartment.   But if I do research and the particular model of Audi I am looking at has a higher defect rate than the Volkswagen as measured by J.D. Powers customer surveys, then the Volkswagen will have the higher quality because there is less chance of my needing to take it in for repairs.

In any case, because agile is so focused on interaction with the customer, quality seems like a natural constraint to focus on in a project.

Need for Quality Standards

However, one of the characteristics of an agile versus a traditional project when it comes to constraints is the notion of the fixed constraint.   Although scope, time and cost are thought of traditionally as the “iron triangle” of constraints, it may be a more instructive image to think of them as a triangle-shaped water balloon.    If you fix one of the ends in your hand, the liquid is free to flow between the other two ends.   In a traditional project, the scope is usually the “fixed” constraint that is determined as completely as possible in the beginning of the project.

In an agile project, however, the time or cost may be the fixed constraint, which means the scope may need to be adjusted.    Here’s how this affects quality:   if you are under pressure to get a project in on time or within a certain budget, then there is pressure to perhaps reduce the scope, or amount of features that go into a product.   But if you reduce the features too much, so that the resulting product does NOT meet the customer’s needs, then the project will be a failure even if it is technically a success with regards to the time or cost constraint.

This is why quality standards need to be defined.

Quality-In Design

Not only do quality standards need to be defined, but they need to be defined EARLY in the project, before detailed planning starts to occur.  That’s why this process is in the Initiate process group, by the way.

The reason for this is the simple empirical law that the cost to fix a defect rises exponentially the later it is discovered.  Rather than spending the enormous amount of time and money needed to inspect and repair defects either before they leave the factory, or, even worse, after the product is in the hands of the customer, it is best make an early investment in designing and developing a product so that the defects don’t occur in the first place.

Here following best practice standards and guidelines should be the focus of the agile team so that the iteration review meetings show explicit progress towards key stakeholder goals, which should be defined in a clear way.    This helps prevent cutting corners when faced with limits on time and budget that might have an adverse impact on the quality of the product.    That is how to reduce risk when it comes to the quality constraint on an agile project.

The next series of posts are on the sixth knowledge area of Communication and the two processes from that area that are done in the Initiate process group, Process 6.1 Colocated/Distributed and Process 6.2 Participatory Decision Making.

 

 

Agile Project Management Process Grid–Process 5.2 Regulatory Discovery


The Agile Project Management Processes Grid has been created by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference.”   He divides the 87 processes used in agile project management into five process groups and seven knowledge areas.

This post covers the second of three processes in the block of processes that are used in the Initiate process group and the Risk Management knowledge area:  Regulatory Discovery.

In traditional project management, there are two “generic” inputs that are used with a lot of the processes, namely “Operational Process Assets” (or OPAs) and “Environmental Enterprise Factors” (or EEFs).  The OPAs are assets such as documents that are used in the organization as repositories of procedures, guidelines, and templates to be used in project management.   With regard to risk analysis, these were covered in the previous agile PM process 5.1 Organizational Practices.

The EEFs, on the other hand, make up the environment outside the organization in which the project takes place.   One large category of EEFs are government regulations.   Risk analysis involving these government regulations is what this current process 5.2 Regulatory Discovery is all about.

Regulatory Discovery Process 

Here’s how the process works.

  1. Identifying all stakeholders (process 1.1 Stakeholders Identification).
  2. Identifying those stakeholders, external and internal, who may need to audit the project.
  3. Identify the documentation that will be required by those stakeholders, sometimes referred to as documentation user stories.
  4. Make sure the documentation user stories track the requirements such as testing plans, results, etc.
  5. Create a protocol for tracking the documentation user stories during the lifecycle of the project.

Since the relative penalty for not being in compliance with government regulations is high, it is important to engage in regulatory discovery and compliance activities in order to mitigate risks such as product liability.

However, the amount of resources that you place in compliance should be the minimum needed to ensure compliance, and compliance activities should be directed away from critical team members so that they can concentrate not on reducing a negative (mitigating risk) but on increasing a positive, in terms of adding real value on the project on behalf of the customer.

The kind of risk mitigation that SHOULD involve the critical team members is related to quality standards, which is the subject of the next post.

Agile Project Management Processes–Process 5.1 Organizational Practices


The Agile Project Management Processes Grid has been created by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference.”   He divides the 87 processes used in agile project management into five process groups and seven knowledge areas.

This post covers the first of three processes in the block of processes that are used in the Initiate process group and the Risk Management knowledge area:  Organizational Practices.

A Failure of Imagination

The NASA program that eventually took three Americans to the moon in 1969 had a very disastrous beginning.   Apollo 1 was designed to take the Saturn rocket that would eventually take men to the moon and to test it out in Earth orbit.   The three astronauts, Gus Grissom, Edward White, and Roger Chaffee, were doing a routine test on the launch pad on January 27th, 1967, when a fire broke out in the cockpit which killed all three of them.

There was an investigation which showed that the origin of the fire was a spark that came from a faulty electrical connection, which was exacerbated by the highly oxygenated environment in the cockpit of the Command Module.    However, the chairman of the Congressional Committee that investigated the incident asked a fellow astronaut Frank Borman, “what do you think caused the fire?   I’m not talking about wires or oxygen here==what do you think was the underlying cause of the fire?

Frank Borman answered that it was a failure of imagination.   In doing risk analysis on the Apollo program, NASA put their focus almost entirely on the dangers to the astronauts due to the hazardous vacuum conditions that exist in outer space.   NASA didn’t, however, consider the risks to the astronauts that could be caused on a routine training exercise that took place on the ground.   That was the reason for the fire.

Brainstorming

Risk analysis can be divided  into two categories:

  1. Generic risks–these are risks that are common to all projects that are particular to the organization itself
  2. Unique risks–these are risks that are particular to the project itself

The first approach to risk analysis in both categories is brainstorming, where the team member and the customer/proxy get together and create a list of possible catastrophic events that could impact the project negatively.

There are way of doing this which add an element of fun, which counteracts the negative nature of the content.   Try giving awards for those that come up with various nightmare scenarios such as

  • “Academy Award for Best Screen Play” goes to the person who describes the negative scenario in the most dramatic fashion.
  • “Pulirzer Prize in Investigative Reporting” that describes the negative scenario in the most matter-of-fact way as if it was the subject of a 60 Minutes investigative report.

These are just examples, but you get the idea.   You want to encourage people’s imagination and creativity.

Risk Analysis

The next step after coming up with the negative scenarios in the brainstorming session is to analyze them and, in each case, come up with the root cause of the scenario.  You can group the root causes of the risks in something called a Risk Breakdown Structure that categorizes the various sources of the risks.

Prioritizing Risks

The next step in risk analysis after you’ve analyzed the root causes is to prioritize risks using the following process.

  1. Estimate on a rough numerical scale (1 to 10) the probability of the risk occurring
  2. Estimate on a rough numerical scale (1 to 10) the impact of the risk occurring
  3. Create a risk matrix that shows the probability of a risk occurring and its impact if it does occur, and graph the estimates done in the first two steps.
  4. Decide which sectors of the matrix correspond to a HIGH, MEDIUM, and LOW level of risk.   Usually the lower-left corner is LOW, the upper-right corner is HIGH, and MEDIUM is somewhere in an area in between these two other areas.

This basic risk profile will be expanded upon and detailed in the planning process group.

Some of the risks are going to come not from the organization, but from outside the organization; in particular, from government regulations.  The next process 5.2 Regulatory Discovery deals with risks that come from this source.

 

How to RISE to the Occasion of Being a Leader


Yesterday at the Winter 2015 installment of the Toastmasters Leadership Institute (TLI) here in Chicagoland District 30 of Toastmasters International, Mark Brown, the 1995 World Champion of Public Speaking, was the keynote speaker.

In yesterday’s post, “ATE Ways Leaders Get Things Done”, Mark Brown outlined 8 traits that leaders should possess who want to empower their team, as opposed to aggrandizing power to themselves and thereby undermining their team, as poor leaders do.    This was based on Mark Brown’s second presentation at the Winter TLI that was done mid-morning.

After lunch, Mark Brown gave his final keynote presentation of the day.   Ethel Goatee, our District Director, coined a phrase RISE, which stands for Respect-Integrity-Service-Excellence, at the beginning of our current Toastmaster year which runs from July 2015 until next June.   These were the 4 characteristics she felt that leaders should possess, whether in Toastmasters, at the workplace, or in another non-profit or community organization.    Mark Brown took this acronym, and spoke for about 45 minutes about what each of these 4 characteristics meant to him.   That was the basis of his presentation, which I summarize below.

RESPECT

You need to respect your team members, of course, but you can’t respect others until you respect yourself.    Restoring work-life balance is simply a matter of restoring respect for the integrity of your body, mind, and spirit.    Stephen Covey, in his work “The 7 Habits of Highly Effective People” talks about P-PC balance, meaning “production” and “production capacity.”   Production is the capital that you expend to get things done.   Production capacity is what you do to build up that capital.    Near-sighted managers will ask their team members to always be in the “P” or “production” cycle, but leaders will have the wisdom to encourage their team members to take time out for building up “production capacity”–by resting, or studying and thereby sharpening one’s skills.   A leader HAS to start with him or herself, however, in this endeavor.

INTEGRITY

There are three key questions people will ask about you to determine whether you have integrity.

  • Can I trust you?   Whatever happened to the concept of the “gentleman’s agreement”, where a handshake and a verbal commitment were considered enough?
  • Can I depend on you?    If I give you a task, do I have to spend time and energy following up or can I relax knowing that you will either accomplish it or tell me quickly if you cannot?
  • Can I defend you?   If your integrity is challenged, can I give evidence of your character based on examples of your past conduct?

SERVICE

Service is not, as is sometimes supposed, what you do for others, but it is who you choose to be at each moment of your life.   My mother had a saying, “work is love made visible.”  If you truly love the people that surround you, work or sacrifice is not sacrifice of yourself as much as it is an expression of gratitude towards others.   You do not do it for the promise of a reward.

There’s a saying I have that there are three stages of being a Toastmaster.  The first is when you are afraid to get on stage.   That’s the reason why people join Toastmasters in the first place, to get rid of their stage fright.  And then, the benefits of mastering public speaking start to accrue–people applaud when you do a speech!   How gratifying is that?

Well, that takes you to the second stage–when you are afraid to get off stage.   You are enjoying the limelight, and like the proverbial Jack Horner of the Mother Goose rhyme, you say to yourself “What a good boy [or girl] am I!”

There are some people who are stuck at this stage, blissfully unaware that there is a third stage of being a Toastmaster, when you know the right time to get on stage and the right time to get off stage.   In other words, you know that the message that you are giving is ultimately more important than the messenger.  This is when your passion for service takes over and your speaking is in service of the audience and not in service of your own ego.   That is the stage that all Toastmasters should strive for.

EXCELLENCE

Your worst enemy can be the word “good”, if it is said in the context of meaning “good enough”.   You’ve heard of the phrase “good enough for government work”?    It implies that you are setting the standard too low.   Unfortunately, that’s what many of us do.   Because we want perfection that we feel cannot be achieved, we use that as an excuse to attempting to go farther, to do better–in short, to achieve excellence.

If you do achieve something, then celebrate!   But turn that period of celebration into a comma, not a period.   In other words, don’t rest on your, uh, laurels, but rather ask yourself:   is there more than I can do?   Is there more of my experience that I can share with my team?   Can I make a difference for my team by making a decision–or by letting them make a decision?

It is a privilege of a lifetime to be who you are.   But with that privilege comes a responsibility to help others be all that they can be.   If you exemplify this culture of excellence in your own life, people will be attracted to it because they will want to experience in their own lives.

Thus, the acronym of RISE–Respect, Integrity, Service, and Excellence–can truly be the touchstone of your future potential as a leader!!

 

“ATE” Ways Leaders Get Things Done


At the Winter 2015 version of the Toastmasters Leadership Institute held in District 30 Chicagoland at AT&T University today, I was present at the opening presentation by the keynote speaker Mark Brown, He gave a brief biographical sketch of how he came to the United States as an immigrant from Jamaica with $40 in his pocket and a dream of a better life.

After joining Toastmasters in 1994, he entered a speech contest and got all the way to the finals on his first try.   He engaged the 1990 World Champion of Public Speaking David Brooks to coach him for the next year’s competition, and he ended up becoming the 1995 World Champion of Public Speaking!

In the second presentation he made later on that morning, he talked about the other set of skills that Toastmasters is known for other than speaking skills, namely leadership skills.    He shared eight ways in which leaders get things wrong, and eight ways in which leaders get things right.   In both cases, the eight ways all end in the letters “A-T-E”, and that is the reason for the title of his talk which is the same title as this blog post.

Let’s start with the bad examples before we get to the good ones.

Eight Ways Leaders Get Things Wrong

  1. Manipulate—they use team members for personal gain, such as taking credit for achievements that in reality were only made possible by the members of the team
  2. Dominate—they play the tyrant and get things done by virtue of their authority alone, at the expense of eroding the relationship of trust between the leader and the members of the team
  3. Intimidate—they browbeat and discourage team members, by micromanaging them or undermining their confidence
  4. Vacillate—decisions are made rashly and sometimes reversed for no apparent reason
  5. Frustrate—subordinates are impeded when they bring up ideas for change
  6. Incapacitate—team members are hindered from doing their jobs
  7. Denigrate—they put down or belittle team membdrs
  8. Procrastinate—they put off making decisions until they hit a crisis point

Everyone in the audience was probably making a little checklist of which of their current or previous bosses fit one of these eight toxic leadership styles.    The important thing, however, is not to take the resentment you might feel in these situations if you are on the receiving end and take it out on others.

Rather, you need to break the chain and resolve not to treat team members this way when Everyone in the audience was probably making a little checklist of which of their current or previous bosses fit one of these eight toxic leadership styles.    The important thing, however, is not to take the resentment you might feel in these situations if you are on the receiving end and take it out on others.Rather, you need to break the chain and resolve not to treat team members this way when you are the leader.

Eight Ways Leaders Get Things Right

  1. Communicate
  • Clearly define tasks and responsibilities—state dates and times for deadlines
  • Explain procedures in detail
  1. Educate
  • Share your knowledge by having a clear succession plan
  • Help your team members to succeed by giving them the gift of your experience
  • It doesn’t matter who gets the prize if the team wins
  1. Delegate
  • Show people you are not alone
  • Allow subordinates to grow
  • Make sure team gets credit for successes
  1. Participate
  • Get involved, but not OVERLY involved to the point of micromanagement—be a PART, not a PEST
  • The right balance depends on the team member you are dealing with
  • Stay aware and stay “in the loop”
  1. Relate
  • Build relationships—see the person, not the role or title
  • Be approachable
  • Show understanding of the person and their circumstances
  1. Motivate
  • Tune them into WIIFM (What’s In It For Me)
  • Build confidence in your leadership by showing confidence
  • Remind them of their WHY (i.e., their passion)
  1. Appreciate
  • Be the cheerleader and team builder
  • Mark milestones with ceremony
  • Celebrate team successes and individual accomplishments
  1. Dedicate
  • See your responsibility first, not your privilege
  • Know the risks, but forge ahead anyway
  • Don’t be a manager, be a leader!

This is the bare outline of his presentation, which included examples of most of the points he was making.   It contained so many specifics about being a memorable leader that I wanted to share it with everyone!