Linked to Strategy

Posted on September 7th, 2010 by Dennis Stevens  |  1 Comment »

What is keeping corporate executives up at night? Is the CxO laying awake wondering if her company is good at project management or software development? Probably not. AMA says that the top issue facing executives is executing their strategy.

“The practice representing the largest difference between higher and lower performers is demonstrating the ability to quickly and effectively execute when new strategic opportunities arise.”
~ AMA, The Keys to Strategy Execution, 2007

So what are the keys to executing strategy? Recent research from PMI shows that when we align projects with the business strategy and clearly communicate the strategy to the team, then projects are delivered at a much higher rate.

“The single most important factor influencing project success is the project’s link to the organization’s business strategy and the project manager’s understanding of how the project supports the business strategy.” 
~ CIO Magazine-November 2009: Business Strategy: The "Best Determinant" of Project Success

So it sounds easy, we need to focus on executing the projects that advance our business strategy. And we need to communicate this strategy across the organization and the project team. How well do the ways that we select projects and communicate their strategic significance accomplish this?

How Do We Select Projects?

So how do most organizations decide where to invest? Projects are selected for the portfolio based on local ROI’s calculated by business managers, or by spreading investment across the organization based on head count like peanut butter, or by charging IT organizations to run IT like a business with departmental reimbursement. Are these the best ways to handle this? Probably not. None of these connect the projects to strategy – and none of these make the connection between strategy and the project explicit.

ROI’s are almost impossible to estimate. Local ROI’s don’t equal organization level benefit. For example, one organization spent $10 million implementing an automated solution to allow them to scale for seasonal demand. The $10 million was justified through service improvement and reduced labor in the department but it shifted significant costs from departmental budget to the IT department for customizations, maintenance, and ongoing licensing. In addition, ROI’s don’t provide an effective way to communicate the underlying assumptions about how the project supports the business strategy.

Spreading investment based on head-count assumes that all improvements are equal or that we can do enough in each area to raise the whole ship. The is no way we can make all the improvements in the organization, there is a limited amount of capacity for change and there is a limited amount of resource to invest. It is extremely unlikely that all problems will result in the same benefit to the business. In fact, this approach, while extremely common, ends up being destructive. It spreads limited resources too thin, it creates excessive demand for the enabling functions (IT, training, project management, support). And it obfuscates business strategy.

Running IT like a business sounds great, but it is another case of local optimization. IT is an enabler of business value. Some of the investments the business needs to make will have short term costs but they will return long term value for the business. When IT is run from the view of short term profitability you will often miss out on the most important investments. In this case, IT’s strategy – making profit from its resources from the business – it not aligned with the business strategy itself.

Based on numerous studies, the leading obstacles to project success are related to scope creep and shifting requirements, inadequate and/or disappearing resources, and a lack of effective executive sponsorship. All of these are related to organization’s trying to execute strategy without a clear alignment between strategy and the projects in the portfolio. Local ROI’s, equal distribution of investment, and local optimization of IT don’t solve these problems. They don’t clearly connect project efforts to the business strategy. And they aren’t resilient to the real changes in the market that businesses have to be able to adapt to.

So What Do We Do?

We need a way to reflect the business model and the where the strategy impacts the business model. We need to be able to clearly articulate what changes need to take place to deliver on the business strategy. And we need to be able to adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily.

We use capability mapping to achieve this. A capability map, as discussed in an article I co-authored June 2008 Harvard Business Review "The Next Revolution in Productivity" addresses these challenges. It clearly articulates the business model in a stable way, let’s you directly connect the business strategy to the business model, and let’s you connect project efforts to the capability map. This provides traceability from project to business model to strategy in a powerful visual management tool.

Five Steps to a Powerful Capability Map

1. Articulate the Near Term Business Strategy.

We frequently use a model we have developed based on Patrick Lencioni’s “Silos, Politics, and Turf Wars” called a Thematic Goal Model. It is straight forward, powerful, and communicates clearly. We can provide input to this from a SWOT analysis, a balanced score card, or multiple empirical methods like QFD to determine strategic themes. The outcome is a clear statement of a limited set of the near term strategic themes. The next set of “big rocks” that need to move to advance the business strategy. The important thing here is to make it visible and to get buy-in from the organization.

2. Decompose the Business into its Constituent Capabilities.

Decompose the business into the activities or functions of the organization. The activities are performed for a purpose, to achieve some outcome or transformation the business needs to accomplish.  Then, interpret activities as capabilities. Capabilities are independent of how they are done, who does them, and the organizational structure. They are named in a “Verb-Noun” form and express the underlying business purpose. A common mistake is to treat a process, or a “how”, as a capability. For example, “Produce Invoice” is not a capability. The business purpose is not to produce an invoice. The purpose of producing an invoice is to “record a customer charge”  and to “request payment from the customer”.  You can decompose the capability map to whatever level is interesting for your particular situation. We will do a limited drill down to start and then build out a more detailed view as the business strategy dictates. This can keep you from getting stuck in an analysis paralysis. Develop the map collaboratively, you will want buy-in from the organization when it is time to make the tough calls about what to invest in.

3. Evaluate the Capability Map in the context of the Business Strategy.

For each capability you can ask a few questions determine the strategic significance. Is this capability directly related to the business strategy? Would a significant change in this capability directly help the business execute its strategy? This can be an interesting exercise because different people will have different perspectives on what is important. Be rigorous in the assessment. Everything in a business is connected at some level. You are looking for direct relationships between capabilities and strategy. When you get down to determining how to address any interesting capabilities you will get a chance to explore the other related capabilities. Keep bringing the focus back to the strategic connection – not to individual functions. Rank the capabilities on a scale of 1-5 with 1 being directly and 5 being not at all. The capabilities that end up being a 1 or a 2 are strategically interesting.

image4. Determine Performance Gaps at the Strategically Interesting Capabilities.

Now, look at the strategically interesting capabilities. Determine the performance gaps you would need to close to achieve the business strategy. You are not looking to identify every potential improvement at the capability – you want to be specific about what improvement is needed at which capability to achieve the specific business strategy. Again, you have to be rigorous. The goal is to identify the smallest subset of changes needed to achieve the business strategy. Remember, this is a focusing effort.

5. Determine a Road Map to Achieve the Strategy.

Now, you have a very clear set of improvements to focus your improvement efforts on. Drive your portfolio decisions from here. Articulate these as a specific performance improvement, at a specific capability, to achieve a specific strategic outcome.  Initially, all of this is done at a relatively high level. Once you have your specific initiatives you can do more detailed discovery about the best way to accomplish the objectives. Lay these initiatives out across all the enabling functions. You want to balance the efforts against capacity to optimize time to strategic value.


Now we have a way to reflect the business model where the strategic impact is explicit. We can clearly articulate what specific changes need to take place to deliver on the business strategy. This model can keep us focused when we start to get pressure from multiple directions. But we can also adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily. Better than ROI approaches, better than a bottom up local optimization model, better than running IT as a business, we can focus our efforts on executing the projects that advance our business strategy. We can synchronize efforts across the various enabling functions to optimize time to strategy. And we can communicate this strategy across the organization and the project team. Each activity on every project can be clearly linked to strategy.

How We Earned our Right to Education

Posted on September 7th, 2010 by Dennis Stevens  |  1 Comment »

Dads Courage AwardMy dad sent me this. He is a 76 year old Korean War era Marine veteran and has spent the last 20+ years fighting prostrate cancer and advocating for prostrate cancer awareness. This year he was awarded a Courage Award from Piedmont Healthcare and the Atlanta Braves “For being a pillar of hope and inspiration in the community and leading the effort to find a cure”. He sends me inspirational and patriotic notes like this once in a while. This isn’t about Lean or Agile or Software Development Project Management, but I wanted to share it with you.

How Students Earn Their Right to Sit in a Desk in the Classroom

Back in September 2005, on the first day of school, Martha Cothren, a social studies school teacher at Robinson High School , did something not to be forgotten. On the first day of school, with the permission of the school superintendent, the principal and the building supervisor, she removed all of the desks out of her classroom.

When the first period kids entered the room they discovered that there were no desks.

‘Ms. Cothren, where’re our desks?’

She replied, ‘You can’t have a desk until you tell me how you earn the right to sit at a desk.’

They thought, ‘Well, maybe it’s our grades.’

‘No,’ she said.

‘Maybe it’s our behavior.’

She told them, ‘No, it’s not even your behavior.’

And so, they came and went, the first period, second period, third period. Still no desks in the classroom.

By early afternoon television news crews had started gathering in Ms.Cothren’s classroom to report about this crazy teacher who had taken all the desks out of her room.

The final period of the day came and as the puzzled students found seats on the floor of the deskless classroom, Martha Cothren said, ‘Throughout the day no one has been able to tell me just what he/she has done to earn the right to sit at the desks that are ordinarily found in this classroom. Now I am going to tell you.’

At this point, Martha Cothren went over to the door of her classroom and opened it.

Twenty-seven (27) War Veterans, all in uniforms, walked into that classroom, each one carrying a school desk. The Vets began placing the school desks in rows, and then they would walk over and stand alongside the wall. By the time the last soldier had set the final desk in place those kids started to understand, perhaps for the first time in their lives, just how the right to sit at those desks had been earned.

Martha said, ‘You didn’t earn the right to sit at these desks. These heroes did it for you. They placed the desks here for you. Now, it’s up to you to sit in them. It is your responsibility to learn, to be good students, to be good citizens. They paid the price so that you could have the freedom to get an education. Don’t ever forget it.’

According to, this is a true story.

Don’t forget that many of the freedoms we have in this great country were earned by War Veterans.

My Job is hard, Yours is easy

Posted on August 30th, 2010 by Dennis Stevens  |  1 Comment »

I really enjoyed Agile 2010 this year. My workshop, “Feeding the Agile Beast”, and presentation, “Using Lean and Agile to Lead Business Transformation”, were both well received. We found good interest in the Agile Extension to the BABOK. ICAgile was a topic of conversation and for the most part we found an appetite for a solid certification model. I also got to spend time with people I consider to be in my tribes. Just to name a few – note: if I fail to mention someone it is not intentional, just tweet me and I will add you to the appropriate clan(s)

While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.

It isn’t just about code

I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.

When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.

Excuse me, but are you kidding me

Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.

My Job is Hard, Yours is Easy

A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s.  People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.

I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.

Certification, the Dreyfus Model, and Tilting at Windmills

Posted on August 25th, 2010 by Dennis Stevens  |  3 Comments »

There continues to be a lot of discussion about certification and the value of certification. Most recently at PM Hut with Certifications Don’t Make Project Managers. The article argues that PMP certification is not useful because we still fail at projects at an alarmingly high rate. I think it is a flawed argument in many regards (check my three or more comments) but I understand the underlying concerns. First, that hiring managers take certification to indicate an improbably high level of competence. Second, that there are talented people that can’t or choose not to pursue certification. Let me address both of these concerns.

What Does Certification Imply

From my experience, a PMP is like a recent college graduate, a medical resident, or a 16-year old who just got their license. They have shown interest in being project managers, have some situational awareness from having participated in projects, have been educated in the fundamentals and share a common language. But they are not prepared to be CEO of a business, an emergency room surgeon, or a cross country truck driver. I am not sure how big a problem this really is.

The Dreyfus Skill Acquisition Model identifies five stages of competence:

  • Novice: Basic understanding of concepts. Adherence to rules. No discretionary judgment.
  • Advanced Beginning: Situational perception. All aspects of work treated with equal importance.
  • Competent: Coping with crowdedness. Formulating routines. Able to recognize patterns.
  • Proficient: Holistic view. Senses deviations from the pattern.
  • Expert: No longer relies on rules. Based on deep tacit knowledge. Vision of what is possible.

Certification takes you no higher than Advanced Beginner and probably doesn’t guarantee any more than Novice. But a Novice is way ahead of the competence curve from someone who has no idea what to do.  To be a great project manager who can run projects in complex organization unsupervised you probably need to rise to the level of Proficient or Expert. Additionally, Getting beyond Advanced Beginning requires more than just some knowledge. We talk about Knowledge, Skills, and Aptitudes. Beyond project management knowledge, there are soft skills and organizational aptitudes necessary to be successful leading complex projects.

I don’t think that the concern that hiring managers and HR departments place too much weight on the PMP is a real problem. In my conversations with HR managers and hiring managers, they aren’t assuming more than this. The fact that hiring managers are asking for PMP’s as an entry point means that they are looking for a common starting place and basic level of intent and awareness.  If they want to greater level of Skills and Aptitudes then they should interview for these. PMI supports this model through their Project Manager Competency Development Framework.

People Who Can’t or Won’t Earn Certification

I earned my PMP in 1998. I have been active with PMI since then including working as the Deputy Project Manager for OPM3 and my current work as a member of the OPM3 Services Advisory Group and on the board of the PMI Agile Virtual Community. My PMP lapsed in 2001. I have not renewed it. Why? At the time it was partially due to the neglect of not attaining and recording PDU’s and partially due to tilting at this certification windmill. I felt that the real value of PMI was in the community and in advocating for responsible project management. I put my money where my mouth is – I support the community and advocate for responsible project management. I don’t really need my PMP at this point to get a job. If I did, I would have it. In fact, I wish I had kept it as I gained nothing by tilting at the PMP windmill.

If you can’t get a job because you don’t have a PMP or can’t pass the PMP test, then you should get your PMP. Unless you want to be unreasonably stubborn – like I was – or want to continue to not be evaluated for a job. This argument just doesn’t hold water for me. While I have known plenty of super capable, super talented project managers that were PMP-less – they had the language, they had the hard and the soft skills, and they had the organizational aptitudes to be successful. It is a logic fallacy to say that because there are good project managers without PMP’s that you shouldn’t look for PMP’s to be your project managers.

Tilting at Windmills

The shame of this is that there are real issues with project management today. We don’t have a clear enough path for determining Agile Project Managers (ICAgile is looking to address this shortly). HR organization’s fail to interview effectively for situation appropriate Skills and Aptitudes. Many companies don’t invest in the developing project managers further up the Dreyfus model. Organization’s are still poorly designed for adapting to change and supporting project execution.

However, none of this has anything to with the value of the PMP or other types of certification. Certification is the beginning of the journey. It is the first driver’s license, the college degree, acceptance into the residency program. Certification is critically important. It sets the baseline. It establishes the basic body of knowledge that is expected. It creates awareness in HR departments and with hiring managers of what kinds of knowledge they should be looking for.

So, rather than tearing down certification and slandering organization’s that have promoted our profession and created great communities for us – let’s put our energy into:

  • creating awareness of the need for further growth
  • promoting to individuals and hiring managers the Knowledge, Skills, and Aptitudes needed to climb the Skills Acquisition Model.
  • communicating the value that organization’s receive when they are organized to be adaptable and execute strategy well

There is power and benefit in these activities. The continual bashing of certification and the organization’s that support them is just useless tilting at windmills.

We are Doing QA All Wrong

Posted on August 23rd, 2010 by Dennis Stevens  |  17 Comments »

Over the last month I have presented or participated in several user groups and conferences. There was Southern Fried Agile in Charlotte, Agile 2010 in Orlando, a PMI Atlanta professional growth event, meetings of Agile Atlanta and the Atlanta Scrum Meet-up, and Product Camp Atlanta (not surprisingly in Atlanta). These conferences give me an opportunity to meet with people doing, or attempting to do agile in the enterprise. There are a lot of common patterns that I am seeing. One of the most common patterns is that we are doing QA all wrong in most companies.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

  • the cost of setting up testing environments is much lower
  • our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
  • our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.


Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

  • Switch their primary focus to Quality Assurance
  • Help the organization reduce re-work
  • Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
  • Enable value, flow, and ongoing improvement
  • Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?

Synergy Between PMBOK and Agile

Posted on August 22nd, 2010 by Dennis Stevens  |  No Comments »

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


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 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).


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.

Interesting Links this Week

Posted on July 18th, 2010 by Dennis Stevens  |  No Comments »

Here’s a summary of some of the posts that made me stop and think this week. I believe this new format is more useful than a dump of all the posts I tweeted during the last week. Thanks to @coryfoy for helping me with the Google Reader logistics on this. Enjoy!

Connectivism in the Enterprise

“When information develops rapidly, the content is no longer the object of learning activities. Instead, the development of the learner’s capacity for ongoing growth (adaptation) becomes the key focus.”

15 Awesome Quotes on Creative Collaboration

"It is the long history of humankind (and animal kind, too) those who learned to collaborate and improvise most effectively have prevailed." – Charles Darwin

Taming the Agile Enterprise: Value Stream Mapping for Knowledge Work

Value Stream Mapping is a proven and effective way to address challenges within the manufacturing environment, an environment with static processes. This article expands on that, showing ways to
modify it to be compatible with the world of knowledge work, where the challenges are more dynamic, complex and fast paced.

Favorite Tweet of the Week

@rkelly976: My 3yr old got upset, my 5yr old "Dad, explain it to her, don't just tell her". A communication lesson there #pmot #leadership

Kanban, Mental Models, and Double Loop Learning

That means we need to create an environment where:

  • valid information is apparent
  • it is safe to explore underlying assumptions
  • participants are actively involved in controlling their tasks and collaborative problem solving
  • the participants are focused on a bigger goal
  • we can compare the result of our change actions with the actual outcomes

Capability Development

“The one statistic that for me sums up where China is going is the 60 million qualified university graduates that enter the workforce each year.”

Strategy Is For Amateurs, Logistics Are For Professionals

“…implementation, not strategy, is what usually separates winners from losers in most industries, and generally explains the difference between success and failure in most organizational change efforts, sales campaigns and so on.

Cross Functional Teams Don’t Come Free

“Good communication is both hard and crucial for any organization. It is therefore imperative that we let communication be one of our guiding principles when choosing between the two variants.”

Convincing People

“Trust is a fluctuating resource. Everyone starts with a level of trust. Sometimes this can be negative (for example, criminals). Your interactions with others either increases or decreases the trust. The unfortunate thing about trust is that while it takes a huge effort to build complete trust, a single wrong move can totally deplete it. People have different trusting personalities, ranging from gullible to suspicious. And they may also (rightly) trust you differently on different subjects. For example, while they may accept everything you say on electronics, your advice on car maintenance falls on deaf ears.”

Does a Kanban System Eschew Estimation?

“So kanban teams do not eschew estimation simply because it is hard. Some teams choose not to estimate because they can realise the same benefits that estimation gives with a lower cost.”

I Signed the Oath of Non-Allegiance

Posted on July 18th, 2010 by Dennis Stevens  |  2 Comments »

I signed the oath of non-allegiance 300dpi.png

Alistair Cockburn, in the Oath of Non-Allegiance, has issued a call to action for the software development community to stop bickering and calling out contending methodologies. He has called for “discussion about whether an idea (agile plan-driven impure whatever) works well in the conditions of the moment.” As someone who has earned his PMP, CSM , received certificates from the Lean Enterprise Institute, and who completed David Anderson’s Kanban Coaching workshop – I have had the opportunity to see this bickering up close. I have occasionally even as the target of it.  Here is Alistair’s call to action:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

This is becoming an increasing familiar theme. We see it in Laura Brandeburg’s Business Analyst Manifesto. It is expressed by by Liz Keogh, Jean Tabaka and Eric Willeke in “A Community of Thinkers”. I am involved in a PMI Agile team where we are trying to make sense out of the benefits associated with bringing together the PMI Body’s of Knowledge (Portfolio, Program, and Project) in the context of Agile. I am working with the IIBA’s Agile Business Analyst core team to express the Business Analysis Body of Knowledge in an Agile fashion. I also participate in various Yahoo and Google groups where we are working at having these kinds of conversations involving Kanban and Lean.

These teams and discussion groups bring together practioners and thought leaders from various communities working to understand and to share. Sometimes the discussions get heated. You have a lot of successful, intelligent people sharing their experiences and trying to make sense out of their successes while simultaneously trying to expand their world view. The awesome thing is that there is a lot of learning and connecting going on in these communities.

You may want to protect your turf -  but this is the future. The tools and resources that support software development have improved orders of magnitudes in the last two decades. It’s crazy to believe we don’t have a long way to go to figure out the best ways to deliver software – especially at the enterprise.  Tom Peters quotes General Eric Shinseki, Chief of Staff, U.S. Army – “If you don’t like change, you’re going to like irrelevance even less.” I choose to join the community who is looking for ways to honor the fundamental premise of the Agile Manifesto – We are uncovering better ways of developing software by doing it and helping others do it.

Kanban, Mental Models, and Double Loop Learning

Posted on July 14th, 2010 by Dennis Stevens  |  1 Comment »

DoubleLoopLearningBack in September of last year I wrote about The Fifth Discipline and the Agile Enterprise. In that article I connected mental models and double loop learning with Agile. Mental Models are a way to describe a person’s intuitive perception of the world around them. How we act on that world, our decision rules, are based on  our mental models. In single loop learning, we may change our decisions, but we leave our underlying mental models and decision rule unchanged. In double-loop learning, we change our underlying mental models and decision rules to better serve us in the real world. I talked about how Agile, when done well, inspires us to explore our mental models and improve our decision rules. When our mental models go unexplored, we won’t change our decisions and so we won’t get new results.

Theory in Use and Espoused Theory

Recently, I have seen several references to Chris Argyris in the Agile community. Argyris is an American business theorist who developed a way of explaining organizational behavior called Action Science. In Action Science he describes two simultaneous mental models that make it difficult to create change in an organization. The first is our Espoused Theory. Our Espoused Theory describes the model we say we use to describe how we act (or how we would like others to think we act). Our Theory in Use is one we actually use to make decisions. From a personal standpoint, the Theory in Use is complicated for a number of reasons. It is shaped by how we are participating in the situation. I might respond differently to my brother (who I work with on clients) then I would respond to a client. It is shaped by the threat we feel in the situation. I might respond differently when the situation is under control then I do when I feel threatened. This becomes even more interesting when we are dealing with organization’s and changing the mental models that shape organizational behavior.  Making changes in the stories we tell about why we behave the way we do won’t change our decision. A key to making change is to intervene at the Theory in Use.

Model I-Inhibiting Double Loop Learning

Argyris tells us that when human beings deal with issues that are embarrassing or threatening, their reasoning and actions conform to a model called Model I. Trying to make change in a Model I organization is difficult because you are dealing with their Espoused Theory. It is neither rewarding nor safe for them to explore or actually change their mental models and decision rules – so there is a wide gap between their Espoused Theory and their Theory in Use. The defensive behavior in Model I organization’s create a vicious make this divide even greater. Model I organizations have the following values and supporting behaviors.

  1. Define goals and try to achieve them. Participants rarely develop mutual definition of purposes – nor are they open to altering their perception of the task. Participants plan actions secretly and  and manipulate others to  agree with a their definition of the situation.
  2. Maximize winning and minimize losing. Participants feel that once they have decided on their individual goals it is sign of weakness to change them.
  3. Minimize generating or expressing negative feelings. Expressing or permitting others to express feelings is a bad strategy. Participants unilaterally protect themselves.
  4. Be rational. Interactions are objective discussions of the issues.Participants withhold the truth, suppress feelings, and offer false sympathy to others.

Model I behavior results in organizational defensive behaviors that block exploring underlying mental models and the resulting maturity that arises. Most organizations exhibit Model I values and behavior most of the time.

Model II-Encouraging Double Loop Learning

Argyris describes a much more productive type of organization that he calls Model II. In a Model II organization, it is safe and rewarding to the participants to explore underlying mental models and decision rules. Model II organizations have the following values and supporting behaviors.

  1. Valid information. Participants design environments where accurate information is shared and underlying assumptions can be openly explored.
  2. Free and informed choice. The participants jointly control tasks and focus on collaborative problem solving.
  3. Internal commitment. The participants jointly protect each other in learning and risk taking. Mental models and decision rules are jointly explored.

Model II behavior results in organizational behavior that enhances underlying learning. High maturity organizations exhibit Model II values and behavior.

Kanban and Action Science

So, if we want double loop learning (and we do), we want to promote Model II values and behavior. That means we need to create an environment where:

  • valid information is apparent
  • it is safe to explore underlying assumptions
  • participants are actively involved in controlling their tasks and collaborative problem solving
  • the participants are focused on a bigger goal
  • we can compare the result of our change actions with the actual outcomes

Kanban explicitly creates this environment. The board, the tasks on the board, and the metrics make valid information readily available. The visualization of the work helps make it safe to explore underlying assumptions. You are no longer looking to cast blame, you are looking for an understanding of the system – it is depersonalized. The participants are involved in defining the board, the policies, and participate in problem solving on the board. The board and the focus on reducing lead time, reducing defects, and the policies changes the focus of the team to the bigger goal. Finally, the data available to us helps us make sure the improvements we attempt are achieved and sustained.

Kanban and Maturity

Chris Argyris’s intervention method for developing Model II behavior is simple. Map the system, internalize the map, test the model, invent solutions, intervene and study the impact. Kanban puts a simple, actionable model of this in place. Even better than the single cycle intervention model, the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.

Further Reading

Argyris, C. and Schön, D. (1996) Organizational learning II: Theory, method and practice, Reading, Mass: Addison Wesley.

Argyris, C. (1993) Knowledge for Action: A guide for overcoming barriers to organizational change, San Francisco, CA: John Wiley & Sons, Inc.

Kanban 101

Posted on July 13th, 2010 by Dennis Stevens  |  2 Comments »

Here is the presentation I gave the Agile Atlanta and to the PMI Professional Growth Event this month.