4squareviews

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

The block of processes I am covering now are those in the Planning process group and the “Value-Driven Delivery” knowledge area.   The first process is the creation of Release and Iteration Plans, but before these plans are created, the agile team needs to construct a central feature list.

Product features may come from a number of sources, such as

• end users
• functional business units
• internal and external stakeholders
• requests for proposals (RFPs)
• development team members
• senior management
• competitors
• government regulations

In creating the list, the project team needs to create some boundaries regarding what is allowed to be on the list, so features that are impossible or are described in an overly vague way are not allowed to appear.

A central feature list may be considered as a “superset” of features to be used for planning the release and first iteration.   It represents what a product could  become over several releases.    It is not written in stone; rather, it is a living document which is dynamic and evolves from iteration to iteration.

If, for example, new features are identified after the first iteration, then the additional critical features identified by the customer/proxy are folded into the evolving release plan.

The process of creating Release and Iteration Plans will be divided into the next two posts to discuss the Release Plans first and then the Iteration Plans.

Filed under: Uncategorized | Leave a comment »

John Stenbeck, in his book ‘PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, has created an agile project management process grid that takes the 87 processes he has defined into 5 process groups and 7 knowledge areas.

I am currently covering those three processes that fall within the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.5 Product Roadmap, the second process is 1.6 Minimal Marketable Features (MMF), and the third process is 1.7 Prioritizing Stories.

All of these processes are linked together in the following way.   In the first process 1.5 Product Roadmap, the stakeholders were engaged in the process of setting up the product roadmap and its relationship to the various releases of the product.   In the second process 1.6 Minimal Marketable Features (MMF), the development of the product is refined even further, down to the level of Minimal Marketable Features (MMF), which might be considered the equivalent of minor deliverables in traditional PM.

At this point, you have the scope of the project worked down to a granular enough level that you can the concept of team velocity to make a rough order of estimate regarding whether you can finish the project within the time constraint allowed.   Team velocity refers to the production capacity of the team.

So if you find through process 1.5 and 1.6 that there are 500 story points involved in the particular release you are working on, and the mean team velocity turns out to be 50 story points per iteration, then you can say within a rough order of magnitude that the release will take 500/50 = 10 iterations to complete.

However, if this is a project where the time constraint is fixed, and you only have, say, 7 iterations worth of time, then you have figure out how to make do with features that add up to 350 story points rather than 500 story points.

This is where this process 1.7 Prioritizing Stories comes in.   What are the

• must have
• should have
• would be nice to have
• could have

features of the product.   Here the customer/proxy must weigh in the discussion by deciding what it is the product will do, how it will look, and how it will perform.   Based on these criteria, the backlog of features can be prioritized.   It is essential to get the stakeholders’ cooperation in this process, which again is why this is under the “External Stakeholders Engagement” knowledge area.

The prioritization process is sometimes referred to as “grooming” the backlog, and this is because, like the periodic grooming of a pet whose hair is constantly growing, the process started here in the initiating process group continues during the course of the project, where changes in the priority of stories may end up changing between iterations.

The process of prioritizing stories is a significant investment in time on a project, but it delivers valuable returns in offering a path to success.

This concludes our discussion of the planning processes related to External Stakeholder Engagement.   The next block of 4 planning processes are those related to the “Value-Driven Delivery” knowledge area.

Filed under: Uncategorized | Leave a comment »

John Stenbeck created an Agile Project Management Process Grid in his book “PMI-ACP Exam Prep”, which divided the 87 processes he named into 5 process groups and 7 knowledge areas.

I am currently covering those processes in the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.5 Product Roadmap, the second process, 1.6 Minimal Marketable Features (MMF), is the subject of this post.

In the last process, the stakeholders were engaged in the process of setting up the product roadmap and its relationship to the various releases of the product.   In this process, the development of the product is refined even further, down to the level of Minimal Marketable Features (MMF), which might be considered the equivalent of work packages in traditional PM.

However, the difference here is that MMF comprise the smallest set of functionality that provides satisfactory customer value.   Just to take an example, the version of the software for a cellphone might be called 1.2.4, where 1 is the large-scale version of the product as designated in the product roadmap, 2 is the second release of that product version, and 4 is the 4th MMF that is being developed within that second release.   So it all fits together like Russian matrioshka dolls.

Defining and then sizing the MMF is important, because this will enable the team to use a calculation to determine the probability of meeting any given release date.   This is a “team velocity” calculation, and is done by taking the number of story points for any given feature, and then taking the mean value for the team’s productivity during a given iteration.   So 500 story points divided by 50 story points (on average) per iteration means that the project will most likely take 500/50 = 10 weeks.

If the resulting schedule estimate ends up being too long for the customer, then the process of reassessing the MMF needs to take place, so features can be prioritized and then lower-priority features can be modified or eliminated.

That process 1.7 Prioritization is the subject of the next post.

Filed under: Uncategorized | Leave a comment »

John Stenbeck created an Agile Project Management Process Grid in his book “PMI-ACP Exam Prep”, which divided the 87 processes he named into 5 process groups and 7 knowledge areas.

I am currently covering those processes in the Planning process group and the External Stakeholder Engagement knowledge area.   The first process in this block of processes is 1.6 Product Roadmap.

Product Roadmap

Why is the product roadmap related to “External Stakeholder Engagement”?   Because stakeholders who are taking their vision and enlisting your company to help make it a reality need to be on board with the process of designing a product roadmap.

What is a product roadmap?   In the world of traditional Project Management, it would be what features the product would entail, sometimes called the product backlog.   For example, the application Duolingo is an app that is used to teach foreign languages for free.    The creation of the app itself would be an example of a product roadmap.   Each language on Duolingo consists of the same features.  The emergence of a course on a new language on the Duolingo app would be an example of a release.   For example, Duolingo has just released for English speakers the 15th language, namely, Polish.    Other languages–Spanish, French, German, Italian Portuguese, Dutch, Danish, Irish, Swedish, Turkish, Norwegian, Ukrainian, Esperanto, and Russian–are examples of earlier releases on that application.   And the release of a new language is itself composed of a series of phases which in an agile project would be handled in iterations.

So the progression from large to small is product roadmap, then release, then an iteration.   Why is this mapping of the releases onto the product roadmap, in other words, the release plan, such a critical process?    Because is how you can use estimating techniques to show a predictable schedule for the delivery of an individual feature or of an entire release from the product roadmap.

In an agile project where it must be completed by a certain date, the release date is defined in advance, but the specific features of the release are negotiable.   Given the team velocity, that is, how many user stories can be processes in any given iteration, you can calculate how many iterations it will take to complete entire set of user stories.

This gives the stakeholder a degree of confidence that the project will be completed on time.   And that is why the stakeholder must be engaged starting at the top level of plans, namely, the product roadmap.

The next process is 1.7 Identifying Minimal Marketable Features (MMF), which is covered in the next post.

Filed under: Uncategorized | Leave a comment »

At the end of the second chapter of John Stenbeck’s book “PMI-ACP  and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “Agile Project Management Process Grid”, divided into five process groups and seven knowledge areas.

Chapter 3 covers the Initiating Process Group, and that is the group of processes I have been covering for the past two months.   Now, we are going into the heart of agile project planning, and the book requires three whole chapters 4 through 6 to cover all of this material.

So let’s start with an overview of the process group in general.

First, despite the term “agile,” planning is just as complex and time-consuming as in traditional project management.   And, like in the case of traditional project management, successful agile planning at the beginning of the project is the key to creating customer satisfaction at the end of the project.

Characteristics of Agile Planning

Here are some of the basics of agile planning:

1. Product feature prioritization–only product features with the highest priority for the customer/proxy have to be planned in detail before initiating the project
2. Short iterations–these deliver valuable features sooner so that the customer/proxy can interact with a tangible or intangible yet functional product.
3. Customer flexibility–ensured through re-prioritizing product backlog between iterations.
4. Team stability–ensured by not allowing changes to the iteration backlog during the iteration.

1. Market portfolios–longest time horizons and broadest descriptions of the product
2. Product functionality (aka Themes)–delivered in successive linked waves
3. Roadmaps–functionality is operationalized in Epics and further defined in Feature Stories.
4. Releases (User Stories)–in each iteration, user stories are defined that aline with the Feature Stories and can be integrated into product functionality.

The next post will start with the first of the processes in the Planning process group that belong to the “External Stakeholders Engagement” knowledge area, namely Process 1.5 Product Roadmap.

Filed under: Uncategorized | Leave a comment »

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 6 knowledge areas.   Now I’m moving on to the one process in the seventh and last knowledge, that of Continuous Improvement, called Process 7.1 Define Required Ceremonies.

What do ceremonies have to do with continuous improvement?    These ceremonies referred to are:

• Sprint Planning, which looks forward to the next iteration
• Spring Review/Retrospective, which looks backward upon the previous iteration
• Daily Meeting, which looks at the status of the current iteration

These three ceremonies are formalized in order to engage stakeholders in structured discussions that help clarify and articulate their values and priorities.

By defining these ceremonies, the stage is set for continuous improvement during the course of the project.   But like the “ground rules” of team interactions, the defining of team ceremonies help set expectations and reduce the probability of misunderstandings so that the team can cooperate in producing an actionable, high-value product backlog that is “burned down” or completed incrementally with each iteration.

This covers the last of the processes in the Initiate process group.   The next group of processes is the Plan process group, an introduction to which is contained in the next post.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | 1 Comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »

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.

Filed under: Uncategorized | Leave a comment »