4squareviews

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first block of processes, those in the first process group (the Initiate process group) and the first knowledge area (External Stakeholders Engagement).

Now, I am embarking on a description of the second block of processes, those in the first process group (the Initiate process group) and the second knowledge area (Value-Driven Delivery).

These three processes are as follows:

Process 2.1 Value Analysis
Process 2.2 Business Case
Process 2.3 Contracts

The next post was going to cover the first of these three processes, Value Analysis.   However, this process seems to be missing in John Stenbeck’s textbook.    I assume he is talking about Business Analysis in the agile PM context, but I want to contact him and make sure that is what he is referring to.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the third agile tool mentioned above, the Product Data Sheet or PDS, which also happens to be Process 1.3 in the Agile PM Processes Grid.   This post will cover the fourth agile tool listed above, the flexibility matrix.

The Flexibility Matrix

As discussed in a previous post, in traditional PM, the scope is fixed as much as possible in the beginning of the project, and the other two of the triple constraints of time and cost are estimated in relationship to this more-or-less fixed variable.

In agile PM, it is one of the two triples constraints of time or cost, usually time, which is the fixed variable, and the scope is the one constraint that is flexible.    Okay, in theory that it is understandable, but when push comes to shove, and some of the scope has to be thrown out of the project, how do you make that decision?    That’s where the flexibility matrix comes in.   As mentioned above, it shows how to handle trade-offs and prioritize features by showing the relative importance of constraints such as scope, schedule, cost and quality (although other constraints may be added to the matrix).

NOTE:   When using the flexibility matrix, only one constraint may be considered fixed, all of the others have to be defined as firm or flexible in relationship to this fixed constraint.    In the example below, the flexibility matrix is given where the schedule is fixed, the scope and quality are firm, and the cost is flexible by comparison.

Usually the flexibility matrix is incorporated into another tool called the Product Data Sheet, which was covered in the last post.   This is a one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision.    Here is the above flexibility matrix incorporated into a Product Data Sheet which I made up to represent an actual language-learning app called Duolingo which I use every day to study foreign languages.

Product Data Sheet incorporating Flexibility Matrix

The Product Data Sheet has elements which are geared towards the customer (the elevator statement, customer segment, and customer benefits), towards the team (the milestone table), and to both the customer and the team in facilitating any conversation that comes up about trade-offs (the flexibility matrix).

Process 1.4 Active Listening is a tool used in Agile PM when conducting any conversation with stakeholders, like the one referenced above when considering trade-offs between various features.    It is one of the most powerful tools of the agile practitioner’s toolkit, and I will cover it in the next post.

Filed under: Uncategorized | 2 Comments »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the second agile tool listed above, the Product vision box.   This post will cover the third agile tool listed above, the product data sheet, which just happens to be Process 1.3 of the Agile Project Management Processes Grid.

Product Data Sheet

This is a one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision.    According to author Jim Highsmith in his book Agile Project Management, Creating Innovative Products, the product data sheet provides the project information that the team and all the stakeholders need in an appealing, condensed format which constantly refocuses them on the strategic aspects of the project.

Here are the typical elements of the Product Data Sheet:

• Project Start Date
• Project Finish Date
• Agile Leader (the project leader who guides the process)
• Customer/Proxy (the project leader who guides the product)
• Elevator Statement (see previous blog post on this agile tool)
• Customer Segment(s)
• Customer Benefits
• Flexibility Matrix
• Milestone Table

Using the example I’ve used for the previously presented agile tools in the series, let me take the example of an app that is already in existence called Duolingo, which I use every day to study foreign languages.    The following is an example of a product data sheet which uses my own made-up content to give an example of everyone of the elements listed above.

You can see how the customer will be focusing on the elevator statement, the customer segment(s) and the customer benefits, whereas the team will be focusing on the flexibility matrix and the milestone table.    It is more left-brained and logical in its presentation as opposed to the more right-brained product vision box which is more visually-oriented and geared more strictly for the customer than for the team.

The flexibility matrix is used when making a decision about what features have priority and need to be developed first. I have saved an explanation of this last of the 4 agile tools for product development for the following post.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the Vision Statement, which also happens to be process 1.2 of the Agile PM Processes Grid.   This post will cover the second agile tool listed above, the product vision box.

Product Vision Box

The product vision box is a tangible expression of a solution to that includes graphic images as well as narrative content to express the customer’s product vision.    This is meant to be presented to the customer so technical jargon is to avoided as much as possible.

One way to create the product vision box is to start with the vision statement, sometimes called the elevator statement, as discussed in the last post.    Let’s review the elements of the vision statement, as set forth by Geoffrey Moore in his book Crossing the Chasm.

Vision Statement

For:  [name a customer type]

Who Want:  [state a specific need or desire]

The:  [name your product]

Is a:  [name the product category]

That:  [name a compelling reason to buy or use the product or service]

Unlike:  [name the leading competitive products]

Our Product:  [specify the differentiating features or functions]

Here’s an example I created with an app that I use every day to study foreign languages called Duolingo.

For all those who want to learn a foreign language, the Duolingo app is an free app that can take you from having no knowledge of a foreign language to fluency by using it just 10 minutes a day, unlike other foreign language programs like Rosetta Stone that can cost up to hundreds of dollars and require a much larger time commitment.  Our product teaches the user the basic and intermediate levels of any one of a dozen or more European languages.

Vision Statement –> Product Vision Box

Here’s a sample of a “Product Vision Box” for the Duolingo app that I created using the vision statement.

DUOLINGO!

THE EASY, FUN WAY TO LEARN A FOREIGN LANGUAGE

For any one who wants to learn a foreign language

App can be downloaded to your iPhone or Android Device

Be fluent in months if you practice just 10 minutes a day

App is free to use

Learn any one of a dozen foreign languages, with more being added

GO FROM LANGUAGE ZERO TO LANGUAGE HERO!

As you can see, there is the product title, followed by a slogan which gives the basic function of the product.   Then you can include a graphic element which shows either how the product will work, or in this case, the logo that plans to be connected with the product, the owl named Duo.

Then the elements of the vision statement can be stripped out and given underneath.    I have followed the list with a catchy slogan “Go From Language Zero to Language Hero” which is aimed at the potential end user, who may have tried to learn a foreign language in the past and had little success.    This is obviously just an example, but it shows the approach being used.

Just remember that there are four communication preferences, those that focus on

• Ideas (relates to what people think)
• Process (relates to what steps people will take)
• People (relates to what people feel)
• Action (relates to what goal people aim for)

One of the perpetual communication problems project managers have is that they are usually have a primary strength in the process communication preference, but may not be able to communicate effectively in the people communication preference, which requires you to tell stories so that people can not just see the steps you are going to take to get to the solution (which is what the process communication preference emphasizes), but what the solution will feel like, look like.    The last statement in the product vision box was “Go from Language Zero to Language Hero.”   This is an emotional appeal to a user, not a practical one.    If you just want to learn a foreign language, then you should try this product.   But if you have been frustrated in the past trying to learn a foreign language, then you should REALLY try this product.    See the difference?    If you have graphic designers or someone with a visual bent, then that is the person you should be using to help create your product vision box.

For those who want to use an approach that is more along the lines of those with a preference for process-focused communication, then you should try the next agile tool, the Project Data Sheet.   That is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

Process 1.1 Stakeholders Identification is setting up whom you are going to have the conversation with.   The next two processes cover what you are going to have the conversation about, namely, the product, which you are going to make for the key stakeholders,    Clarifying at the very beginning of the project what features the product will have is vital, so you that you don’t get a situation where you deliver what you thought the customer wanted only to be told by the customer, “that’s not what I wanted.”

Four Agile Tools used in Defining and Clarifying Vision

There are four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

In this post, I will cover the first tool, that of the Vision Statement.   It encapsulates the vision that the team has for fulfilling the needs of the customer.   It is sometimes referred to as an “elevator statement”, because it must be brief enough to be shared during a short elevator ride.

Elements of an Elevator Statement

Geoffrey Moore first described his formula for elevator statements in his book Crossing the Chasm and specified four conditions that the statement must fulfill:

1. Your claim must be stated clearly in a sentence or two at most.
2. Offer a clear winning proposition for your customer.
3. Help your customers know your claim or they won’t be comfortable with it.
4. Show partners and allies how your goals are meaningful to them.

Geoffrey Moore goes on to say in his book that there is a proven formula you can use for your elevator statements that gets the information down in two short sentences, and which is conducive to fulfilling the other conditions listed above. Here’s the formula:

For:  [name a customer type]

Who Want:  [state a specific need or desire]

The:  [name your product]

Is a:  [name the product category]

That:  [name a compelling reason to buy or use the product or service]

Unlike:  [name the leading competitive products]

Our Product:  [specify the differentiating features or functions]

Here’s an example I created with an app that I use every day to study foreign languages called Duolingo.

For all those who want to learn a foreign language, the Duolingo app is an free app that can take you from having no knowledge of a foreign language to fluency by using it just 10 minutes a day, unlike other foreign language programs like Rosetta Stone that can cost up to hundreds of dollars and require a much larger time commitment.  Our product teaches the user the basic and intermediate levels of any one of a dozen or more European languages.

The vision statement can be used in conjunction with other agile tools, such as the product vision box and the project data sheet, as will be seen in the posts covering those tools.

The next post will cover the second agile tool, the Product Vision Box.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Process Grid devised by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”,” the very first process listed under the Initiating process group and the External Stakeholders Engagement knowledge area is Process 1.1 Stakeholders Identification.

1.What is a Stakeholder?

A definition of a stakeholder is “a person or group that can impact a project or can be impacted by the result of a project”. Let’s compare that to the definition of a risk, which is “an event or condition that can impact a project either positively or negatively.”    So, a stakeholder could be thought of as a human risk factor, and can jeopardize a project in the same way that a risk can.

However, in the case of a risk, you cannot reason with a event or condition, such an earthquake or flood.    You can only proactively prepare to lower either the probability of its occurring, or its impact if it does occur.    In the case of a stakeholder, you have the possibility of engaging the stakeholder in order to influence his or her level of engagement on the project..

Stakeholder identification as a process is less formal than in traditional management, but the categories of engagement seem to be the same, namely:

1. Unaware
2. Opposing/Resistant
3. Neutral/Independent
4. Supporting
5. Leading (project champions)

1.Unaware

The first category should be obvious–many stakeholders get involved late in the project because they were simply not aware of its existence until late in the project, and are just now waking up to the fact that the project will effect them in some way.    So stakeholder engagement is the first process in agile to make sure that all people who SHOULD know about the project DO know about it.

2.Opposing/Resistant

The next four categories are all levels of engagement for those stakeholders who are now AWARE of the project.   Opposing stakeholders feel that they, or their group, will be impacted negatively by the project.    You must either explain why this is not the case, or explain how the project plans to mitigate this impact.

3. Neutral/Independent

Those who are not affected by the project can at least be persuaded to stay out of the way, or possibly even support the project, since they have nothing to lose by its success.

4.  Supporting

Those who support the project are those who will stand the benefit from it, even if indirectly, such as with technical, logistical support, or interest groups.

5.  Leading (project champions)

These are usually the customer or client, the end users, management, partners, and vendors.

Project champions are important to have as allies because they can help you persuade stakeholders in the other groups.

Once you have identified stakeholders, you need to find out their power and interest levels, meaning their power to affect the project and their interest level in the project.    In traditional PM, these power and interest levels are used to determine the stakeholder engagement strategy in one of four modes which are listed as follows:

• Low interest/low power:   monitor
• Low interest/high power:  keep informed
• High interest/low power:  keep satisfied
• High interest/high power:  manage closely

In agile, focus instead is on engaging with the stakeholders to the extent that they can contribute to the details of a solution to the problem posed by the customers.    By NOT focusing on stakeholders in this way, traditional projects often suffer by delivering what they thought the customer specified only to have the customer say it wasn’t what they wanted.

What the customer wants on day 1 of the project may not be what the customer wants later on in the project.  This is due to one of three factors.

1.  Sometimes it is because something gets lost between the requirements the customer has in mind and the technical characteristics of the product that are created to fulfill those requirements.

2. Sometimes it is because the competitive landscape changes–for example, when a commercial rival to the customer now has a new product which the customer wants to outdo or has come out in the market with the same product that the customer had in mind.

3. Sometimes it is because the internal political landscape changes–for example, when the customer now wants to take the project in a different direction because of a change in the management’s vision for the company’s future.

For that reason, close, consistent collaboration with the key stakeholders is key and focused on the stakeholder’s needs.   To translate those needs into tangible deliverables the project can create, there are two tools and one technique used, which are the topics of the next three posts.

Filed under: Uncategorized | Leave a comment »

The Agile Project Management Processes Grid^TM is a grid of matrix that contains the 87 Agile Project Management Processes that are delineated in John Stenbeck’s book “PMI-ACP^® and Certified Scrum Alliance Professional Exam Prep and Desk Reference”, a book which simultaneously prepares you for two certification exams, the PMI-ACP^® and the Certified Scrum Alliance Professional Exam.

The Agile Project Management Processes Grid^TM is organized by columns that represent the five agile process groups.   These five agile PM process groups are listed below, with the traditional PM group equivalents listed in parentheses immediately afterwards:

1. Initiate (initiating)
2. Plan (Planning)
3. Iterate (Executing)
4. Control (Monitoring & Controlling)
5. Close (Closing)

The rows of the Agile Project Management Processes Grid^TM, on the other hand, represent the seven agile PM knowledge areas, which are listed below, followed in parentheses by my interpretation of which knowledge area (or areas) they correspond to most closely in the traditional PM processes as set forth by PMI.

1. External Stakeholders Engagement (Stakeholder)
2. Value-Driven Delivery (Scope, Quality)
3. Adaptive Planning (Time, Cost)
4. Team Performance (Human Resources)
5. Risk Management (Risk)
6. Communication (Communication)
7. Continuous Improvement (Quality)

The very first “block” of processes are those in both the first process group, the Initiating Process Group, and the first knowledge area, External Stakeholders Engagement,   This block contains four processes, namely,

Processes in the Initiate Process Group, External Stakeholders Engagement

1. Process 1.1–Stakeholders Identification
2. Process 1.2–Vision Statement
3. Process 1.3–Project Data Sheet
4. Process 1.4–Active Listening

If you look at p. 48 of John Stenbeck’s book, you’ll see these four processes listed in the upper left-hand corner of the grid.   However, you won’t see the process numbers–I added those for the purpose of this blog because it helps me to order them when I try to memorize them and reproduce them on a sheet of paper from memory.    PMI puts explicit numbers on its traditional PM processes starting with 4.1, because the first knowledge area of Integration Management is covered in chapter 4 of the PMBOK Guide^®.    Since PMI is not the one creating the Agile Project Management Processes Grid^TM, but are being added as my own personal memory device, I decided to label the first Agile PM process 1.1, since it is the process that is listed as the first process listed in the first knowledge area (the 1 before the decimal point refers to the ordinal number of the first knowledge area, and the 1 after the decimal point refers to the ordinal number of the process within that knowledge area).

So the 87 processes are distributed like this

1. External Stakeholders Engagement (Processes 1.1-1.10)
2. Value-Driven Delivery (Processes 2.1-2.14)
3. Adaptive Planning (Processes 3.1-3.20)
4. Team Performance (Processes 4.1-4.13)
5. Risk Management (Processes 5.1-5.13)
6. Communication (Processes 6.1-6.10)
7. Continuous Improvement (Processes 7.1-7.7)

Okay, with all of that naming convention out of the way, let me start the next post with Process 1.1–Stakeholders Identification

Filed under: Uncategorized | Leave a comment »

In going through John Stenbeck’s book “Introducing Agile Project Management”, I saw on p. 48 of Chapter 2 “Introducing Agile Project Management” a familiar sight: an “Agile Project Management Processes Grid”, like the processes matrix I was used to for traditional project management from the PMBOK Guide.   This is my second year leading a study group for those aiming to take the PMP exam, and I always stress how important it is to memorize the 47 processes that are divided up into a “processes matrix”, with the 5 process groups in columns and the 10 knowledge areas in rows.   When you know that matrix backwards and forwards to the point that you can recreate within 10 minutes on a blank sheet of paper, then you know it to the point that it can actually help you with situational questions that are asking “what should you do next?”   If you know what process you are in NOW based on what situation is being described in the situation, it’s a simple matter of looking at the matrix and finding out what process happens NEXT.

Similarities and Differences between the Traditional and Agile PM Processes Grids

Another thing that looked familiar was the fact that there were 5 process groups in the Agile Project Management Processes Grid.   They are fairly close to the ones in traditional PM–here is a list of the 5 process groups in Agile with the traditional PM equivalent taken from the PMBOK Guide listed in parentheses immediately afterwards

1. Initiate (Initiating)
2. Plan (Planning)
3. Iterate (Executing)
4. Control (Monitoring & Controlling)
5. Close (Closing)

However, when you get to the rows, there you start to see the difference between the Agile Project Management Processes Grid and the Traditional Project Management Processes Matrix.   There are 10 knowledge areas in PMI’s formulation of PM processes as found in the PMBOK Guide on p. 61.   On p. 48 on John Stenbeck’s book there are 7 knowledge areas, which are listed below, with my interpretation of which knowledge area (or areas) they correspond to most closely in the traditional PM processes as set forth by PMI.

1. External Stakeholders Engagement (Stakeholder)
2. Value-Driven Delivery (Scope, Quality)
3. Adaptive Planning (Time, Cost)
4. Team Performance (Human Resources)
5. Risk Management (Risk)
6. Communication (Communication)
7. Continuous Improvement (Quality)

The two knowledge areas in traditional PM listed in the PMBOK Guide that I could not find an equivalent for in Agile were “Integration Management” and “Procurements Management”.   My guess is much of the “integration” that is going on in traditional PM projects is probably being spread across many knowledge areas in Agile; procurements management is an optional knowledge area even in traditional PM because not all projects require vendors or contractors.

The next HUGE difference is the number of processes in Agile:  87 as opposed to 47.   Now this is a daunting task to memorize this number of processes, so the best way to go about it is to memorize them block by block, and today’s post will introduce the 4 processes in the first block of the Agile Project Management Processes Grid, those that are in the Initiate process group (the first column in the grid) and in the External Stakeholders Engagement knowledge and skill area (the first row in the grid).   In the next subsequent 4 posts, I will go into depth on each of these processes.

Processes in the Initiate Process Group, External Stakeholders Engagement

1. Process 1.1–Stakeholders Identification
2. Process 1.2–Vision Statement
3. Process 1.3–Project Data Sheet
4. Process 1.4–Active Listening

Before I go into a quick introduction to these 4 processes, the first thing I wanted to say right off the bat was I thought it was interesting that the knowledge area dealing with Stakeholders is the LAST knowledge area in traditional PM according to PMI, but it is the FIRST knowledge area in Agile PM.   That tells you a lot about the focus in Agile on the stakeholder, because after all, that is the source of your requirements for the product that is the reason for your project’s existence.

Process 1.1–Stakeholders Identification

This process actually consists of two parts–identifying stakeholders and building stakeholder engagement.

Identifying stakeholders does not just mean listing who they are, but also classifying them in terms of whether they are favorable stakeholders (project champions), neutral, or opposing stakeholders.   There are a series of questions to be answered that can help in this classification.   Once the stakeholders have been identified in the sense of what their relationship to the project will be, the process of engaging the stakeholders can begin.

Building stakeholder engagement is, like everything in Agile, an iterative process.   John Stenbeck says that traditional PM often conceives of the convergence on the solution as a “stair-step process” that is linear, whereas in the real world, the convergence on the solution is an oscillation that goes back and forth with smaller and smaller wavelength until the solution is reached.

Process 1.2–Vision Statement

Although the tool is called “Vision Statement”, the closest tool I could find in John Stenbeck’s book to this description is the “Product Vision Box”.

Taking the place of the project charter in traditional project management, which contains a high-level description of the product that is being proposed to be created by the project, there are a group of tools which are used in Agile to convey to the customer what they can expect from the project.   The first tool is a Product Vision Box which conveys this in a combination of graphic images and narrative content.

Process 1.3–Project Data Sheet

The second tool used to communicate the vision of what the product will be is called the Product Data Sheet (PDS), which is a one-page summary of the key objectives of the project, the capabilities that the product will have, and any additional information needed to understand the purpose of the project.

These tools are also used in the Communication knowledge area, but they are included separately as tools under the “External Stakeholders Engagement” knowledge area in the Initiate process group because these tools are especially useful in the initial dialogue with stakeholders.    It gives them something tangible to react to, with the Product Vision Box being obviously a more visual tool than the project data sheet.

Process 1.4–Active Listening

Have you ever seen an interview on TV by someone who is not quite skilled enough as an interviewer?   They will ask a question, the person will answer, the interviewer will say, “right” in a neutral voice, and then continue on with the next question.  They are focused on their list of questions, and the unenthusiastic response to the answer shows that they are not actively listening to it.   They are passively listening to it, and are interested only in when it ends, so they know that is their cue to tell the next question.

You cannot be a passive listener on an agile project; you must be an active listener.   In the case of the interviewer, if you have a series of questions you’ve written down, and the person responds with an answer that takes the interview in another direction, well then you respond to the person’s answer and make it seem like a conversation, which is what it should be.

Active listening in an agile framework means focusing on the stakeholder you are speaking to in order to craft your message specifically in a way that is going to be more meaningful to them, and then listening and making sure you understand what the stakeholder means.   This may mean paraphrasing what they are saying to you to make that you have really gotten the message they are sending you.

Although this last tool seems perfectly suited in the Communication knowledge area, it is nevertheless in the Stakeholders knowledge area because it is particularly important when speaking to stakeholders (and I would add, to management and team members as well).

The next post will cover the first process, Process 1.1 Stakeholders Identification, in more depth.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, in the second chapter called “Introducing Agile Project Management”, he tries to strip down the essentials of what constitutes agile project management into something he calls the “Agile Process Map”.    In the third chapter, on “Initiating Projects”, he explains that portion of the overall agile process that deals with the initiating process group, the first of five process groups which include

• Initiate
• Plan
• Iterate
• Control
• Close

The Agile Process Map

First of all, let us review the overall agile process map, which at a macro level flows from the first steady state to a transition state and then to a second steady state.

Steady State #1

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

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

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

The Product Backlog

Essentially the initiating process group takes you to point of developing Steady State #1.   You take input from stakeholders and set priorities according to their values.   In order to accomplish this, you need to engage stakeholders in to have them articulate those values.   The output of this stakeholder engagement process is the PRODUCT BACKLOG.   The product backlog represents the vision for the entire product as decided by the customer/proxy (aka the Product Owner in the language of Scrum).   This is a “living document”, which means it is continually being improved as new insights are gained.

The Iteration Backlog:  Step 1–Soft Commitment

From the PRODUCT BACKLOG, the next process is selecting a portion of the product backlog for the ITERATION BACKLOG.   It is the product owner who describes what can and should be included in the iteration.   The product owner takes the user stories and assigns a size to them based on those stories that have high priority.   The product owner also should develop a definition of done for each story that includes acceptance criteria.  Based on a mutual understanding of what the product owner sets forth in the iteration backlog, the team makes a soft commitment to a specific set of features for the iteration backlog.

The Iteration Backlog:  Step 2–Hard Commitment

After the soft commitment completed in step 1, the team discusses how to create the deliverables, decomposes the user stories (the equivalent of “work packages” in traditional project management) into tasks, and performs an detailed estimate of each task in terms of how long it will take.   Once the team has finalized their analysis and agrees that they can succeed, they make a hard commitment to the specific set of features that will be delivered to the Product Owner at the end of the iteration.

This is the portion of the overall agile process map that takes place during the initiating process group.

The next post will list the agile project management processes that come under the 7 knowledge areas in the initiating process group.   Please note the difference between the overall agile process, which shows how the entire project flows, and the 87 individual agile PM processes, which are essentially the detailed tools and techniques you use in the overall agile process.

Filed under: Uncategorized | Leave a comment »

I was invited to the IIBA Chicago chapter monthly dinner meeting to participate in a panel discussion that we hope will open up into a Q&A session from the audience.

The purpose of the discussion is to show how people like me who have entered the profession of business analysis or project management have used chapter resources to help is with our professional development.

Maria Astidillo was also invited. She and I are not business analysts but project managers who just happen to be Directors at the PMI Chicagoland chapter, but we are not going in our official capacity (she is Director of Association Outreach and I am Director of Certification), but as professionals who have used volunteering for the chapter, among other things, as a way of accelerating our career path.

The idea for the discussion panel came from David DeWitt, the current President of IIBA Chicago chapter, and we have been planning this event for some months now.

Before I headed up to the event, I wanted to pen this post as an introduction to the discussion, which I will record in this post upon my return.

Filed under: Uncategorized | Leave a comment »