Agile Project Management Frameworks–Extreme Programming (XP)


In chapter 2 of John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference,” he goes through the various agile project management methodologies.    The most prominent one, Scrum, was discussed in the last post.    In this post, I summarize his presentation on the second most prominent framework in terms of adoption rate and marketplace usage, that of Extreme Programming or XP.

This is a list of features of XP that one should be aware of in studying for the PMI-ACP exam.

1. XP History

The ideas of XP were created in response to two changes in software development:  1) procedural programming was beginning to be replaced by object-oriented programming, and 2) speed-to-market became a strategic growth issue and shorter product life-cycles demanded agility to handle rapidly changing customer requirements.

  1. 1999–Kent Beck formalized his ideas for XP in his book Extreme Programming Explained.     This focused on technical practices that promoted skillful software development.
  2. 2004–XP continued to be developed, and the second edition of Extreme Programming Explained
    expanded the list of best practices to include:   continuous code reviews, pair programming, unit testing, modularity, bottom-up design, incremental design patterns, and refactoring of all code.

2.  Five Basic Activities of XP

  1. Coding–most important product of the development process is software code
  2. Testing–the more flaws testing can eliminate, the more working code can be delivered
  3. Listening–listening to customer needs so they can be understood well enough to discern the technical aspects of a viable solution
  4. Designing–limit system complexity by creating modular designs that organize the system logic with the minimum amount of dependencies
  5. Communicating–the opposite direction of 3. Listening, this is communicating to the customers the need to have system requirements for the developers to work on

3. Two Goals of XP

  1. Rapidly create and distribute organizational knowledge to the development team
  2. Create a unified with the customers and users of the system

4. Four XP Team Roles

  1. Customer–creates and prioritizes the stories (deliverables) to be developed.   Customer can vary release date by adding or removing stories from the backlog to be delivered (this is unique to XP).
  2. Programmer–estimates stories (i.e., how much effort is needed to complete a specific deliverable), writes code, usually working in pairs with another programmer, and writes tests
  3. Coach (OPTIONAL)–monitors process, mentors the team on XP processes and techniques, helps team identify risks and optimization opportunities
  4. Tracker (OPTIONAL)–monitors team progress and warns when schedule adjustments require redistributing of tasks.    A programmer can double as a tracker for another pair of programmers.

5. 12 Core Practices of XP

  1. Planning Game–technique used to elicit new requirements from the customer, with the team then giving an estimate of the effort required to develop and implement it
  2. Small releases–begin with the smallest useful feature set.   Release often, adding a few features each time.
  3. Product them–each product has an underlying theme or metaphor,
  4. Simple design–employ simplest possible design to get the job done
  5. Test-driven development (TDD)–write a test before adding a feature
  6. Refactoring–constantly improve a product’s internal design by rewriting code to make the product more reliable and adaptable
  7. Pair programming–two programmers work together, the first programmer (the driver) typing in code and focusing all attention on tactical choices and completing the current programming task, while the second programmer (the observer or navigator) reviews each line of code as it is written, considering potential problems with strategic choices, as well as suggesting ideas for improvements.    They switch roles frequently.
  8. Collective code ownership–everyone shares responsibility for the quality of the code, so that anyone can make necessary changes anywhere.
  9. Continuous integration–all product changes to the code base are integrated at least daily.
  10. Forty hour work week–if additional overtime is needed on a regular basis, this is considered a serious failure of the agile process.
  11. On site customer–development team has continuous access to an on-site customer or a proxy.
  12. Coding standards–everyone codes to the same standards and conventions

6.  6 Criticisms of XP

Although it is a very rigorous framework, there are some who have criticized the XP framework.  Among these criticisms are the following:

  1. Stability of requirements (customer can add or remove stories from the backlog at will)
  2. Lack of design specifications at the architectural of systems level
  3. Lack of a document trail defining compromises made to solve user conflicts
  4. Demand to have the customer/proxy on site (principle #11) is unrealistic
  5. Requirement to have a unified customer viewpoint versus a single programming organization (principle #11) is unrealistic as well
  6. Scalability seems to be an issue in XP framework

The next post will cover Lean Software Development, an agile framework which attempts to apply lean manufacturing principles that descend from the work of W. Edward Deming to the application area of software development.

Agile Project Management Frameworks–Scrum


In John Stenbeck’s PMI-ACP Exam Prep PLUS Desk Reference, he exhaustively lists the various agile project management frameworks in chapter 2 “Introducing Agile Project Management”.

This post will cover the very basics of the Scrum approach which is the dominant approach in Agile Project Management right now.

1.  Scrum History

  • 1986–Hirotaka Takeuchi and Ikujiro Nonaka write The new new product development game in Harvard Business Review, 64(1), 137-146, describing a holistic or “rugby” approach of having one cross-functional team moving through overlapping phases “passing the ball back and forth” as it were, similar to what happens in a rugby scrum.
  • 1991–Peter DeGrace and Leslie Stahl first refer to this approach explicitly as the “Scrum approach” in their book Wicked problems, righteous solutions:  A catalogue of modern software engineering paradigms (New York: Prentice Hall).
  • 1993–Jeff Sutherland, John Scumniotales and Jeff McKenna refer to this approach using the single word “Scrum” in the approach they developed at the Easel Corporation.
  • 1995–Jeff Sutherland and Ken Schwaber collaborate in writing, sharing experiences and suggesting industry best practices, creating the first public presentation of Scrum.

2.  Scrum framework definition

Scrum is a project management framework that uses

  • iterative cycles and
  • incremental deliverables

to develop solutions.

3.  Scrum ethos–mutual commitments between the organization and the team

The organization agrees on the stability of

  • the size of the timebox for all sprints (iterations)–usually two or four weeks in length
  • specific deliverables for each sprint

This commitment creates a stable work environment which allows the team to focus on the work uninterrupted.    The team, on the other hand, commits to

  • delivering the specific deliverables at the end of the sprint regardless of challenges that may occur

by promising to be as creative as necessary to solve problems.

4.  Scrum roles

    • Scrum Master (SM)–ensures the process is understood and followed, removes impediments in the form of outside interference for the team
    • Product Owner (PO)–also known as the “voice of the customer”, represents the stakeholders and the business, and sets the priorities for deliverables
    • Team–cross-functional group which implements solutions to create deliverables

5.  Scrum key principle

Customers need to be able to change their minds about requirements.   This flexibility allows solutions to complex problems to emerge through a process which provides transparency, inspection and adaptation towards a solution which satisfies the emerging customer’s requirements.

According to John Stenbeck, 75% of organizations using agile use the Scrum approach–this is why he has synthesized a review of the specific Scrum framework and the general Agile PM framework in his “PMI-ACP Exam Plus PLUS Desk Reference”, the PLUS being the material on Scrum.

In the next post, I will describe Extreme Programming (XP), second to Scrum in terms of its adoption rate and marketplace usage.

The Relationship between Lean Manufacturing Principles and Agile Project Management–Part 2


In John Stenbeck’s “PMI-ACP Exam Prep PLUS Desk Reference” guide, in his second chapter “Introducing Agile Project Management”, he takes on the huge topic of explaining the relationship between the development of lean manufacturing principles and the development of agile project management.    It’s important to understand this connection not only to understand the motivations behind agile project management, but also to dispel one of the common misconceptions about agile, that it is limited in its application to IT.

In this second part, I am going to elucidate the connection between Lean Manufacturing Principles and Agile Project Management.   First a brief recap:  here are the five core lean principles, which I’m repeating from the last post (Part 1).

A.  Five Core Lean Principles

  1. Define the value the customer desires.
  2. For each product, identify the value stream that provides customer value.
  3. Challenge all of the wasted steps not directly providing customer value and remove them, so that the remaining value-added steps flow continuously through to the product.
  4. Use “pulling” (production based on actual demand) between steps to create continuous flow.
  5. Continuously move toward perfection by reducing the number of steps, and the amount of time and information needed, to provide the customer value.

B.  The Relationship between Lean and Agile

Okay, now that we’ve spelled out the lean manufacturing principles and the core beliefs that underlie them, let’s go into how agile project management draws upon them.

Applying manufacturing principles to project management means that rather than the processes of production, you are now dealing with the processes of product creation or development.    The output of production is a series of finished products, and the output of the development process is a new product.

Let’s take a look at Agile Project management concepts and how they map to Lean concepts (principles and core beliefs from the above lists).

  1. Agile prioritizes business needs which are defined to create customer value (→ Lean Principle #1, 2).   Top priority is reserved for requirements that are most important to the customer, involve safety, and involve technical issues such as scalability.   The second tier of requirements should be those that focus on improving marketability, performance, and flexibility.  Then and only then should you focus on third-tier requirements that leverage opportunity or create comfort and luxury.
  2. Agile focuses on speeding up time-to-market by removing delays in the development process (→ Lean Core Belief #1).   This reduces the elapsed time from idea generation to delivery of value to the customer.
  3. Agile eliminates waste (→ Lean Principle #3).   This means waste in terms of time, in terms of money, and in terms of complexity of design (because it creates a lot more quality control work).  (→ Lean Principles #3 and #5)
  4. Agile defers commitment on decisions until sufficient information is available.   If decisions are made based upon assumptions that turn out not to be true, then this will turn out to waste time, which is Agile principle #3 above.   These decisions are usually in two areas, 1) defining requirements and 2) planning and estimating.  (→ Lean Principle #5).   On the other hand, decisions cannot be made too late because of an arbitrary desire for increased accuracy.   This is because increasing the accuracy of any estimate requires resources, and at some point, spending more resources on an estimate than is necessary to get a useful level of accuracy will turn out to waste money (→ Lean Principle #3 and #5).
  5. Communication with the customer is improved by developing the solution in increments and consulting with the customer at each increment   Instead of “pulling” production based on actual demand, which is the principle in lean manufacturing, in agile project management, the “pulling” that goes on is the clarification at each stage with the customer to make sure that the customer’s valued requirements are being translated into the technical characteristics of the product (→ Lean Principle #2, #4).   The design process can therefore be described as emergent rather than trying to be specified in detail at the very beginning stages as in traditional project management.

You can see by this set of correspondences between lean manufacturing principles and principles of agile project management that the frameworks share a lot in common, but that is because they have evolved in response to decreasing product design cycle times and increasing pressure on resources.

In the next series of posts, I will start a review of the agile frameworks, which include Scrum, Extreme Programming (XP), Lean Software Development, Feature Driven Development (FDD), Agile Unified Process (AUP), Crystal, Test Driven Development, and Agile Modeling (AM).   This will introduce the “agile lexicon” which is needed to understand the overal agile process map and the more detailed agile PM processes grid.

The Relationship between Lean Manufacturing Principles and Agile Project Management–Part 1


In John Stenbeck’s “PMI-ACP Exam Prep PLUS Desk Reference” guide, in his second chapter “Introducing Agile Project Management”, he takes on the huge topic of explaining the relationship between the development of lean manufacturing principles and the development of agile project management.    It’s important to understand this connection not only to understand the motivations behind agile project management, but also to dispel one of the common misconceptions about agile, that it is limited in its application to IT.

In this first part, let me reiterate John Stenbeck’s exposition of what the lean manufacturing principles are and the core beliefs that have evolved from them.

A.  Five Core Lean Principles

  1. Define the value the customer desires.
  2. For each product, identify the value stream that provides customer value.
  3. Challenge all of the wasted steps not directly providing customer value and remove them, so that the remaining value-added steps flow continuously through to the product.
  4. Use “pulling” (production based on actual demand) between steps to create continuous flow.
  5. Continuously move toward perfection by reducing the number of steps, and the amount of time and information needed, to provide the customer value.

“Lean thinking” based on these core lean principles started in manufacturing, but the tools and principles were adapted into other application areas or settings such as

  • service sector
  • healthcare
  • construction
  • non-profit
  • public sector

B. Six Lean Core Beliefs

The five core lean principles evolved into the six lean core beliefs which are articulated as follows (again, thanks to John Stenbeck for his thorough exposition).

  1. Measure of success for any system or process = the amount of time between when ideas come in and when value is received by the customer.
  2. Any ad hoc (undefined) system or process will produce unacceptable delay in customer value because it cannot be analyzed and improved upon.   Processes must be defined in order to improve customer value.
  3. Most process errors are caused by the system, not operator error (i.e., by people who work in the system.
  4. The goal is to optimize the whole system, not merely individual steps.   Rather than optimizing the efficiency of each individual step, it is better to look at when the steps occur (i.e., the transitions between the steps).
  5. Management must work with the team in order for the system to improve.
  6. Teams are most efficient when the amount of work expected is within their capacity; efficiency is best improved by minimizing the amount of non-value or low-value work in any process.

These core beliefs of lean thinking became a paradigm for agile project development.    How this process occurred is the subject of the next post (Part 2).

Mapping Agile to the Project Management Body of Knowledge (PMBOK®)


In his book on Agile Project Development entitled “PMI-ACP® and Certified Scrum Professional Exam Prep and Desk Reference”, John Stenbeck talks about how Agile fits into not only the PMBOK®, which is trademarked under the Project Management Institute, but under the other frameworks that exist in the world of Traditional and Agile Project Management.

1. Traditional Project Management

Let’s talk about traditional project management first.

The Project Management Institute is the industry leader (measured by the membership base) in traditional project management, with its PMBOK® framework.   John Stenbeck says that he thinks PMI remains the leader because of its extensive research grants and educational scholarships which extend and promote this framework.

There are other organizations in traditional project management, including

  • Prince2®
  • Association for Project Management (APM)–more prominent in the UK
  • International Project Management Association (IPMA)–more prominent in Europe
  • various universities (which issue certificates as well as degrees in Project Management)

2.   Agile Project Management

On the Agile side, however, there is a LOT more competition, because it is an emerging and less established field than traditional project management.

The Scrum Alliance is now the industry leader, because of its largest membership base.   The most recognized certification in Agile is the Certified Scrum Master®, but it also offers the Certified Scrum Product Owner® and Certified Scrum Developer® at the entry level, and Certified Scrum Professional® at the more experienced level.

In addition to the Scrum Alliance certifications, the other organizations are:

  • Scrum.org
  • PMI (with its new Agile Certified Practitioner certification (PMI-ACP®)
  • various universities (which issue certificates in Agile Project Management)

Although Scrum is an approach within Agile, Agile is broader than Scrum and includes other frameworks, of which the main ones are

  • Extreme Programming (XP)
  • Lean Software Development (LSD)
  • Feature Driven Development (FDD)

and the relatively smaller frameworks (in terms of the total market), which are

  • Crystal
  • Spiral
  • Dynamic Systems Development Method (DSDM)
  • Agile Unified Process (AUP).

Although Scrum Alliance’s Certified Scrum Master® certification is currently the industry leader, John Stenbeck says that he expects the new ACP (Agile Certified Practitioner) certification from PMI is eventually become the industry leader over the next few years.

Before John Stenbeck goes into all of the Agile frameworks above in Chapter 2 (Introducing Agile Project Management) of his book, he has a long digression on the relationship between the history of Lean manufacturing and Agile, because it shows not only the commonalities between them thematically, but it also points to one of the key reasons why John Stenbeck’s thinks that Agile will continue to grow in the project management community.    Most people have several preconceptions about Agile, one of the most common of which is that it is suitable for the IT application area, but not for other application areas.   The fact that many common ideas are to be found between Agile and Lean Manufacturing shows that Agile has a wide potential for application in manufacturing and other application areas.    The next few posts will cover this relationship between Lean and Agile…

Chicago Multicultural Connections Club


Tonight at the Chicago Multicultural Connections club, I gave a talk on the importance of learning a foreign language in today’s global economy, and I’m planning to give tips based on my experience in learning several foreign languages.

The contents of the speech are described in the last post.   I wanted to give my impressions of the hosts, the club, and the members in general.   When I was the Chief Project Manager for the Professional Development Day in 2014 for the PMI Chicagoland Chapter, I chose “The Third Coast Goes Global” as the theme of the all-day set of workshops.    I got the idea from a history of the city of Chicago called “The Third Coast,” the premise of which is that Chicago is rapidly becoming the third most internationally-connected city in the United States, despite the fact that it is in the heart of the Midwest.

The Chicago Multicultural Connections Club is geared for those professionals who have come to Chicago from other countries, and for whom English is often a second language, AND those professionals who live in Chicago who are interested in making connections with those from other cultures and countries.   I gave a talk there tonight on learning foreign languages, and it was obviously not a difficult task to convince them of the importance of this–rather I spent time comparing techniques that are better for adults who want to learn a foreign language efficiently.

There were people who originally came from Mexico, China, Ecuador, Austria, and Americans who have lived in Singapore, China, Germany, Japan and other places around the world.   But no matter the geography, they all the same mental geography, in that they were enthusiastic about the opportunity to cross cultural and linguistic boundaries.   I hope that I can join the club sometime in the future, because the members seem like “my kind of people.”

Amy Segami and Paula are the co-founders of the group, and they both are passionate about creating an opportunity to make Chicago and even more international city than it already is.    I know Amy Segami from the Windy City Professional Speakers Club, and I appreciate her generosity in setting me up with this opportunity to speak for her Chicago Multicultural Connections Club.    She is a very experienced speaker, and she gave me valuable pointers on how to reorganize my material so that even more impact.

The audience consisted of about a dozen or so people, and the setting  with the scattered tables, chairs and couches was more conducive to conversation than a typical lecture room with rows of chairs.     When I opened up the part of the talk about foreign language learning techniques, I got a lot of participation, and there were a lot of questions at the end.

As a speaking experience, I would say it went as well or even better than I had imagined it, and there were no technical glitches or any problems that marred the experience, at least for me.    I am exhausted after returning home from the presentation, but I am very happy because I made quite a few multicultural connections of members in the club, and I gained valuable experience as a speaker.    I had been the Master of Ceremonies twice, but giving an hour-long presentation is a lot longer and more varied speaking experience than I have ever had before.    But I saw it not as an hour-long speech plus a Q&A session, as much as a series of mini-speeches than I strung together and practiced separately so that the whole thing came off seamlessly.    I know in the future I can handle speaking engagements of this length without any difficulty, and I look forward to my next opportunity!

Becoming Fluent in a Foreign Language


Tomorrow at the Chicago Multicultural Connections club, I’m giving a talk on the importance of learning a foreign language in today’s global economy, and I’m planning to give tips based on my experience in learning several foreign languages.

There is a new book out by MIT Press called “Becoming Fluent:   How Cognitive Science Can Help Adults Learn a Foreign Language” by Richard Roberts and Roger Kreuz.    In that book they dispel three myths about learning a foreign language.

Myth 1:   Adults cannot acquire a foreign language as easily as children.

Children do have 2 distinct advantages over adults in learning a foreign language; they can learn native accents more easily, and they are less self-conscious and have fewer self-limiting beliefs, like the belief that … adults cannot acquire a foreign language as easily as children.    Children know how to manipulate symbols, but adults know how to manipulate rules, and that gives them a cognitive advantage in learning another language that not only has new symbols, but new rules as well.

Myth 2:  Adults should learn foreign languages the way that children do.

Adult brains are different than children’s brains; they are wired differently, so trying to learn foreign languages the way that children do, by just imitating what they hear, and relying on trial and error, is going to make the process more difficult and more frustrating for an adult.

Myth 3:  When learning a foreign language, try not to use your first language.

Although the “total immersion” method is popular, it keeps you from using your own native language as a natural lever to get you to the “other side”.

Here are some tips on learning a foreign language.

  1. Determine what is realistic–use the Common European Framework of Reference for a goal
  2. Go public with your goal–write a blog, tweet your goal, or mention it in an e-mail or post to a group
  3. Find a study buddy–Italki, Meetup, etc.
  4. Study at the same time each day–Duolingo is a good resource here
These are the myths about learning a foreign language, the tips I intend to talk about, and a preliminary set of resources, which I will pass out at the presentation tomorrow.    I will have an “after” post to describe how the talk was received.

Comparing the Process Groups and Knowledge Areas between Traditional and Agile Project Management


One of the first things I have those who attend my online PMP study group do is to memorize the names of the 5 process groups and 10 knowledge areas from the PMBOK Guide–there are 5 process groups and 10 knowledge areas.    This is a prelude for them to learn the 47 PM processes and where they go on the Traditional PM Processes Grid.   This grid is formed when you put the 5 process groups across in columns and the 10 knowledge areas down in rows.    Memorizing this grid is part of the initiation ritual for those who want to pass the PMP exam.    Why?   Knowing the names of the processes and their proper order to the extent that you can reproduce on a piece of paper in 10 minutes or less is a key skill to learn for preparing for the exam.    It helps you in many ways, for example, in situational questions involving “what do you next?”, it is important to identify what process you are in now and then realize from the grid what process you are heading towards next.    Putting this in an external form like a piece of paper allows your mind to use that processing space to focus on the details of the question, as if you were clearing RAM on your computer.

As I study Agile Project Management using John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference,” I see that there is an Agile PM Processes Grid at the end of the 2nd chapter.    This immediately caught my eye and i wanted to compare this grid with the Traditional PM Processes Grid as found in the PMBOK Guide.

Here are the five process groups in Traditional and Agile PM.

TRADITIONAL Initiating Planning Executing Monitoring &
Controlling
Closing
AGILE Initiate Plan Iterate Control Close

Notice how the Initiating, Planning, and Closing are the same between the three (using the normal verb form in Agile rather than gerund or noun form used in Traditional).   Monitoring & Controlling is shortened to Control, and then Executing is replaced by Iterate.    In reality traditional PM also goes back and forth between Executing (doing the project work) and Monitoring & Controlling (checking the project work), but this “back and forth” pattern is emphasized in Agile with the word “Iterate”.   So far so good; these two sets of process groups correlate pretty clearly.    Now let’s go on to the knowledge areas.

TRADITIONAL AGILE
Integration External Stakeholders Engagement
Scope Value-Driven Delivery
Time Adaptive Planning
Cost Team Performance
Quality Risk Management
Human Resources Communication
Communications Continuous Improvement
Risk
Procurements
Stakeholders

Note that this is just the order that the knowledge areas are listed in.    There are 10 knowledge areas for Traditional PM, and 7 knowledge areas for Agile.     How do these knowledge areas correlate?     Well, here’s my best attempt to put those knowledge areas in Traditional PM next to their Agile counterparts.

TRADITIONAL AGILE
Integration (various knowledge areas)
Scope Value-Driven Delivery
Time Adaptive Planning
Cost Adaptive Planning
Quality Value-Driven Delivery,

Continuous Improvement

Human Resources Team Performance
Communications Communication
Risk Risk Management
Procurements N/A
Stakeholders External Stakeholders Engagement

You can see it’s not a neat, one-to-one mapping as with the process groups, mainly for the reason that there are 10 knowledge areas in Traditional PM and 7 knowledge areas in Agile PM.

Let’s take the Agile knowledge areas as they appear in the original order and discuss how they correlate.

  1. External Stakeholders Engagement–this obviously correlates with Stakeholder Management in Traditional PM, but notice that it is the first knowledge area rather than the last one as in Traditional PM, which shows the priority that Agile places on feedback to and from the customer throughout the entire set of Agile Processes
  2. Value-Driven Delivery–This covers Scope Management in traditional PM.  In that quality is considered creating a product whose technical characteristics fulfill the functional requirements gathered from the customer, this covers the quality control portion of the Quality Management knowledge area in Traditional PM
  3. Adaptive Planning–This covers the Time and Cost Management knowledge areas in Traditional PM
  4. Team Performance–This covers the Human Resources Management knowledge area in Traditional PM
  5. Risk Management—This covers the Risk Management knowledge area in Traditional PM
  6. Communication–This covers the Communication Management knowledge area in Traditional PM
  7. Continuous Improvement–This covers the quality assurance portion of the Quality Management knowledge area in Traditional PM, rather than the quality control portion which falls more under Value-Driven Delivery knowledge area in the Agile PM Processes Grid.

One additional comparison needs to be made, and that is the difference between the Agile PM Processes Grid and the domains listed by PMI that are covered by its PMI-ACP exam.   This comparison is below.

AGILE KNOWLEDGE AREAS PMI-ACP DOMAINS
1. Agile Principles and Mindset
2. Value-Driven Delivery 2. Value-Driven Delivery
1. External Stakeholders Engagement 3. Stakeholder Engagement
4. Team Performance 4. Team Performance
3. Adaptive Planning 5. Adaptive Planning
5. Risk Management 6. Problem Detection and Resolution
7. Continuous Improvement 7. Continuous Improvement
6.  Communication (included in 4, 5)

How do these compare?     Well, the PMI-ACP Domain of “Agile Principles and Mindset” is kind of like the first three chapters of the PMBOK that explain the concepts behind Traditional Project Management.   The other PMI-ACP Domains map pretty well to the Agile Knowledge Areas in the “Agile PM Processes Grid” with two notable exceptions.

Risk Management is a part of problem detection and resolution, but the “resolution” portion of the PMI-ACP Domain also includes the implementation of continuous improvements that are proposed in domain 7.    And Communication is a VERY important Agile Knowledge Area.   The reason why it is not included in the PMI-ACP list of domains is not because PMI doesn’t consider communication important for Agile, rather it is SO important it is hard to confine it to one domain.    It shows up in tasks that are in domains 4 (Team Performance) and domain 5 (Adaptive Planning) for the most part, but to a lesser extent in other domains as well.    It is “omnipresent” within all of the other domains, let’s put in that way.

I hope this post is helpful, and if any readers have any suggestions or questions on these comparisons, please let me know.    After I go through the remaining material in chapter 2, “Introducing Agile Project Management” (part of the “Agile Principles and Mindset” domain on the PMI-ACP exam), I will list the actual processes in the grid.

Executing and Controlling a Project in Agile vs. Traditional Project Management


In a post two days ago called “The Triple Constraints …”  I explained how John Stenbeck in the second chapter of his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference” showed the difference between how the triple constraints are handled differently during the planning process in agile project management versus the way they are handled in traditional project management.

In this post, I would like to explain his next topic, which shows the difference between the way that agile and traditional project management handle two other phases of project management, executing and monitoring/controlling.

As mentioned in the earlier post, of the triple constraints, scope is the one which is the focal point of planning under traditional project management, where it is as well-defined as possible, and the other constraints of cost and time are determined based on the resources available.     However, in agile project management, the time and the cost are the well-defined constraints, and the scope is determined based on those resources.    So rather than the work package, the unit of scope if you will in traditional project management, the work period or timebox is the unit of time used to manage product development cycles in agile project management.

Just as in traditional project development, you take the final deliverable and break it down with the decomposition method into smaller and smaller deliverables until you get to the level of work packages, timeboxes in agile project management can also be broken down.    Let’s look at the various levels of timeboxes in agile.

Level 1–Roadmap

A roadmap is used in agile project management to align the shorter development cycles with a desired future business result.   They are the equivalent of a portfolio plan in traditional project management.    Roadmaps are composed of release plans.

Level 2–Release Plan

A release plan is used in agile project management to guide development of sets of features that represent a component of the overall product solution.    Often, release plans represent the point at which deliverables can be used or implemented by customers.    Release plans are composed of iterations plans or iterations.

Level 3–Iteration

Iteration plans or iterations are timeboxes in the sense that they are units of time defined as either two, three, or four weeks, depending on the organization’s norms or rules.   Having a fixed unit of time for the iteration helps with stability, which allows the team to improve quality steadily over time.    Within each iteration, user stories are developed which are descriptions of work efforts for specific features or components that will be created by the agile team during the iteration.    User stories are probably most comparable to a combination of work packages and activities in traditional project management.

In traditional project management, deliverables are broken down through the decomposition process into work packages in Create WBS (process 5.4) in the Scope Management knowledge area.   Work packages are the smallest unit of deliverable, that is, tangible features or components that will be created.    Then, in the Time Management knowledge area, in Define Activities (process 6.2), the activities are listed which will create the work packages.    Work packages are nouns, activities are verbs.

However, in agile project management, both the description of the specific features of components that will be created by the agile team and the work effort  needed to created them are combine in the user stories.    Sometimes, the user stories can be broken down into tasks used to fulfill each user story.

Within each iteration, there are three feedback cycles.

  1. Daily meeting (sometimes referred to as a “stand-up meeting” or “Scrum meeting)–synchronizes the daily activities of all of the team members, and allows measurement of daily work progress against the iteration plan.
  2. Review meeting–at the end of each iteration timebox, this is a product-centric meeting which presents the completed deliverables to all interested stakeholders so that they can give feedback on how well it meets their needs and expectations.
  3. Retrospective meeting–again at the end of each iteration timebox, this is a process-centric meeting where the agile team, Scrum Master (the project leader), and Product Owner (the project’s key stakeholder) discuss process improvement ideas in order to produce better work products, reduce errors, and/or improve communications.

So the iteration plans are rolled up into release plans, which are rolled up into roadmaps.   This is the decomposition of timeboxes that is characteristic of agile project management methodology, as opposed to the decomposition of scope that is characteristic of traditional project management methodology.

A Time to Remember–14 Years Ago Today


For my Toastmasters Club, I wanted to do a speech to memorialize the events that had happened on September 11, 2001 as I remembered them from my vantage point in midtown New York City.    I originally had thought of doing it as a narrative, but then an improvisation workshop I  took at a Toastmasters Leadership Institute session gave me the idea of doing is a play, recreating the events and dialogue I had with co-workers and family.    

It was a lot more effective to act out the events of the day rather than simply describing them.    I wanted to get across two key ideas, that humor can help you distance yourself from painful events to help you survive them, and that something positive can be gained from adversity with an attitude of gratitude.

Time to Remember

(Stepping out to audience, and singing these lyrics of “Time to Remember” from The Fantastiks )

Try to remember the kind of September when you were a tender and callow fellow

Try to remember and if you remember then follow … follow follow follow

(beckoning to audience in “follow me” gesture, sitting down in chair)

(Picks up imaginary telephone) Hello, this is Mitsubishi Motors, can I help you? (Suddenly smiling and relaxing) Oh, Dad! Why are you calling me here in New York so early? It must be only 7:00 AM there in Chicago—oh, slow down, slow down. (Sitting forward, with worried look.) Oh you were watching CNN when you saw a report of … what? A plane hit the World Trade Center? John’s company is in one of those buildings, you know. Did you call him? You got a busy signal. Okay, I’ll call him and then call you back. Oh, speaking of planes, did Mom get on her plane yet? Well, call her while I’m calling John.

(reaches for telephone) First, I’d better tell Ken about this—he’s the only with a TV in his room. (Getting up, knocks on imaginary door in center stage.) Sorry, Ken—this is an emergency. My Dad called from Chicago and said he saw on television that a plane had hit the World Trade Center. You’d better turn the TV on to find out what’s going on. (Now looking to left at imaginary TV.)

Watches TV—I have no idea what kind of plane it was, but it must be one hell of an accident. (Puzzled look, and then shakes head in noncomprehension.) What? A second explosion? Where did that come from? A second plane (“oh my God” look forming on face)? You know what this means, don’t you. I’ve get to tell our boss.

(stepping back, folding hands in calm gesture and speaking directly to the audience)

At this point, we knew it was a terrorist attack, not an accident. I tried calling my brother John, but there was no answer; all communication was now cut off. It turns out his company, Marsh & McLellan, was in the center of where the plane hit in the North Tower. I knew he was safe because he didn’t work in that building, but rather in a building in Midtown Manhattan near where I worked. It was my mother I was worried about, because as far as I knew, she was getting ready to board a flight heading from the East Coast to Chicago.

(Moving forward and talking in center stage at same colleague’s “door” as before.)

I heard the secretary next door started a rumor that they “got the Sears Tower in Chicago” (imitating New York accent). Did they attack it or are they just evacuating it?  What is it, Ken? What’s happening to the South Tower? (looking at TV, staring in horror, as hands slowly cover face)

For months after seeing the South Tower fall in September 11, I had a recurring nightmare. I’m in an office building, and there’s a rumbling like an earthquake. I look outside the window and the high-rise buildings next to us inexplicably start shooting upward. And then, I realize that they are not shooting up in the air—it is our building that is falling to the ground, and I have only a few seconds to live … and then I wake up in a cold sweat.

I finally went to a hypnotherapist and he found under hypnosis that during that time when I saw the building fall, I empathized with those poor people who were about to die to the point that I identified with them. That’s why in my imagination I joined them in their final moments.

Yes, Hase-san. Major Guiliani as just given the evacuation has just been ordered.  One problem: there’s no public transport going in or out of Manhattan. I guess we’ll have to walk to the bridge, cross it and take transport on the other side. Hai, gambarimasho. Yes, let’s all persevere.

On the way back home, as I crossed the bridge from Manhattan to Queens, I saw the two gaping wounds in the Manhattan skyline pouring out smoke. I had the same feeling many had that day that we had just experienced the Pearl Harbor of our generation.

Oh, I’m so thirsty, thank Heaven for 7-11. (Tries door, face showing surprise) How could a 7-11 be closed? Wait a minute–there’s a sign … “closed due to terrorist attack”. Oh, for goodness sake. Why, did they think they were next? That’s what I call delusions of grandeur.

I can just see it now, Osama bin Laden is in a cave somewhere saying, “well, did you get the World Trade Center?” “Yes, we did!” “What about the Pentagon?” “Yes, we did!” “What about the 7-11 in the mini-mall in Queens?” “Uh, no, we didn’t!” “Son of an infidel! You’d better get it next time!” (Laughs at ridiculous image.)

I realized just then that I had laughed for the first time since all of this started. Of course I wasn’t laughing at the terrorist attack, I was laughing at fear. It was suddenly as if a fog lifted, and I realized, if I can laugh at fear, I can survive and move forward. I walked home the rest of the way.

(Hands in prayer position) Hey, I know you’re busy today, but you’re the only one who hasn’t given me a busy signal all day. Please make sure my brother and mother are okay, that’s all I ask. (phone rings) Dad! (points thumb up to ceiling in “OK”gesture). Oh, I’m so glad to hear your voice. I just got in. Is Mom okay? Oh, her plane got grounded. Yeah, she and thousands of other people. Oh, well, at least she’s okay. And John? I’m sure he sounded shaken, considering … Poor guy! Well, Dad, at least all in the people in your family are still alive. I really appreciate you calling. I love you, Dad! (looking upward and mouthing the words) Thank you.

(getting up and singing final verses from “Time to Remember”

Deep in December it’s nice to remember without the hurt the heart is hollow

Deep in December it’s nice to remember the fire of September that made us mellow

Deep in December our hearts will remember and follow …