Last night was the inaugural meeting of the PMI Atlanta Chapter Agile Local Interest Group. This group will meet on the third Tuesday of every month to provide Agile speakers and events to support the Agile Project Management community. I am heading up the LIG with a great group of volunteers including Phyllis St John – who has been instrumental in getting the LIG up and running. Cox Enterprises provided that space and John Kosar from CCCI sponsored dinner and coordinated the space.

I was the presenter last night. I did an introduction to the roots of Agile and talked about Knowledge Domains around the new PMI Agile Certification.

Thanks to everyone who attended and provided input on what you would like to see from the LIG.

Mike Cottmeyer will be presenting next month. I will post details here on the location as we get that sorted out.

This is an ongoing discussion in the Agile regarding how PMBOK is contrary to Agile methods. I disagree with this assumption. I am producing this post to summarize a few key places where I think PMBOK is explicitly aligned with Agile

Sprints

PMBOK 2.1.3 talks about project organization. Figure 2.4 shows a sequential relationship of phases. Each phase has an initiating process, a circular interaction of planning and executing, and a closing process. Figure 2.5 shows an overlapping relationship between phases, where the closing process of a prior phase may overlap with the initiating phase of the next iteration.

The final Lifecycle in section 2.1.3 talks about an iterative relationship. "An iterative relationship, where only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables. This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research, bu it can reduce the ability to provide long term planning. The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value. It also can entail having all the project team members (e.g. designers, developers, etc.) available throughout the project, or at a minimum for two consecutive phases." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 22.

This model is precisely aligned with the way we run agile project including sprint planning, the sprint, and spring acceptance.

Progressive Elaboration

From Section 1.3 of the PMBOK, What is Project Management? "Because of the potential for change, the project management plan is iterative and goes through progressive elaboration through the project’s life cycle. Progressive elaboration involves continuously improving and detailing a plan as more-detailed and specific information and more accurate estimates become available. Progressive elaboration allows a project management team to manage to a greater level of detail as the project evolves." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 7.

Progressive Elaboration is shown in Figure 1.1 of the relationship between Portfolios, Programs, and Projects

From 5.1.2.8 Collect Requirements->Prototypes. "Prototypes support the concept of progressive elaboration because they are used
in iterative cycles of mock-up creation, user experimentation, feedback generation, and prototype revision." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 109

Self Organization

From 1.1 Purpose of the PMBOK(r) Guide "Good practice does not mean the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project." A Guide to the Project Management Body of Knowledge (PMBOK(r) Guide) – Fourth Edition, p. 4.

Responding to Change

Chapter 11 – Project Risk Management describes the following processes.

• 11.1 Plan for Risk Management
• 11.2 Identify Risks
• 11.3 Perform Qualitative Analysis
• 11.4 Perform Quantitative Risk Analysis
• 11.5 Plan Risk Responses
• 11.6 Monitor and Control Risks

"Known risks are those that have been identified and analyzed, making it possible to plan responses to those risks. " "To be successful, the organization should be committed to address risk management proactively and consistently throughout the project."

Scope is an input to Risk Management. As the Scope is being progressively elaborated, it follows that Risk Management must also be progressively elaborated. Risk includes Requirements Risk, Technology Risks, Quality Risks, Market Risks, Customer Risks, Prioritization Risks, etc. We plan to manage these risks in Agile through iterations, close customer collaboration, and responding to change. We inspect (learn about requirements, technology, quality, market, customer, and prioritization risk manifestation)
and the team adapts (this is our risk response from our plan).

Summary

These are not squinting at the PMBOK(r) and looking at it sideways. I was working on OPM3(r) Second Edition as the PMBOK Fourth Edition team was working. Making Agile fit, as it was considered a good practice (something that works for
most organizations most of the time in specific circumstance).

You can order a copy of the PMBOK Fourth Edition from Amazon for less than $35 US.

Trying to get a Podcast onto my Blog

[display_podcast]

This should be easier to do.

In my post yesterday I talked about the Big Agile Capability Model.  I received comments ranging from “We don’t need processes in Agile” to “CMMI already supports Agile”. I actually agree with both of those statements. We don’t need a highly detailed task list that doesn’t allow for flexibility or creativity in the creative steps of building software. In fact, we need an approach that allows for a lot of interaction. But we do need to work with intention – we don’t need to be reinventing every interaction every time.  And while CMMI does support Agile, it doesn’t look or sound like anything Agile people talk about. It hasn’t historically resulted in Agile behaviors developing within development teams. I believe that the very approach of implementing processes with complex names so that are auditable results in behavior that is contrary to the Agile approach.

A Capability, as we define it, is ““an ability or capacity the organization relies on for a specific purpose or outcome”.  No where do we say you need a highly documented and rigid process that must be followed and all forms filled out in triplicate. We aren’t describing a step-by-step process. Process is a “how” discussion within capabilities – capabilities are about outcome and purpose. They are highly interconnected. If you have clarity on the outcomes and purposes you desire from a capability, you begin to have a reasonable shot at coming up with a way to do it that works in your organizational context.

So, capabilities aren’t bad. They exist whether you do them intentionally or not. Our goal is to come up with a capability model (or lenses) to serve two purposes. First, we want to establish clarity what makes Small Team Agile work. This is important because as we scale, we still need to focus on delivering value to the customer through our small teams.  Second, we want to build a framework that is understood by the Agile community to talk about these capabilities through all the orders of scale.

To walk you through our process, we are basing our model on a decomposition Scrum and XP.  We look at the common roles of Product Owner, Scrum Master, and Team and identify the capabilities that typically are the responsibility of each role. The names and descriptions of the capabilities will be massaged some as we receive feedback and fine-tune our approach. But essentially, these are the capabilities that exist on most successful Agile teams today.

These capabilities should look a lot more familiar to an Agile team than the list of RUP or CMMI practices. The fact that you can map these to CMMI doesn’t make them familiar or encourage agile behavior. And we haven’t documented detailed processes in any of this. It is to understand the purpose and outcomes you are need in each capability and then intentionally work toward those purposes and outcomes. It is also important to understand how any improvement in a capability is going to improve your ability to optimize value delivery.