This article explains what a risk-adjusted backlog is, why they are useful, how to create one and how teams work with them.

What is a Risk-Adjusted Backlog?

A risk-adjusted backlog is a backlog that contains activities relating to managing risk in addition to the usual features associated with delivering value.

Agile projects typically prioritize the backlog based on business value or perceived needs. The Product Owner or business representative prioritizes the backlog elevating the highest value features to the top, so they get delivered first.

Taking an Economic View of Decision Making

Prioritizing based on business value is an example of the lean concept of 'Taking an Economic View of Decision Making.' In deciding which feature to develop first, those with the highest economic value are selected. Taking an economic view of decision making has a couple of advantages.

Project managers generally like plans and estimates so we can forecast when things should be done and how much they may cost. It helps manage client expectations and answer the type of questions they ask, such as "When will it be done?" and "How much will it cost?"

So, when project managers hear about ideas such as "let's stop estimating," it can trigger a knee-jerk reaction. It sounds lazy and avoiding the hard work of having to estimate. It can seem like people want to shirk their responsibility and accountability. First, those lazy agilists wanted to stop doing documentation; now they want to stop estimating too!

There has been a debate raging since 2012 about the use and value of estimates on agile projects. It has spawned the #NoEstimates hashtag, a website, a book and countless blog posts and conference presentations.

Like many radical ideas, when we dig into “no estimates” thinking, there are some good ideas, sound logic—and a whole heap of misunderstanding around it. This article sets out to unravel some of it.

Gray areas occupy the transition from one world to the next. Neither black nor white, predictive nor agile, project managers are increasingly finding themselves in the gray area of hybrid project management. This can make us feel uncomfortable since we are neither faithfully following either approach—instead living a compromise between seemingly different value systems.

We could get uncomfortable, guarded and hesitant to embrace the reality we face. Or, we could welcome it, use it to our advantage and share the benefits/trade-offs with anyone willing to listen. This second option of embracing, using and sharing is “playing in the gray area,” a term I learned at a recent workshop I was giving. It nicely summarizes the idea of accepting and making the most of our reality rather than uncomfortably accommodating it and mainly keeping it to ourselves.

Now that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

Let’s explore what you do and do not put in a backlog. How do these sound?

• Features and non-functional requirements – Absolutely
• Bug fixes and change requests – Yes, probably
• Risk avoidance and risk reduction activities – Sure, maybe
• Opportunity exploitation activities and marketing ideas – Now you’re just getting weird!
• Team building and social events – Erm, no!

Yet, if it’s all just stuff for the team to do, then why not put it in the backlog? Maybe because the customer has not asked for it and the product owner has to own and order it, but let’s look further.

If we used a backlog metaphor for prioritizing backlog work items. It may look like this.

I am not suggesting these are the correct elements for including in a backlog, I am just showing the common ones. However, I am probably getting too abstract too quickly. Let’s start at the beginning.

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

1. Concrete Experiences (What we already know)
2. Observation and Reflection (What our retrospectives help us identify)
3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know.

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead use “Lessons to be learned”.

I am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.

 

 

This article aims to dispel the myth that agile projects somehow magical manage risks for us, and outlines a couple of practical tools that can be used to start improving risk management approaches. 

Agile is Not a Risk Management Approach

Some people believe agile approaches with their short cycles and regular feedback have a risk management approach naturally built into the process. It is easy to see why, the building blocks and attachment points for plugging in an effective risk management process are certainly present, but unfortunately just building something iteratively or incrementally does not ensure risks are managed. 

It is all too easy to develop iteratively missing opportunities to actively address threats or exploit opportunities. Many agile teams also fail to actively look for risks, discuss and decide on appropriate actions, undertake those actions and reassess the risks and evaluate if the risk management process is even working. 

It is a shame because in many ways agile methods provide an ideal framework for introducing effective risk management practices. They have short timeframes, active reprioritization of work, frequent review points, high team member and business engagement in planning, etc. However, similar to having a group of people to help you find something, “a beach-party is not the same as a search-party”. We need a conscious effort, coordination and cooperation to make it effective.

 

Consciously Adding Risk Management to Agile Approaches

The good news is, that when organizations and their participating teams decide to layer risk management onto agile approaches there are many self-reinforcing cycles and mechanisms to make use of. For instance, the frequent consideration of change requests and reprioritization of work in the backlog makes the insertion risk avoidance or risk mitigation tasks an easier process to handle. 

Likewise, the regular retrospectives that review progress and process are great points to examine the effectiveness of risk management strategies and take corrective actions. Daily standup meetings that surface issues and blockers can also act as early warnings for potential new risks, etc. 

For anyone interested in linking agile approaches to risk management steps, here’s a White Paper on Collaborative Games for Risk Management that was presented at the 2012 Agile conference and PMI Global Congress. These ideas and their development more into Opportunity Management were explored at this 2015 Agile Conference Session. However, the mechanics of doing the work and linking it into an agile lifecycle are the easy parts, getting people to take a risk-based view to project work is where the real work is needed.

 

Thinking about Risk Management

Education and acceptance are the keys to successfully adding risk management to agile practices. We need to get people engaged in the process and instill a common understanding of threats as the possibility of negative value. Once people understand this they can answer the question “Where is the next best dollar spent?” more effectively. It might not be on building the next feature from the backlog, but instead avoiding a risk or exploiting an opportunity. 

Disclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.

To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?

Coding vs Collaboration Costs

The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.

Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?

Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve. 

So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.

Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?

The Compounding Costs of Delay

An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.

Benefits are why we undertake projects. Projects are expensive to undertake and have a risk of failure. So, we need to get benefits from them, or at least think we will get benefits from them, to start projects in the first place. Often the benefits of a project are not fully realized until after the project is finished. This is why benefits management is usually the domain of program management. Sitting a level higher than individual projects and operating over longer timelines, programs are better positioned to identify, track and transition benefits from individual projects or groups of related projects.

Agile approaches place strong emphasis on delivering business value. Work is prioritized with the highest business value items done early and definitions of “done” that focus on acceptance rather than completion of work help ensure benefits are truly delivered. This aligns them well for benefits tracking and management, but there is more to understand to truly integrate agile projects with effective benefits management.

First let’s take a peek at the established world of benefits management. The PMI’s Standard for Program Management has three program phases: 

 

1.   . Program Definition
2.     Program Benefits Delivery
3.     Program Closure

 

 These are shown below along with a breakout of Benefits Delivery steps:

It is interesting to note that sub-steps 2 and 3, “Benefits Analysis and Planning” and “Benefits Delivery” are iterative. So we can see, program management is focused on the iterative delivery of benefits; which is what agile is all about so why do agile teams often face challenges from traditional project managers and PMOs? 

 

Thick Sandwiches

This is an aside, but a repeating pattern we often encounter is something I call the “Thick Sandwich”. It describes the situation where workers want to do the right thing and executives and senior managers want business benefits, but placed between them is a layer of middle management who, while well intentioned, tend to obstruct common sense and efficient delivery. So, engineers want to be useful, sponsors want products, but project management as a discipline aims to bring order, predictability, measurement and controls tend to gum up the whole process. 

Middle managers and their processes are created to optimize the process, add rigor and controls, but often just hinder the process. Lean processes (including agile) run up against this often. Agile is well aligned at CMMI levels 1 (Initial), 2 (Defined) and 3 (Managed), it also perfectly aligns with CMMI level 5 (Optimizing) that focuses on process improvement but runs afoul on the documentation and controls layer of CMMI level 4 (Quantitatively Managed). Here again the well-intentioned layer of rigor and control can act as a value delivery inhibitor if we are not careful.

 

I am testing demand for another Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in attending a 3-day Calgary based PMI-ACP Exam preparation course. 

 

Evolution of the PMI-ACP Credential

I ran a couple of Calgary based PMI-ACP courses three years ago when the exam first came out. Since then the certification has grown in popularity from niche to mainstream with over 10,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

In October 2015 the PMI rolled out the updated version of the PMI-ACP exam, based on feedback from hundreds of existing credential holders and agile practitioners. The new Exam Content Outline has been restructured with the addition of a new domain “Agile Principles and Mindset” to focus on thinking and acting in an agile way as opposed to simply implementing agile processes and hoping for improved results.

 

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile methods such as Scrum and XP. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to restructure it to the new Exam Content Outline. The book is currently available for 30% off from RMC here and is also included in the course.

 

Details about the Course

The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking. It includes the second edition of my book, colour printed workbook, sample exam questions, and USB stick of additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.

Psst, this is your conscious, I am here to remind you about something you have thought about, but then hid away in the back of your mind. Lots of this agile stuff is hypocritical, it preaches evolution and change, but then we ask the same old three questions at standup every day. Also, why must we have standup every day, isn’t that kind of prescriptive? Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. With a free rein to morph product and process there is a strong likelihood that by six months into a project the practices followed by the team would have deviated from the proven and tested methods of most successful teams. The risk of failure would increase and every project in a company would be using a radically different approach making integration, scaling and team member transfers a major problem.

The other reason is a little more sinister. Most of the creators, proponents and promotors of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over.

I am not suggesting we should be changing agile methods willy-nilly, I think a basic suggestion to try them out-of-the-box for a couple of years is sound advice. However, beyond that I believe there are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that and what other people can learn from it.

Agile methods like XP, Scrum and DSDM have been advocating co-located teams in open plan offices now for 20 years. The idea being that since face-to-face communications are the fastest and most efficient, teams should be established to work this way whenever possible. Also, software projects, where agile methods started from, build intangible, often new and novel solutions to problems; as such there are lots of opportunities for miscommunication about how these new systems should look and work. Having people working together makes it easier to surface these misunderstandings, collectively troubleshoot problems and collaborate on new solutions.

However co-location is not always possible and open plan offices can suffer from “noise pollution” and frequent interruptions. The following infographic was created by a Voice Over Internet Protocol (VOIP) provider so probably has some selection bias, but importantly draws its findings from over a dozen respectable sources including articles from Bloomberg, The Guardian, the Wall Street Journal and Fortune.

How do we define quality as a project manager? Is it managing a project really well, or managing a successful project? How about managing a successful project really well, that sounds pretty good. However it poses the next question: What is a successful project? Let’s look at some examples of project success, failure and ambiguity.

 

Apollo 13
Apollo 13, the third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from astronaut, James Lovell (that is widely misquoted as, "Houston, we have a problem".)

The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing for future missions. Clearly, this was a remarkable achievement, but the original project goals were not met. Lovell now recounts this story at PMI conferences under the very apt title of “A Successful Failure”.

 

(Or how a picture can divert 1,000 eyes)

This post was first written for ProjectManagement.com who were doing a series on Visual Project Management at the time. I was excited when I heard about the theme since I am a big fan of adding meaning through visual tools to all kinds of project elements, whether it is methodology scope, project progress, or risk lists.  As a visual thinker I like to make sense of a concept spatially before adding detail or explaining it to others. Yet I have found this to be a weakness as well as a strength, because what cannot easily be visualized can often get trivialized or forgotten.

Plans and prototypes are great because they easily bring people together to debate and collaborate on important project elements. Since we have something to point at and annotate; discussions and agreements progress quickly because consensus making is greatly facilitated. However what about conflict management, decision making across teams, or business engagement issues? These are more difficult to visualize but arguably more important than if a web site should have a blue or a green background.

The idiom of “Out of sight, out of mind” speaks to the dangers of an overreliance on visual management.  So how do we address this threat? I believe there are two main choices: first, find a way to somehow make it visible, or second, consciously bring extra attention to it.

Another project saying “What gets measured, gets managed” might hold a clue to helping find ways to make things more visible. I think there are some parallels between the visible / invisible issue to the measurable / immeasurable issue. Many of the things we can measure on a project are not helpful and many of things we would really like to measure are intangible and difficult to measure. Einstein summed it up nicely with the quote “Not everything that counts can be counted, and not everything that can be counted counts”.

Do any of these traditional PMO scenarios match your agile team experiences? Your traditional PMO is so laughably outdated that most agile projects ignoring them; other projects produce token deliverables to appease them, but these bear little resemblance to anything actually happening on the agile projects.

The PMO looks for conformance to BDUF (big design up front) methodologies with signoffs to premature speculations about requirements and scope definitions. It reports progress on traditional projects such as being 75% through Requirements Gathering or 50% through Analysis and Design as if these non-value delivering activities are actual progress. Finally, when projects have issues the PMO responds by creating more review and approval groups to ensure competence and adds gates and sign-offs to try and improve quality.

If these scenarios sound familiar to you I would like to ask a follow-on question: How is your agile roll out going? Is the PMO the last bastion of opposition or are you fighting pockets of resistance and misunderstanding throughout you organization? Is the once “no-brainer” decision to switch to agile actually causing some headaches and frustration? If you answered yes to this too, you are not alone.

It turns out the PMO is not usually the problem, but they are a good litmus or canary-in-the-coal-mine for how an agile transformation is going. The PMO’s focus is project execution process, so if you cannot convince this group that agile is the way to go, then how do you plan to convince groups who don’t care about process at all? How about the BA Center of Excellence or the Architecture group, have they fully bought in to your agile approach or are they requesting more formal practices?

Getting the PMO onboard is helpful in convincing these other, more problematic groups that agile methods can be a better way of working. So how do we do that? Well making agile more accessible is a good start. PMO’s often shy away from agile methods since the short iterations and repeating cycles of work do not offer the familiar phases and gates they are used to. In fact interacting with agile team iterations seems as appealing as putting your arm in a spinning concrete mixer.

However we can make the process less daunting by showing how the user story and backlog process works. Take some required deliverable, like a handover document, and create a story for it. Give it to the team and along with a customer proxy (a Product Owner for instance) the story will get prioritized and placed in the backlog. Since it is required for Go Live the story will get selected and worked on by the team prior to the release date – all with PMO limbs intact.

 

Another point of confusion around agile methods for some PMO groups is the lack of a visible end point or meaningful progress reporting. They may wonder if iterations just repeat until the customer is happy rather than the specification is complete? Gaining visibility into the process can help by providing retrospective data to the PMO along with story points and feature metrics. By explaining the cadence of reviews and tracking metrics PMOs are assured progress is measurable and all the old favorites like Budget At Completion (BAC) and Schedule Performance Indexes (SPI) can still be obtained.

Helping the PMO helps agile adoption by creating another advocate group. It may be a surprise to some PMs and teams but PMO’s are under a lot of pressure to justify their existence and demonstrate their value add. They are usually very receptive to ways to stay current and support emerging practices.

Investing some time to train them in Product Owner training or Retrospective Facilitation pays dividends since now they can offer these new project services. Project teams will benefit from a more educated and aligned business community and gain impartial facilitators making it easier for all to contribute ideas at retrospectives.

Rather than unaligned PMOs representing an obstacle to agile teams, they really represent missed opportunities for further agile adoption and an indicator that the agile message might be miscommunicated to other stakeholder groups. Spending some time to address their concerns, explain the risk reduction goals of early feedback, and equip them with useful services will pay dividends and ease the larger adoption of agile and lean principles.

(I first published this artice at ProjectManagement.com here)

Even though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the true focus.

Just as Disney is all about manufacturing a positive visitor experience through detailed buildings, social engineering and extensive staff “character” training; agile methods are really about creating a social framework where effective work can be accomplished. This social framework will vary from project to project and enterprise to enterprise. It is a problem solving exercise like building a custom galley kitchen inside a boat not a standardization exercise like force fitting IKEA kitchen cabinets.

I realize that by using analogies to Disneyland and IKEA so early in an article many readers may assume I have finally lost the plot but after 20 years of practicing agile I have had enough with rote methods implementation and attempts to scale through process training that fail. To me agile is about process as much as Disney theme parks are about Mickey Mouse. Yes, they are an easily identifiable symbol, a short cut to identification, but far removed from what the real focus is.

In fact Mickey Mouse cartoons kind of suck and most people would be hard pressed to think of a good one. However, luckily for Disney that is not the point, their real goal is to capture imagination and allow people to explore fantasy environments while spending lots of money, hopefully as part of a pleasurable experience so they will come back and also tell their friends.

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

Sense making – agree information gathering steps and prioritize exploratory work

Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting

Conesus gathering - collaboratively gain consensus on direction, approach and decisions

Prioritization – build mindful to risk reduction and business value

Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates

Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings. Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail and it is like assessing a Disney theme park by asking “Does everyone have their Mickey Mouse ears?”

I am lucky to work with an agile team that has been together for 7 years. Not that it has taken us that long to finish a project, but instead the business sees the benefits of a high performing team and keeps bringing us new projects to undertake.

[The whole idea of bringing projects to established high performing teams could be the subject of another post . Instead of creating new teams per project and going through the Tuckman stages of Forming, Storming, Norming then hoping to get to Performing, using existing high performing teams bring many benefits.]

The team is the best I have worked with and won a PMI Project of the Year award for the first project they completed. Yet I cannot remember the last time we had a stand up meeting or retrospective. We dropped two week iterations in favor of a continuous pull of features and use cycle time in lieu of velocity or detailed estimation based on points or days. So is the team still agile? An outside observer looking for process or ceremonies might say No; I would say You Betcha! The team embodies the sense making, iterative, consensus driven concepts implicitly. Techniques like prioritization, results oriented reporting and empowerment are baked into every conversation and action.

It would feel weird to wait until the end of a sprint to discuss adaptation of process. In fact the notion of a sprint seems an artificially restrictive and wasteful construct to manufacture. Inter team communications are too important to wait for a daily stand up meeting and team members get an equal say in decisions and spend lots of time in healthy debate, both face to face and with remote team members.

The set up is not perfect and still has room for growth. We could do better at interacting with other groups and our tendency to “fly-under-the-radar” to avoid delays for approvals from other groups also means we miss opportunities to share success stories and spread effective practices to other departments as well as we could. Yet on the whole the group is very effective.

Skills acquisition is often described using the “Shu”, “Ha”, “Ri” progression. In this model new practitioners start with obeying the rules (shu, which means to keep, protect, or maintain), then consciously moving away from the rules (ha, which means to detach or break free), and finally unconsciously finding an individual path (ri, which means to go beyond or transcend).

My point is that agile is not process following. Success is not methods replication, it is not really gaining an agile mindset either, that’s too insular and individual; instead it is creating a working ecosystem for your environment. The ecosystem may have activities that could be labeled as “processes”, but true processes are designed to resist change, they are like robust pipes that force compliance on items that vary. Activities and behaviors are more open to change and support it where it makes sense.

There are some popular tests to gauge if a team or project is truly agile. The Nokia Test and the Scrum Test are good starting points but they still ask if ceremonies like daily stand ups and constructs like iterations exist. These questions miss the true intent of these practices and bring focus to the process. Yet the process is not important and may/should change over time as a team develops, or be adapted to better suit a client. So it is better to separate the process from the behavior we are really trying to assess.

The following questions do not dictate what process to use but look for signs of a healthy, productive project environment.

1. Does the business value what is being delivering and want to continue with the same group?
2. Is the team still improving and learning as it works?
3. Are the increments of delivered work frequent and of a high quality?
4. Is the project ecosystem healthy?
5. Is the system receptive to change?

Thinking of behavior and capability rather than process conformance will help organizations deploy and scale their agile adoptions. It might be easier to measure process adoption than underlying competency, but like associating Disney with Mickey Mouse it is not really about the process.

[I first published this article at ProjectManagement.com here]

On May 5^th I will be presenting at the PMI-NAC Conference on the following topics:

1. 21^st Century Risk Management: Supporting mathematical analysis with social influence
2. PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches

I am looking forward to the event and will share thoughts and feedback on the sessions here afterwards. Until then here are the presentation outlines:

Presentation 1: ”21^st Century Risk Management: Supporting mathematical analysis with social influence”

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence.

While the project manager is key to project co-ordination and success, they are rarely the domain experts and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management and the importance of social influence on risk management. Using case studies, a team approach to risk management to collaborative workshops, new risk visualization techniques, and examples of team risk avoidance and risk mitigation actions are examined.

Presentation 2: ”PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches”

Agile, lean and kanban approaches are a part of the new project delivery toolkit, especially for projects with IT components. The PMBOK Guide v5 published in January 2013 now describes a lifecycle spectrum spanning “Predictive, Iterative & Incremental and Adaptive” approaches. The new “Software Extension to the PMBOK Guide” expands this model with further agile related guidance for project execution.  Gartner Research claims 80% of today’s software projects employ agile methods. So, is your PMO living in denial, or simply living in the past?

Fortunately, a new class of PMO has evolved to support a dynamic mix of traditional, agile and lean project approaches that we can learn from. Using case studies from award winning PMOs, this presentation examines how proactive organizations are tracking diverse project types with common metrics and enablers.

I have had a busy autumn and it has been too long since I posted here. I did some consulting in Europe and attended the PMI Global Congress in New Orleans to present on “21^st Century Risk Management” with Dennis Stevens.

More recently our local PMI Chapter won the “Chapter of the Year” award and held their excellent Professional Development Conference that I gave a couple of presentations at. The first on “PMO Evolution: Frameworks for Integrating Lean, Agile and Traditional Projects” and one on “Surviving Agile Projects” aimed at traditional project managers transitioning to manage their first agile project.

The consulting and conference interactions led to a number of ideas for application on agile projects that I will be sharing here in upcoming posts. At our local PMI conference in Calgary last week Bob Lutz, Retired Vice Chairman of General Motors Corporation gave a great talk on design and project management.

He was discussing the importance of defined, repeatable process for efficient, high quality production. Strict compliance and rigorous process controls certainly help improve the manufacturing process. What was interesting was his cautions about applying defined, repeatable processes to design work. He said it flat out does not work and can lead to terrible products.

Bob recounted how upon rejoining General Motors in 2001 he asked “Who the hell designed the Pontiac Aztek?” (which appears on many Top 10 worst car design lists and is generally slammed from a design perspective – although liked by some loyal owners.) The Pontiac engineers were very defensive claiming that in fact the design of the Aztek was one of the best executed vehicle design projects that had run, hitting each of its targets and assessment milestones during the process. Lutz went on to say while some processes need rigour, design processes need collaboration, feedback and frequent verification to ensure we are on the right track.

As we execute our projects I think there is great value in determining if we are designing something or manufacturing something. The creation of software solutions is like car design, we are trying to understand the problem space and create candidate prototypes for evaluation and evolution towards the best available solution. This requires collaboration, feedback and frequent verification.

Other projects like upgrading servers and training 500 people are more defined, repeatable activities that can benefit from well defined process and strict controls. Most projects I have worked on have elements of both work types mixed together. An important skill for project managers is to know when to employ strict process and when to encourage less structured collaboration where designs evolve based on build-feedback cycles.

I really enjoyed Bob’s talk; he is an engaging speaker who tells things as he sees them and I look forward to reading his latest book “Icons and Idiots”. Over the coming weeks and months I intend to post here more frequently and continue the dialog on the smart application of process and pragmatism.

It may not always be apparent but the goals of the Project Management Office (PMO) and agile teams are well aligned. Both groups want to get to the same destination: namely successful projects and happy stakeholders. However, things often come adrift as soon as the best direction to travel in to get there is discussed. The PMO might expect lots of planning and some documentation to confirm everyone understands the approach. An agile project team might want to build some proof-of-concept models to test feasibility and get confirmation of understanding. So, very quickly the two groups can disengage and have difficulty generating alignment again.

This is one reason agile teams don’t always see the Project Management Office (PMO) as a source of assistance. All too often a traditional PMO can Present Multiple Obstacles, but it does not have to be that way.

First let’s examine what PMO’s are supposed to do. The old roles of: “Rules”, “Tools” & “Schools” goes some way to describing their functions, but a more complete set of offerings was provided in the 2010 PMI Project Management Journal article “Identifying Forces Driving PMO Changes”. These are:

1. Monitor and control project performance
2. Develop and implement standard methodologies, processes, and tools
3. Develop the competency of project personnel, with training and mentoring
4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
5. Strategic management, including participation in strategic planning and benefits management
6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
7. Management of customer interfaces
8. Recruit, select, and evaluate project managers
9. Execute specialized tasks for project managers (e.g. preparation of schedulers)

  For organizations using agile methods, these services can be delivered as follows:

1. Monitor and control project performance – Help teams track their velocity. Assist with tracking team and sponsor satisfaction ratings. Look out for and alert teams of dangerous velocity trends, check backlog size, and offer reviews of iteration and release plans.

2. Develop and implement standards – Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.

3. Develop personnel with training and mentoring – Provide agile training courses, coaches, and mentors to help project mangers transition to agile projects and upgrade their skills. Send people to local agile events.

4. Multiproject management – Coordinate between agile teams, communicate between projects including items such as outlining progress, issues and retrospective findings. Help manage Release Trains at the program level and Investment Themes at the portfolio level using frameworks like the Scaled Agile Framework (SAFe).

5. Strategic management – Identify projects with opportunities for early ROI or competitive advantage.

6. Facilitate organizational learning – Gather project velocity profiles, capture, store and index retrospective findings. Include perceived PMO cost vs. value in project metrics.

7. Manage Stakeholders – Provide Product Owner training, guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of Subject Matter Experts (SMEs) to projects.

8. Recruit, select, and evaluate project managers – Develop guidelines for interviewing agile project managers.

9. Execute specialized tasks for project managers – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.

Understanding the role of a PMO and translating the goals into an agile setting helps create alignment rather than conflict between the groups. These items may sound a tall order for your average old-school PMO. However PMO’s are under pressure to remain current and demonstrate their value in a climate of fast moving projects, cost cutting and increased scrutiny.

In the September 2009 PMI Community Post magazine Jack Duggal published an article called “Teaching PMOs to DANCE” that dealt with the issue that many of today’s projects are moving quicker than PMO’s can respond. Many PMO’s struggle assisting projects that DANCE:

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

The agile community calls projects like these “a good fit for agile” and this is the synergy. When we can explain agile approaches are not just non-conformist, ill-planned projects, but instead a proven approach for these tricky new project types then a win-win is possible for both camps.

Jack Duggal also gave a presentation at the 2011 PMI Global Congress entitled “Reinventing the PMO” which was quite agile manifesto like. Jack outlined a need for PMO’s to shift:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough. PMOs need to cultivate a mindset to shift to a benefits and outcomes focus and establish measures to ensure benefits realization and achievement of business value.

2. From Delivery to Adoption and Usability
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted. With a shift to an adoption and usability mindset, PMOs can promote and plan for adoption throughout the project lifecycle to ensure intended realization of projects’ benefits and value.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Change management in the PMO realm has focused on configuration management and procedural changes. Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation. PMOs can play a key role in understanding, leveraging and leading change.

The “Next Generation PMO” as Duggal names it will have a mindset viewing the organization as a complex adaptive system. The PMO’s purpose becomes more focused on linking tactical & strategic help with business value. Success will be measured via benefits realization and business value rather than project delivery. All of which are very much aligned with agile concepts.

So, rather than PMO’s being unsupportive of agile, I have found most to be very co-operative when alignment with agile helps them address challenging projects, deliver value and stay current. Also as project managers experienced in agile take roles in the PMO I think this transition will accelerate. With some education and buy-in a good PMO can Provide Many Opportunities for agile teams.

(This article first appeared at projectManagement.com here)

My next PMI-ACP Exam Preparation course will be November 18, 19, 20 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book).

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To reserve your place or ask questions please contact [email protected].

Professional athletes watch slow motion video of their performances to find areas for improvement. Armed with this information they can then work on these weaknesses and improve their performance. When studying for an exam how do you objectively measure your skills acquisition and areas of weakness that need to be worked on? Practice tests can help, especially if the questions are categorized into knowledge areas so we can tell which topics candidates understand and which they need more work on.

As a trainer I am also trying to get feedback from the group on whether people understand what I am talking about. I ask them of course, using questions like:  “Does this make sense?”, “Are there any questions on this?”, but I never really know. Cultural norms vary considerably, do polite nods and no questions mean am I preaching to the choir and they know all this stuff already, or they just don’t want to ask questions?

I recently started incorporating audience response systems (clickers) into my training courses, and while no silver bullet, they do provide useful objective feedback. I introduced them so that participants on my PMI-ACP Exam Prep course could answer end of module practice exam questions and get personal reports of how they did to help their study plan.

However the benefits go further, as a trainer I can poll the group with a quick question and if everyone gets it right move right along. Like Fist of Five voting a quick confirmation allows us to move efficiently, but if there is confusion or division of opinion then we can investigate and go deeper into topics. No longer do I have to decide if blank stares mean consent or incomprehension of my accent, now I have some hard data.

It allows for some fun games too, like prizes for most right answers, fastest responders, fastest correct responders, etc. Obviously leader boards just show the top 3 or so people, it is counter productive to show the lower part of ranked lists.

Using these tools we can provide detailed individual analysis of question responses that would otherwise require invasive supervision. Not only which categories did you score the highest and lowest on, but which questions you took the longest to answer, or changed you mind on the answer to select. This meta data helps target follow up studying for participants and also provides me with some useful feedback as I teach.

I used the system live for the first time last week in Bucharest, Romania and will be using them again for my Calgary course next week.

Certifications and the tests that accompany them can be stressful. If there was a quick, ethical way of increasing your test scores while reducing anxiety would you take it? – You should do!

Research into test anxiety, its impact on test performance, and strategies for intervention that were published in Science, 2011 offer some valuable tools for boosting performance.  It turns out there is a 10 minute exercise that has been found to significantly boost performance. Here is an excerpt from the research paper:

 “Two laboratory and two randomized field experiments tested a writing intervention exercise designed to improve students’ scores on high stakes exams… The intervention, a brief expressive writing assignment that occurred immediately before taking an important test, significantly improved student exam scores, especially for students habitually anxious about test taking. Simply writing about one’s worries before a high-stakes exam can boost test scores”. So, especially if you get nervous about important exams, this is a great tool for improving performance.

Returning to the Science paper: “Studies have shown that when students feel an anxious desire to perform at a high level they worry about the situation and its consequences. These worries compete for Working Memory (WM) available for performance. WM is a short term memory system involved in the control and regulation of a limited amount of information immediately relevant to the task at hand. If the ability of WM to maintain task focus is disrupted because of situation-related worries, performance can suffer. Writing may alleviate the burden that worry places on WM therefore improving performance." 

This is a somewhat counterintuitive idea given that drawing attention to negative information typically makes it more rather than less salient in memory. However in the experiments, ninth grade students were randomly assigned to an expressive writing or control condition immediately before the final exam of their high school career. Students spent 10 minutes either sitting quietly (control group) or engaged in expressive writing. The expressive writing group were asked to write as openly as possible about their thoughts and feelings regarding the exam they were about to perform. 

Control participants choked under the increased pressure, scoring  on average 12% lower than earlier test scores; whereas students who expressed their thoughts before the high pressure exam showed a significant 5% improvement on their pre-test scores.

This is a great improvement, from -12% to +5% under stressful conditions. The researches wondered if writing, regardless of content, distracted students’ attention from the situation and thus benefited performance. So they did another experiment where one group was asked to write about anything they liked and the other group did the same expressive writing about the consequences of the exam. In this experiment the unrelated writing group showed a 7% drop in performance from pre test to final test, whereas the expressive writing group showed a 4% increase in performance this time.

So, it is not just writing that does the trick, making a shopping list or drafting your project’s next status report is not going to help you. You have to actually think and write openly about the exam. How do you feel about it? What would happen if you fail? Who would you need to tell? How would people react at work? All the gritty stuff we may be telling ourselves not to think about, that’s exactly what we should be writing about to free up as much working memory as possible.

It seems Working Memory capacity is key for answering questions and is eroded by anxiety. Exercises like 10 minutes of expressive writing could be very useful tools for improving performance. Facing your fears and documenting them will unload them from Working Memory giving you more to solve problems with.

Test are bad enough, but if you are one of the 40% of people that suffer from test anxiety, that panic of “Argg, I have forgotten it all!” this 10 minute exercise could be just the ticket. You should be arriving at the test center in plenty of time anyway, just in case there is traffic or delays. So use that wait time effectively to your advantage.

Note: This article first appeared on ProjectManagement.com here. Bio: Mike Griffiths is the author of “PMI-ACP Exam Prep, Premier Edition: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam” and enjoys helping people understand and pass project management certifications.

My PMI-ACP Exam Preparation course will be April 15, 16, 17 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at Fort Calgary which is close to downtown on 9^th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book). To reserve your place or questions please contact [email protected].

Continue reading to see further details from the Course Outline

In the future how will agile methods be remembered by the project management community?  It seems history has a way of distorting the facts and simplifying concepts out of context. Here are a few examples:

1)    In the original Waterfall Software Development Process paper written by Winston Royce in 1970, after presenting the lifecycle diagram on page two, the author states “I believe in this concept, but the implementation described above is risky and invites failure”. Royce then spends the remaining nine pages outlining feedback loops and “Do It Twice” recommendations since there would be things missed in the first pass through. Read in its entirety, it outlines a fairly robust, risk tolerant approach to building systems that features multiple iterations and opportunities for learning and adaptation.

Yet, waterfall is thought by many to be a single pass lifecycle with all the associated problems. It is as if the project management community latched onto the lifecycle diagram depicted on page two and chose to ignore all the more difficult to implement yet critical steps described in pages 2-11. Read the original Waterfall paper here.

 

2)    Henry Gantt’s project management research and work actually focussed on retrospectives, diagnostics and optimizing work flow. Yet people remember him for the Gantt chart. The funny thing is that he did not even invent what we call the Gantt chart today; that was Joseph Priestley 100 years earlier.

Gantt’s charts were far more complex diagrams that were created after the work was completed and then used to identify waste and improve the process. While he started with scientific management of Fredric Taylor, his research went far beyond charting and optimizing labor. He was a harsh critic of ineffective management and promoted many Lean and Theory of Constraint like values such as “Increased production not through speeding up workmen but by removing the obstacles which prevent them from doing their work”, “Reduced costs, because of the elimination of idleness and waste as well as improvements in process”, “Men interested in their work not only because of the wages but because they have an opportunity to increase their knowledge and improve their skills.

 We often characterize Gantt with tracking charts, but that’s a faulty summary of a talented systems thinker; for more information on Henry Gantt, his real charts and work see Henry L Gantt 1861-1919 Debunking the Myths.

 

3)     The Manhattan project is often attributed as the origin of modern project management and phase gated approaches, however it actually pursued concurrent development. The Manhattan project to develop a nuclear bomb in the 1940s, certainly displayed the modern project management principles of organization and planning, but also high rates of trial-and-error and multiple parallel streams attempting to solve the same problem.

There was just so much uncertainty surrounding how to create a bomb, knowledge was theoretical and incomplete. The project manager, Leslie Groves, said: “The whole endeavour was founded on possibilities rather than probabilities. Of theory there was a great deal, of proven knowledge, not much. There was simply no ready solution to the problem we faced.” So, Groves and his steering committee decided to explore and implement different solutions in parallel. This approach (well multiple approaches) and willingness to modify and add solutions mid-course, led to technical breakthroughs that had been thought impossible by most three years before.

This was 30 years prior to Toyota’s “Set based engineering” but very similar in its pursuit of multiple parallel approaches. Yet today we most often hear of the Manhattan project as the birth of the phase gate approach, this is too bad, they did so much more.

 

4)     Lastly, the Polaris project that was attributed as the origin of Critical Path Method (CPM) and PERT was actually about gaining First-To-Market intellectual property share.  The Polaris project developed the first submarine-launched ballistic missile (SLBM) carrying nuclear warheads. These offensive weapons, almost impossible to track and attack, became a key element of nuclear deterrence.

The Polaris project is today credited with developing the “scientific approach to project management” with the first large scale application of computerized planning techniques, particularly CPM and PERT. A big part of the project was about “getting a share of the ballistic missile pie” away from the newly formed US Air Force that was receiving most of the Pentogon’s money. Admiral Burke astutely believed that “The first service that demonstrates a capability for this is very likely to continue the project and others may very well drop out”. The result was a clear prioritization of schedule over cost and specification; and a willingness to experiment and change specifications over the course of the project.

Trial and error led to two deployed tests in the early 1960’s and PERT served “…less for improving project control than for offering technological pizzazz that was valuable in selling the project. (Since) The image of efficiency helped the project. It mattered not whether parts of the system functioned or even existed, it mattered only that certain people for a certain period of time believed they did.” For more information on the fascinating truth of the concurrent development, experimentation, iteration, and adaptation that really underpinned the Manhattan and Polaris projects see Lost Roots: How Project Management Settled on the Phased Approach (and lost its ability to lead change in modern enterprises).

 

So, given waterfall was iterative, Gantt focused more on the theory of constraints not Gantt charts, the Manhattan project was Lean not Phase Gated, and the Polaris project was about rapidly gaining mindshare through iteration, I don’t really hold out much hope for agile methods to be remembered accurately in the future.

The glass half-full view of these history lessons shows that smart, resourceful people have been tackling complex project problems for centuries and our ideas such as lean-startup, Kanban, behaviour driven development, etc are likely not new.

The glass half-empty view is that agile methods will be erroneously summarized to tangential concepts,   such as “individuals without tools”, or “leave no documentation”. However, smart people will continue to be successful in managing challenging, audacious projects and terms are really just labels that matter less than the methods they describe or results they enable.

Maybe we have better collective knowledge these days and we will not repeat the same erroneous summarization and labeling of take away ideas. Lenfle and Loch, the authors of the “Lost Roots…” paper, assert that the loss of trial-and-error and strategy-making focus from popular project management, that was clearly present on these early projects, restricts the usefulness of project management today. Agile and lean approaches rediscovered this science and are attempting to merge it back into mainstream project management, but are up against a generation of resistance from those who were taught projects can plan out variability.

From an evolutionary perspective it is an encouraging sign that techniques that were lost through poor reporting have re-emerged elsewhere to exploit project environments that have high levels of uncertainty. Regardless of their names or origins, let’s hope they persist and get incorporated in mainstream project management, not to be lost again.

This article first appeared in ProjectMangement.com here. Bio: Mike Griffiths is a project manager experienced in traditional and agile methods who reads about project management much too much - you really don’t want to get stuck with him at a party!

The Project Zone Congress will be taking place in Frankfurt, March 18-19. I attended the Project Zone Congress last year and was impressed by the quality of sessions and access to speakers for Q & A. This year’s conference is set to repeat the format and has some great speakers including Jurgen Appelo author of “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. I love this title and wish I’d come up with it myself!

Readers of LeadingAnswers can receive a 10% discount from the conference by using the code “PZ2012_MEDIA03B869C8” when they register. It promises to be a high caliber conference with sessions on practical agile, the PMO and agile, strategy and leadership, see the schedule for full details.

It is well known that teams work best when they are empowered to self-direct and given freedom to self-organize. Yet striking the balance between providing this autonomy with responsible project oversight to ensure things do not go off track can be a tricky proposition. We want to create empowered teams, but we also need to know if the project is going awry and when to intervene. Unlikely as it sounds, but a great source for creating empowered team environments can be found in the prescriptive process of PRINCE2.

Edwards Deming, a major inspiration for Toyota’s lean approach, said there were two classic mistakes a manager can make. The first is intervening when common cause variation occurs. Common cause variation is the natural variance we see in process. For example some three day tasks will take four days to complete and this is just the way things are – common cause variation, managers need to accept the odd instance of this. The second classic manager mistake is not intervening in special cause variation, which is variation that is new, unanticipated, emergent or previously neglected. For example if project scope changes significantly (new and unanticipated) or velocity trends indicate the project will not get done within schedule (emergent).

So what we really want is a protective bubble for the team that insulates them from micro-management and outside interference – like a giant hamster ball, and also some guard rails and an occasional guiding hand to keep the giant hamster ball on track towards the project goals. I realize that picturing high-performing teams as hamster balls sells them short in terms of their intelligence, insight, commitment and dedication, but it fits with my guide rails metaphor. I was going to use the analogy of a state or province governed by its own local laws, but overseen by a government or federal body. It can self manage for most things, but not revolt, declare war on outside groups, or change direction. However my time living in Canada has taught me this metaphor is as likely to upset just as many people so let’s leave it open – a hamster ball run by the hamsters or a state/province governed locally, you choose - to many people they are not that different.

 As project managers we need to establish the boundaries for our team’s independence within which we have control over how we operate (definitions of common cause variation) and the mechanisms for detecting going off track (indicators of special cause variation).  This is where a concept from PRINCE2 can help. When starting a PRINCE2 project we establish Project Tolerances and Exception Processes. These set the boundaries within which the project manager / team can control project variation and what circumstances trigger an exception and escalation to a steering committee or project board.

Tolerances are established at the beginning of the project, agreed with project stakeholders and written into the project charter. They can be created for a variety of metrics such as time, budget, scope, risk, quality and represented as a simple range such as the budget tolerance as shown below:

 

There are three components to the Tolerance / Exception process: 

1. The Tolerance Range – the acceptable range within which the project manager (and team) get to operate without outside intervention.
2. An Exception – a breach of tolerance (exit from a tolerance range) that triggers the escalation process.
3. The Escalation Process – an agreed process that describes who will be contacted and what actions will be taken should an exception (breach of tolerance) occur.

In the figure below we can see that the blue spend line has exceeded the Projected Budget +10% upper tolerance range and so an exception is raised as per the escalation process for this measure.

Tolerances can be also be more subjective such as a sponsor confidence score and tracked, say, monthly or bi-weekly.

For an agile project, all this talk of documentation in a project charter can sound like more procedural overhead than we want to get into. Plus, scope may not be fully defined and so a more emergent process may be suitable for an uncertain project.  Yet we can take the tolerance idea and recast it in a lighter weight version, with appropriate metrics for an agile setting.

While there may be a less formal charter, most projects get launched with some approving document or discussion. Whether this is a project vision document or a kick-off meeting, this is the time to establish the team’s autonomous environment. Then, providing the project is on track (velocity and spend are OK, demo’s are showing progress, business is happy with quality and engagement) the team is empowered to self-organize provided no tolerances are breached or forecast to be breached.

By discussing the bounds of self-governance and describing what would trigger an exception stakeholders are more likely to let the team self-manage safe in the knowledge that provisions for being alerted are in place. The process of discussing tolerances and agreeing the escalation process allows teams to gain autonomy which improves morale, increases performance, and creates a virtuous cycle. As opposed to suspicious oversight that micro manages, leading to demotivated teams, and a self-fulfilling prophecy of skepticism.

Times of issue escalation are not the best moments to establish resolution processes, since people are concerned and emotional. Like having an evacuation plan for a building, if an event occurs when you need to use it, you want it already established rather than having to make it up during a real fire. The same goes for projects, it is much better to have an escalation process in place and then just execute it “We said we would convene a committee meeting if average velocity indicated we would not get all the “Must Have” work done with remaining funds. This is where the current projections show us and the options we have are… ”. This is preferable to having to invent some new process in the midst of a project issue.

Agile tolerances can be created around most observable measures that the project community cares about. They can be internally facing such as defect cycle time, that might trigger some special retrospective focus.

 

Or externally facing such as User Satisfaction that could trigger a steering committee meeting..

The real point is that borrowing a process such as Tolerances, Exceptions and Escalations from PRINCE2 actually creates more freedom for teams to operate. Agile teams spend a lot of effort agreeing on a common definition of “Done”, by spending a little time to build a common understanding of “Concerned” we can all go faster knowing consensus on the definition and resolution process is in place.

Of course it is no silver bullet; on PRINCE2 projects we sometimes call the tolerances how much rope we give the project manager. Too much and they can hang themselves, too little and they are always coming back with approvals for minor adjustments. So, like everything it has to be applied intelligently, yet it can be a useful tool to have in your toolbox when starting up a project and looking to strike that balance between buffering stakeholders from common cause variation and alerting them to special cause variation. Autonomy creates freedom for the team to perform, while tolerances provide assurances to concerned parties who might otherwise be tempted to interfere too much.

(This post first appeared on www.ProjectManagement.com here)

As a PM, what is the most effective thing you can do for your project in the next hour? (After finishing this article, of course!) I would suggest speaking to your project team members and business representatives about where their concerns lie and what they believe the biggest risks for the project are. The reason being that while tarting up a WBS or re-leveling a project plan might be familiar and comfortable (where you are a master of your own domain), it really amounts to nothing if your project is heading for trouble. Like rearranging deck chairs when you should be looking for icebergs, there are better uses of your time.

The frequency and magnitude of IT project failures are so prevalent and epic that people can appear in denial of their ability to influence, or “in acceptance” that a certain percentage of projects just go south. Does it need to be that way? If we spent more time asking people where stuff could go wrong rather than making ever more polished models of flawed project plans, could we change the statistics (even a little bit)?

According to research by Roger Sessions of ObjectWatch, 66 percent of projects are classified as “at risk” of failure or severe shortcomings. Of these 66 percent, between 50 and 80 percent of these projects will fail. So, if 66 percent of projects are at risk, let’s say 65 percent of these projects will fail; that’s .66 x .66, meaning 43 percent of projects fail. (Despite the grim projection, these numbers are actually slightly better than the Standish Chaos report findings). What would happen if we could prevent just, say, 5 percent of those from failing?

The impacts would be huge, because the amount of money spent on IT projects now is truly monumental. Of all these failing projects, there must be many that flirt on the edge of success versus failure--wobbling between being able to be saved and past the point of no return. These are my targets--not the doomed-from-the-start death marches to oblivion but the appropriately staffed, well-intentioned projects that just don’t quite make it. I bet there was a point in the path to failure when some more dialogue around risks and issues could have provided the opportunity to take corrective action.

The trouble is that we don’t know if we are on an ultimately successful or unsuccessful project until its path may be irreversible. So we need to be acting as if we could be heading for trouble at regular intervals. We should also examine the economics behind this suggestion to change PM behavior. How much is it really worth to maybe sway the outcome of just 5 percent of the projects that are headed to failure?

According to The New York Times, industrialized countries spend 6.4 percent of the GDP on IT projects. Of that, 57 percent typically goes to hardware and communication costs and 43 percent to software development. Of these, 66 percent are classed as “at risk” and 65 percent of them ultimately fail. The cost of failed projects is two-fold: There is the direct project cost, but also a series of related indirect costs. These include the cost of replacing the failed system, the disruption costs to the business, lost revenue due to the failed system, the disruption costs to the business, lost opportunity costs, lost market share and so on.

An investigation into a failed Internal Revenue System project showed a 9.6:1 ration of indirect costs to direct project costs. For our purposes, we will use a more modest ratio of 7.5:1. Let’s see how these figure pan out:

So it turns out that the failing SW projects cost the world about $6 trillion dollars annually, and over $1.3 trillion in the United States alone. That’s a chunk of change, and saving just the 5 percent of projects wobbling on the edge of failure in the States would amount to $1,336B x 0.05 = $66.8B (or $1.28B per week).

How do we do it? Well, socializing the problem is a start. Let’s talk about project risks more often and raise them from the clinical world of reviews and audits up to the more human, approachable world of predictions and wagers. Ask team members to predict why the project may fail or get stuck. Ask our sponsors where they think the biggest obstacles lie. Follow up with “How do we avoid that?” and “What would have to happen to prevent that?” type questions, and follow through on the recommendations.

Just the act of discussing these issues can influence behavior. Armed with knowledge of where the really large icebergs are, people tend to steer and behave differently. To reiterate, we are not trying to prevent all project failures; just keep an extra 5 percent on track through frequent, honest dialog about the issues and a broader stakeholder awareness of the major project risks is a great way to start. So what are you waiting for? 

(I wrote this article first for Gantthead, here )

 

This is the last post in a series on agile risk management. The first looked at the opportunities agile methods offer for proactive risk management, while the second examined the benefits of engaging the whole team in risk management through collaborative games. The last instalment walked through the first three games covering:

1. Risk management planning
2. Risk Identification
3. Qualitative Risk Analysis

This month we look at the final three sets of collaborative team activities that cover:

4. Quantitative Risk Analysis
5. Risk Response Planning (and Doing!)
6. Monitoring and Controlling Risks

The exercises we will examine are

• Today’s Forecast -- Quantitative Risk Analysis
  • Dragons’ Den -- next best dollar spent
  • Battle Bots -- simulations
• Backlog Injector -- Plan Risk Responses
  • Junction Function -- choose the risk response path
  • Dollar Balance -- Risk/Opportunity EVM to ROI comparison
  • Report Card -- Customer/Product owner engagement
  • Inoculator -- inject risk avoidance/mitigation and opportunity stories into backlog
• Risk Radar -- Monitoring and Controlling Risks
  • Risk Burn Down Graphs -- Tracking and monitoring
  • Risk Retrospectives -- Evaluating the effectiveness of the risk management plan
  • Rinse and Repeat -- Updating risk management artifacts, revisiting process

Last month we looked at how agile methods provide multiple opportunities for embracing proactive risk management. The prioritized backlog, short iterations, frequent inspections and adaptation of process map well to tackling risks early and checking on the effectiveness of our risk management approach.

We want to overcome many of the correct-but-not-sufficient aspects of risk management seen too often on projects:

    Poor engagement - dry, boring, academic, done by PM, does not drive enough change
    Done once – typically near the start, when we know least about the project
    Not revisited enough – often “parked” off to one side and not reviewed again
    Not integrated into project lifecycle – poor tools for task integration
    Not engaging, poor visibility – few stakeholders regularly review the project risks

This month’s article extends risk management beyond the project manager role and introduces the benefits of making it more of a collaborative team exercise. Next week we will walk through the team risk games one by one.

First of all, why collaborative team games? Just as techniques like Planning Poker and Iteration Planning effectively make estimation and scheduling a team activity and gain the technical insights of engaging people closer to the work. So too do collaborative games for risk management; after all, why leave risk management to the person who is furthest from the technical work – the project manager?

"...why leave risk management to the person who is furthest from the technical work – the project manager?"

Before I upset project managers worried about erosion of responsibilities we need to be clear on what the scope is here. I am advocating the closer and more effective engagement of the team members who have insights into technical and team related risks. I am not suggesting we throw the risk register to the team and tell them to get on with it. Instead we are looking for better quality risk identification and additional insights into risk avoidance and mitigation, not the wholesale displacement of the risk management function.

So why should we bother to engage the team? Why not let them get on with doing what they are supposed to be doing, namely building the solution? Well there are some reoccurring problems with how risk management is attempted on projects. Most software projects resemble problem solving exercises more than plan execution exercises. It is very difficult to separate out the experimentation and risk mitigation form the pure execution. Team members are actively engaged in risk management every day. We can benefit from their input in the risk management process and if they are more aware of the project risks (by being engaged in determining them) how they approach their work can be more risk aware and successful.

The benefits of collaboration are widely acknowledged, a study by Steven Yaffee from the University of Michigan cites the following benefits:

I picked up a copy of my PMI-ACP^SM Exam Prep book on a visit to RMC Project Management over the weekend. It was good to see it printed up for the first time, and with all the exercises and 120 sample exam questions, it was thicker than I expected at over 350 full-size pages.

The extra weight also comes from the case studies of agile projects I have worked on over the years and the additional materials I included to link the exam topics together. These items that are not in the exam are clearly marked so you can skip over them if you want. However, I am sure some people will find they add value by making the ideas more real. These additional materials also supply useful information to allow readers to fully understand the topics, rather than just memorize the information for the exam.

I am very grateful to the staff at RMC for pulling together my thoughts and ideas into this book, and for the people who reviewed it. Alistair Cockburn and Dennis Stevens were particularly helpful, and after reviewing it, they wrote the following quotes for the cover:

“As one of the authors of the Agile Manifesto, I am delighted to see this book by Mike Griffiths. It is great that such an exam guide was prepared by someone with a deep understanding of both project management and Agile development. Personally, I hope that everyone reads this book, not just to pass the PMI-ACP exam, but to learn Agile development safely and effectively!”

– Dr. Alistair Cockburn, Manifesto for Agile Software Development Co-Author, International Consortium for Agile Co-Founder, and Current Member of the PMI-ACP Steering Committee.

“This is a VERY enjoyable book to read, due to Mike's firm grasp of the underlying concepts of Agile, and his articulate and entertaining writing style. My favorite part is the fact that it is organized into a framework that helps all of the Agile concepts hang together, so they will be easier to recall when taking the PMI-ACP exam.

But Mike's book is more than just the best PMI-ACP prep book out there. It is also the best consolidated source of Agile knowledge, tools, and techniques available today. Even if you are not planning on sitting for the PMI-ACP exam in the near future you need to buy this book, read it, and keep it as a reference for how to responsibly be Agile!”

– Dennis Stevens, PMI-ACP Steering Committee Member, PMI Agile Community of Practice Council Leader, and Partner at Leading Agile.

Thanks to you both, working with you over the years has been a blast. I would also like to thank the visitors of my blog here, too, for reading my posts and submitting insightful comments that kept me motivated to write. RMC has provided me a limited time promotion code that gives readers a further $10 off their currently discounted price for the book. If you follow this link and enter promo code “XTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.

By Mike Griffiths

“My team has stopped talking to me, and I like it!” This may sound like heresy since agile teams are centered on face-to-face conversation, but as with most sound-bites it is missing context and clarification. A more accurate description would be: “We are replacing some face-to-face conversations with other communication channels and this practice seems to improve flow.”

Like all good stories I have started in the middle, let’s back up and examine the full picture. “Flow” is the quiet and highly productive state of work when you are really “in the zone” and making real progress on a topic.

In the book “Flow: The Psychology of Optimal Experience” Mihaly Csikszentmihalyi explains what makes an experience genuinely satisfying and how people typically experience deep enjoyment, creativity, and a total involvement in their work when in this state of flow.  We experience flow when work is challenging enough to provide a reward of problem solving yet not too crazy difficult that it is frustrating. So, not too easy, and not too hard, but a perfect “Goldilocks” rating of “Just-Right.”

Shimon Edelman, a cognitive expert and professor of psychology at Cornell University, offers some insight in his book “The Happiness of Pursuit: What Neuroscience Can Teach Us About the Good Life.” He explains it this way: “Flow is the enjoyment derived from being engaged in an activity that is challenging, but not frustratingly so. Evolutionarily, we are selected for being good at certain kinds of things. You’re not challenged if you’re not tested, we get rewarded incredibly with this feeling of well-being and excitement.”

Enjoyment and Productivity are self-reinforcing factors that give rise to high performance.

The befits of flow on productivity are so significant Tom DeMarco and Anthony Lister in their book “Peopleware” recommend designating two hours a day as “Quiet time” with no meetings or interruptions. Programmers need sufficient quiet time to get into this productive mode, and as Alistair Cockburn observes, it takes only a minute or two of other conversation to disturb it.

This is the flow / communication paradox, on the one hand we want to get to a state of flow, on the other we want a collocated team environment with lots of high bandwidth, face-to-face communications to get questions answered quickly. There have been a few suggestions strike to balance . In the “XP Applied: Playing to Win” book Ken Auer suggest the “Caves and Common” idea. Caves are quiet rooms to work in, Common is the common work area where we learn via osmotic communication and get our questions answered quickly. People can go an work in the quiet “caves” when they need to focus and return to the common area to share and learn when they are done that high concentration task.

Why my team has stopped talking to me, is because they now use instant messaging. So instead of them coming over and asking a question mid way through my angry birds, status report, instead I get a little pop-up at the bottom right hand side of my monitor for me to reply to. The key difference is that this is not so interrupting as having someone physically come over. I can continue with my chain of thought, reach a convenient checkpoint and then type a reply.

Working this way flow seems to be less interrupted, it is no longer a cold reset of re-establishing where I was in my work and getting back into the groove, the interruption was less obtrusive and flow returns quicker. Perhaps because we decide the exact moment when to reply, allowing us to reach a better checkpoint/return point.

When team members who sit 6 feet away started sending me messages rather than talking to me I dismissed it as the poor communication skills of today’s younger workers, the product of text messaging generation, and generally a cop-out of having a meaningful conversation.

Now I realize that many quick questions are not worth the flow interruption penalty of a full face-to-face conversation. So items do however, if we think there is a problem, or need for a direction change then a full stop and discussion is exactly what is required, but for perhaps 5 times as many questions an electronic ping gets the answer without the interruption of flow.

I am not disputing the advantages of face-to-face communications, we will always benefit from the emotion and body language we lose electronically. However, given the value of flow and being in that productive zone, if we can keep that speed going for longer with less disruptive questioning, perhaps the overall business value delivered can go up with fewer face-to-face interruptions?

Likely this is very environment dependant, some projects will be constrained by their rate of learning and more face-to-face communications would help. However other projects, or perhaps the same project at a later phase, could be constrained by productive flow and better served by less intrusive Q&A. Balancing flow and feedback will always be dynamic.

What do you think, does technology help us here in balancing flow with being informed? How are you managing these competing demands? I would love to hear alternative solutions to this widespread issue.

(Note: This article first appeared on Gantthead.com here)

SMEs, SM0s and the Deluded Developer Day

We all want Subject Matter Experts (SMEs), but what happens if we get a Subject Matter Zeros (SM0s)?  How does that impact your schedule, and what about team members who have “other project commitments”? Before you know it, that 6 month schedule that looked pretty comfortable, is looking like a fairy tale.

I recently attended a great presentation by Lee Lambert at my local PMI conference and while he was not talking about agile per say, his commentary on SMEs and part time resources struck a chord, which I would like to share.

The role of the customer, the business, the Subject Matter Expert (SME) on agile projects is vital. They not only help provide requirements, but also clarify details, validate prototypes, perform UAT, tell us about business changes, articulate the goal, prioritize, the list goes on. Great SMEs are like great multi-disciplined developers who can do BA work, architecture, development, and QA – they can just make projects happen. It is rare to get these mythical beings, but I have been fortunate to work with a few.

More commonly we work with SMEs with limited time who have a preference for one or two areas of work, such as providing requirements or testing increments of software. We obviously want the best SMEs we can get, but the best people are always busy since they “get-it” and can crank out work – so who wouldn’t want to engage them?

When SMEs are not available we can assign proxy customers, where perhaps a BA plays the role of the customer, or we get someone more junior from the business who may be less experienced in the role than ideal. These are just the realities of working in companies today and as the Rolling Stones said, “You can't always get what you want, But if you try sometimes you just might find, You get what you need”. When this happens we just need to be sure we understand the consequences to our schedule.

The other factor is team member availability, ideally this is 100%. This makes face-to-face meetings easy, resource leveling a breeze, and a one day task often does actually get done in one day, imagine that! “You, you may say I'm a dreamer, but I'm not the only one”, many project schedules are planned this way even when commitments for support and other projects take availability from the project.

Overall Task Duration is dictated by the productivity of our resources along with their availability, as follows:
So if a task was estimated at 8 hours (one day) for our SME & Dev combo, but we did not get the SME we wanted and instead got a SM0 who, lets optimistically assume is 50% as productive as our SME. Also the developer is not 100% committed to the team, but split across 2 projects and also providing production support for those projects, then their true availability for new development on our project might be only 25%.

Using these figures for our 8 hour task we get: 
This result can be surprising, we instinctively knew it would take longer since the business involvement was not perfect and the developer had other work, most PMs factor in 3-4 times longer, maybe 5-6 times, but it is rare for the full 8 times longer to be properly incorporated.

This is why ideas like Yesterday’s Weather (gauging performance based on previous results) and measuring team capacity via Velocity are often better predictors of completion rates.  The other point it illustrates is the impact and significance of suboptimal resources and non-dedicated participants.

As always the best time to influence project durations and success factors is when selecting the people for the project. It is a too easy to overlook the true impact of a few small compromises and not properly explain the consequences that then accumulate to make projects late. We can use the Task Duration formula to illustrate this or rely on the Beatles “Help, I need somebody; Help, not just anybody, Help…”.

 

Bio: Mike Griffiths is a project manager who seriously needs to update his music collection. He has served on the board of the Agile Alliance and the APLN. Mike is a contributor to the PMBOK v5 Guide, the Software Extension to the PMBOK Guide, the PMI Agile CoP, and the PMI-ACP Steering Committees.

 This post first appeared in Gantthead.com here.

I will be presenting on “Smart Agile Metrics” at the upcoming Calgary Agile Methods User Group (CAMUG) meeting Tuesday January 10th.

Here is the outline:

“Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. The accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.”

This is a favourite talk of mine that I presented many times, just never for CAMUG before. I have written this post on some of the concepts in the talk. The event is free to attend and hosted at the University of Calgary. I am looking forward to seeing some familiar faces and meeting some new people too, I hope you can make it along if you are in the area.

Location:  ICT Building Room 121
Time:       6:00-6:30pm Snacks,
                6:30-7:30pm Presentation

CAMUG Website

I have been away attending the excellent “Agile on The Beach” conference recently, but when I returned I had an email waiting requesting some PMI-ACP study help on Value Stream Mapping. So here is quick outline of the topic.

Value Stream Mapping – is a lean manufacturing technique that has been adopted by agile methods. It is used to analyze the flow of information (or materials) required to complete a process and to determine elements of waste that may be removed to improve the efficiency of the process. Value stream mapping usually involves creating visual maps of the process (value stream maps) and progresses through these stages:
1)    Identify the product or service that you are analyzing
2)    Create a value stream map of the currant process identifying steps, queues, delays and information flows
3)    Review the map to find delays, waste and constraints
4)    Create a new value stream map of the future state optimized to remove/reduce delays, waste and constraints
5)    Develop a roadmap to create the future state
6)    Plan to revisit the process in the future to continually tune and optimize

To illustrate lets optimize the value stream for buying a cake to celebrate passing your PMI-ACP exam with a friend. Let’s say this involves choosing a cake, waiting at the bakery counter to get the cake, paying for the cake at the checkout, then unpacking and slicing before enjoying the benefit of the process (the cake).

"Calling Hallelujah Always Offends Someone"

I am glad the PMI is finally recognizing agile methods, Ken Schwaber recently posted about the PMI Agile Certification, saying that he “…welcomes this and looks forward to PMI shifting from its previous approach to an agile approach. The test of this will be, of course, the success of the projects that adhere to its principles. In the past, the success (or yield) of their predictive approach has been less than 50% of projects (on time, on date, with the desired functionality.)”

He was quoting from the Standish CHAOS Report that comes out every couple of years and documents the success and failure rates of IT projects. The CHAOS reports have been published since 1994, the same year DSDM appeared and when many agile methods were getting going. Each year the results vary slightly, but the general theme is that many IT projects are challenged and results like the following are typical:

    * 32%   Successful (On Time, On Budget, Fully Functional)
    * 44%   Challenged (Late, Over Budget, And/Or Less than Promised Functionality)
    * 24%   Failed (Cancelled or never used)
    * 61%   Feature complete

It is interesting then that Ken attributes the poor success rates of IT projects since the start of agile to be a PMI problem. You would think that with the rise of agile methods and the success of all these Scrum, XP, FDD, and DSDM projects we hear about, that these statistics would have turned right around!

Malcolm Gladwell (author of Blink and Tipping Point) was in town a couple of weeks ago and I enjoyed a great presentation he gave on what happens when we think we have complete information on a subject.

The Problem
Gladwell asserts that the global economic crisis was largely caused by “Miscalibration Errors”. These are errors made by leaders who become over confident due to reliance on information. Those in charge of the major banks were smart, professional, and respected people at the top of their game; who, as it turns out, are prime candidates from miscalibration errors.

People who are incompetent make frequent, largely unimportant errors, and that is understandable. They are largely unimportant errors because people who are incompetent rarely get into positions of power. Yet those who are highly competent are susceptible to rare, but hugely significant errors. 

Think of the global economic crisis where bank CEOs were seemingly in denial of the impending collapse of the sub-prime mortgage market. (I don’t mean close to the end when they were secretly betting against the market while still recommending products to their clients, but earlier on when they were happy to bet their own firms on “AAA” rated derivatives that they knew were really just a collection of highly suspect subprime mortgages.)

Anyway, this phenomenon of educated, well informed leaders making rare, but catastrophic errors is not new and unlikely to go away soon, it seems to be a baked-in human flaw. When presented with increasing levels of information our perception of judgement accuracy increases when in reality their judgement may be very suspect. Let’s look at some examples:

Part 2 of my article on Agile contracts has been published on Gantthead.com. Part 1 reviewed the existing agile contract samples from the DSDM Consortium that speaks to “Fit for business purpose” acceptance criteria and “Passing Tests” rather than meeting specifications. Part 1 also examined the CoActivate Community sample Fixed Price agile contract and Jeff Sutherland’s suggestions on early termination and functionality swapping.

Part 2 highlights some of the ideas Jesse Fewell presented on agile contracts at the PMI Global Congress last year. These include Graduated Fixed Price and Fixed Price Work Packages as building blocks for creating agile contracts.

Clearly these contract options are not panaceas to possible engagement woes, but they do offer some examples of how organizations and suppliers have been able to utilize the flexibility of agile for mutual competitive advantage. 

The next occurrence of my Agile Project Management class will be in New Orleans on February 28 and March 1st (Feb 18 Update: and is now full ). After that there is:

Savannah, GA - April 11, 12
Dallas, TX  - October 26, 27
Anaheim, CA - November 7,8

I enjoy delivering these courses and people enjoy attending them too, here are some feedback comments:

"Mike delivers an exceptionally well reasoned and effective presentation of agile. Thoroughly appreciated" - Bill Palace, El Sugund, CA
“The best PMI class I have ever taken.” - Scott Hall, Marriot International
"This was a very well executed course. Instructor (Mike Griffiths) was very engaging!" – Ameila White, Boeing
"The instructor was very knowledgeable, class well organized, content at the right level of detail and very comprehensive. One of the best classes I have taken regarding PM topics" – James Bernard, Scottsdale
"Excellent course with great information" – Tom Gehret, JNJ Vision Care
"Excellent facilitator. Mike is respectful and knowledgeable" - Nghiem Pauline, San Diego, CA
"The course was fantastic " - Kimberly Kehoe, San Diego, CA
"Mike is an excellent instructor and I really appreciated his organized and clear, well researched presentation. His domain and project management experience is evident from his talk. Also I appreciate his exposure/experience to multiple approaches like PRINCE2, PMBOK, Scrum, DSDM etc." - Sarah Harris, OpenText
"Great content and delivery" – Andrea Williams, Fed Ex
"Great Stuff!, Really enjoyed instructor and real-world examples" - Don Brusasco, Northridge, CA
"The instructor did an excellent job of keeping the pace, - clearly explaining topics and providing practical applications" - Cathy MacKinnon, Schering Plough Corp
"Excellent!" – Peter Colquohoun, Australian Defence

All of these classes sold out last year so if you want to attend I suggest you book early; I hope to see you in New Orleans!

 
So you think you know agile? Well then why not take the Agile Star Quiz and find out if you are really an agile star or more of an information black hole. The questions in each category start out easy, but get harder. Score yourself either manually with the answers shown below or use the attached Excel Agile Star Quiz and scoring model spreadsheet to generate your agile star graph scores.

History
1)    The Agile Manifesto was created at a meeting at:
     A) A rugby match, Auckland, New Zealand, February 2001
     B) A ski resort in Vail, Colorado, February 2001
     C) A ski resort in Snowbird, Utah, February 2001
     D) The OOPSLA software conference, 1999

2)    The last three “Agile 20xx” North American agile conferences have been held at:
     A)  2010 Orlando, 2009 Chicago, 2008 Toronto
     B)  2010 Nashville, 2009 Salt Lake City, 2008 Toronto
     C)  2010 Salt Lake City, 2009 Orlando, 2008 Washington D.C
     D)  2010 Orlando, 2009 Chicago, 2008 Washington D.C

3)    Who published the statement “Software development should be done incrementally, in stages with continuous user participation and replanning”?
     A)  Kent Beck, 1997
     B)  Harlan Mills, 1976
     C)  Ken Schwaber, 2001
     D)  Jeff Sutherland, 1995

This was a regional competition, not the national one, but I am really pleased to report that the IPS project I managed for the last 3+ years won the PMI-SAC Business & IT “Project of the Year” award at last week’s PMI Gala and Conference.

The Integrated Pipeline Solution (IPS) manages about a third of Canada’s heavy oil transportation. While you may think tracking oil moving through a pipeline sounds pretty simple, like anything, the devil is in the details. Husky has about 30,000km of pipeline and complications such as blending products, forecasting production, optimizing capacity, custody transfers, billing, accruals, etc and the fact that billions of dollars are at stake mean that the rules, regulations and complexity adds up pretty quickly.

We had an amazing team and engaged, savvy business representatives – these were the real reasons for success, not the methods we followed. However, there were lots of challenges too and our approach helped us here. We “inherited” the project $1.1M behind budget after an outsourced vendor doubled their estimate following a year of analysis. They were asked to leave and the project was brought in-house, but with no adjustment to the original budget.

Agile methods excel at fixed budget projects providing the sponsor is willing to flex functionality. This is what occurred and we actually ended up delivering more functionality that originally scoped within the initial budget.

The PMI Awards assess projects on a variety of criteria and asks for submissions in a specific 10 page format. I will spare you the 10 page version and instead list a quick summary of the benefits:

• Enhanced Business and IT relations – against a backdrop of varying degrees of business / IT co-operation, the project stood out as an example of completing a long and challenging project through close cooperation. The stakeholders were practical and pragmatic about decision making and priorities. The increased trust built on this project has been useful for launching subsequent projects.

• Business Benefits – the business benefits of creating a single, integrated pipeline system are numerous. User configurable calculations, better data quality, faster calculation speeds, and improved reporting are just some of the tangible benefits.

• Improved resilience and support – The IPS project moved the Pipeline group from a set of unsupported, legacy systems to a new platform of state of the art .Net and Oracle 11g solutions. User developed spreadsheets with questionable data integrity were also replaced.

• Project Objectives met – The project delivered all the requested functionality within the defined project schedule. This functionality was delivered to a very high level of quality, and while there have been some changes and minor fixes since April 2010, there have been no production outages. The project finished just under the $6.1M budget frozen in 2006 despite having to incorporate late breaking business changes in 2009.

Agile methods are best suited for small projects. Women are not suited for extreme endurance events like marathons and ultra (beyond marathon) races. Oh, how conventional wisdom seems ludicrous after being proven wrong time and time again.

“The heresy of one age becomes the orthodoxy of the next.” - Helen Keller

I have been doing more trail running this year, and some ultras. It is great to see the sport is not male dominated and many events are won outright by women. Before the 1980s, there were no women's distance races in the Olympics at all; 1,500m was the furthest race distance allowed for them. Before 1972, women were barred from the Boston marathon and most other marathons.

Pam Reed beat all the men in the Badwater 135-miler two years in a row. Local girl Ellie Greenwood, often beats all the guys in her ultra races. Scientists believe women may metabolize fat more efficiently than men for better fuelling and that estrogen may delay mental weariness. I just know there are lots of ponytails passing me on the trails, and am good with that.

As women go from being thought of as too frail to run marathons to kicking major butt in ultra marathons, so too do agile methods. First described as “light weight” and only for small, co-located teams, we are now seeing more and more use of agile methods in truly huge, distributed, complex projects.

At last year’s Agile Business Conference in London I learned about Nokia’s massive agile roll-out where 1,800 software developers are using agile techniques to develop the Symbian mobile phone platform. This immensely complex endeavour is tightly coupled to quickly evolving hardware, divergent phone standards, and a variety of different cell providers worldwide. Using a variant of Dean Leffingwell’s “Agile Train” approach they are scaling agile to tackle a very complex domain and produce rapid, high quality results.

At this year’s PMI Global Congress last week Richard Spires CIO of the Department for Homeland Security (DHS) spoke about his role overseeing $6.5 billion of IT focussed spend annually. He has 91 projects greater $50M in his portfolio. So, how does he and his team manage it all? “With more and more adoption of agile methods” he said. It is the only way to keep up with the complexity and high rates of change required for this massive portfolio of projects.

Agile started small, and this is still my recommendation for companies looking to adopt it, but do not limit its application or growth there. Command and control structures get heavy and slow to change as they scale up. The weight of the control system seems to over burden the operation of the functions. Perhaps the lighter weight of agile methods can actually be an asset to solving truly huge projects by not smothering operations as they expand?

I think we will be seeing more accounts of ultra sized agile projects in the future.

Back in 1994 when we were defining DSDM, I remember our experiment of getting the user community engaged in the application architecture. (Not a successful experience!) It was at Data Sciences in Farnborough, UK and we were working on a project for a government client called ECGD. Following ideas from Enid Mumford on Participative Design we were testing how far the benefits of closer business engagement went and discovered a limit.
 
For us at least, having the business closely engaged in scope discussions, screen designs, and planning was extremely positive, but having them engaged in our architecture sessions was a net negative experience. They leapt to implementation ideas, disregarded IS strategy, and did not know enough about the architectural issues to be helpful in the discussions. We got frustrated, they got frustrated, and no body seemed better off.

So we discussed it with other DSDM Consortium members and agreed business involvement should not extend to architecture. The DSDM framework was updated and we carried on with our experiments and evolution of the method. For me this was a transformational moment, it was my first time of witnessing a failure and adaptation of a process within DSDM and how we learn and adapt. We just changed the methodology; there was no sacred cow, just good old scientific experimentation.

Business involvement in GUI design: Good
Business involvement in architecture design: Bad.
Therefore, involve them in GUI design, but not in architecture.

If you don't like
What you got
Why don't you change it?
If your world is all screwed up
Rearrange it

The PMI is calling for volunteers to help write and shape PMBOK v5 Guide Link. Here is your chance to inject more recognition and support for agile methods. I was involved in The PMBOK v3 Guide rewrite and got two small changes accepted in 2004 when agile methods and the PMBOK were hardly being talk about and I was a bit of a lone voice at the party.
 
If you don't like what you see
Why don't you fight it
If you know there's something wrong
Why don't you right it
 
Since then the tides have changed and now the PMI Agile Community of Practice is the largest and fastest growing PMI community. In the last PMI Network Magazine sent to members there were two full articles on Agile project management. Of the PMI’s 340,000 members an estimated 65% are in IT and the demand for agile guidance that has proliferated in other disciplines of IT (development, analysis, QA) is very apparent to the PMI, who need to serve their members.

In the end it comes down to your thinking
And there's really nobody to blame
When it feels like your ship is sinking
And you're too tired to play the game

For the last 25 years I have been learning about high performing teams and trying to create high performing teams. Well, I finally got to work with one for 3 years solid and I totally loved it.

For the last 3 years I have been working on the IPS project at Husky Energy with the best team and project I have experienced or reviewed. More of a program than a project, we rewrote a number of legacy pipeline control and billing systems in .NET and removed a clutter of spreadsheets and Access applications that had sprung up to fill the gaps left by difficult to upgrade legacy systems.

I had worked with great people before, I have seen the difference good executive support, and engaged business representatives make. However, as the cliché goes, when you bring them together, and add enough freedom to make big changes, the result is much more than the sum of its parts.

Why So Successful?
Freedom to reset and redo - This was a project restart. After several unsuccessful attempts to kick-off the project and then a failed experience with a vendor to out-source it, the project was brought back in house and restarted. I was fortunate to join at a time when management was open to fresh approaches. Already $1M behind budget and 2 years delayed, we were able to introduce changes into an organization receptive to hearing new ideas and changing process.

Executive Support and Business Champion – These terms “Executive Support” and “Business Champion” are often just titles, mere names or nouns. For our project they were verbs that described their everyday jobs. The sponsor fought to retain our budget during cut backs, the business champion repeatedly went to battle to retain resources, gain exceptions from harmful processes and ensure we had access to the very best business resources.

An experienced, pragmatic team – Most of them had “been there and done that with pure agile”, they had seen the benefits and costs associated with pure TDD, XP, and Scrum. They knew all the theory and had heard the theological debates and just wanted to work now. They were exceptionally strong technically, with mature use of design patterns and layer abstraction. Mainly experienced contractors and some experienced full time staff, humility was high and ego’s low.

Great domain knowledge – We had an insider, an architect from some of the original systems we were replacing on our team. The bugs, the flaws, the big chunks of tricky logic from the original systems could all be highlighted and explained rather than rediscovered, a great time saver.

Embedded with our business users – Being away from the IT group and in with the business was critical in learning their day job and building rapport. By seeing their business cycles, busy days and deadlines we were better able to plan iterations, demos and meetings. Being face to face and sharing a kitchen helped with conversations and quick questions too.

Right Process – Way behind our people’s influence on success was our process, using a relaxed interpretation of agile, we worked with two week iterations, daily stand-ups, user stories, and empowered teams. Given we were replacing existing required functionality it meant prioritization and detailed task estimates were less valuable. From a perspective of minimizing waste we naturally gravitated to do less story point estimation and lighter iteration planning sessions. It was reassuring to hear David Anderson in 2008 talking about Kanban and viewing estimation and iteration rigour as waste. We were not just being lazy; we needed a certain fidelity of estimation for planning, but beyond that got diminishing returns.

The Outcomes
High Productivity - The last release contained over 1400 function points that were developed in one month by 6 developers. This is approximately 12 function points per developer per day, over three times the industry average and other releases had similar productivity. This was despite the domain being complex, we had a full time PhD mathematician SME (subject mater expert) on the team to define and test the linear programming, and iterative calculations being used.

This article summarizes my “Lessons Learned in Project Metrics: Are your Metrics Dumb or Smart?” presentation. It covers the following six topics

 

2010 is shaping up to be a good year for training courses and events. I have the following public enrolment courses available through the PMI.


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

 
My private courses are available year round, see here for a list and course outlines, and I am also hoping to head back to Alaska this summer to teach a class for the PMI Alaska Chapter there again.

As normal I’m keeping the bulk of the summer free to take full advantage of the short, but fantastic hiking and mountain biking season we get here around Calgary. I was hoping to attend the Agile 2010 Conference in Nashville, but the dates August 9-13 clash with the TransRockies Mountain Bike Race August 8-14 that comes right through my backyard of Kananaskis and is too good to pass up.

Instead of the Nashville agile conference, I hope to attend another agile conference in the fall, perhaps the Agile Business Conference in England again, or a Scrum Gathering event. Then of course there is the PMI Global Congress conference in Washington, DC in October. With the PMI Agile Community of Practice now the largest PMI community with >1700 members there will be a large Agile contingent attending and many great agile sessions to go to. Once again so many events and so little time!

On February the 16th I will be presenting at the Calgary Software Quality Discussion Group. This was the first group I presented for when I moved to Calgary nearly 10 years ago and I am very happy to go back and talk about a topic I really care about: Project Metrics. I care not in the sense that I think they are fantastic, instead I care because I think the majority of common metrics are counter productive and misguided. Here’s the outline:

Lessons Learned in Project Metrics - Are Your Metrics Dumb or Smart?


Collecting and reporting effective metrics can be a tricky business. Einstein captured it well when he noted "Not everything that can be counted counts, and not everything that counts can be counted".

Software projects have a history of measuring irrelevant and even counter-productive progress tracking metrics. The "Hawthorne Effect" should teach us that we will influence what we measure, yet companies continue to overtly track things like hours worked and lines of code written, unaware that they send the message of valuing long hours over results, and discourage simplifications and healthy refactoring. Quite often the metrics we want to track are intangible and subjective and so people tend to shy away from them.

More fundamentally, why are we even tracking these metrics? Is it to report on what has already occurred or help steer our future course? Often an imperfect view of the future is more useful than a perfect view of the past. In the real world, rear-view mirrors are much smaller than windshields for good reason, yet the accuracy of hind-sight and our attraction to certainty often creates too much of an emphasis on lagging, already occurred measurements compared to leading metrics. So we get fancy graphs of project spend and defect rates, but no better insights into what we should be doing differently in order to meet our goal.

In this presentation I will review many common project metrics and explain why they are largely misguided and counter productive. An alternative set of "Design Factory" metrics will be presented that are "simple and relevant to the true project goal", these metrics leverage the Hawthorne effect and focus on leading metrics to support smarter decision making.
 

Registration Link

As we start 2010, the second decade of the 21st century, project managers really should be embracing 21st century technologies and approaches. While developers and other project members have been benefiting from improved communication and collaboration via new technology in the last 10 years, project managers have been slower to adopt them.

The plus side of being a late adopter is that most of the kinks get ironed out before you experience them and all the features you may need have probably already been developed. So, time to get with it. Perhaps it can be a New Year’s resolution to at least examine these tools and approaches if you are not already using them on your projects.

The World Has Changed – Why Haven’t Your PM Tools and Approaches?
In the last 10 years many changes have occurred in the world of managing IT projects, yet we still see the same tools and approaches being employed. Is this because they are classic and timeless? Are the traditional PM approaches so successful that they do not need to be dragged here and there following trends and immature technology fads? No, I fear it is more that people are creatures of habit, and the usually more mature project management community, are worse than most at evaluating and adopting new approaches.

Also, project management is a largely individual activity, teams of developers and business analysts are far more common than teams of project managers, so peer-to-peer learning and tool support is almost nonexistent for project managers. Plus, project management can often be a reputation based market and to some people fumbling around as a beginner in a new approach is very uncomfortable to them. Well it is time to get over it, this is how we learn anything, and if you are concerned about looking foolish, just imagine how foolish you will look when everyone else has moved with recent trends and you are in the last stand of dinosaurs.

My last post was on modifying Parking Lot Diagrams to use the area of boxes to show the relative effort of differing parts of the system. The idea was that while traditional Parking Lot diagrams are a great way of summarizing progress at a project level, the customary approach of giving all the feature groups the same size box may lead people to believe these chunks of functionality are of equivalent size or complexity.

In the boxes below, the number in brackets describes the feature count, but this requires people to read the numbers and then consider the relative sizes. My goal was to create a new graphical summary that depicts the relative sizes via box area to make the summaries easier to understand.

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

In the second example we can quickly see the relative estimated sizes of the areas of work, with for example, “Enter Order Details” being three times the size (in area) of “Create New Order”. In this example to keep things simple, I am using feature count (15 vs 5) to depict effort and area. Most projects will use development effort in points or person days as the scaling factor.

Anyway, I have been using these scaled Parking Lot diagrams on my projects for a while, created quite laboriously in Excel and PowerPoint, and I was hoping that someone with better skills than I have could help me streamline the process. Well, in typical fashion, soon after posting I learned that:

A)    I may be asking the wrong question
B)    My invented solution has already been done before and far more elegantly
C)    It has been done on the Simpsons

Oh, the joy of the internet! Actually this is of course a great thing and now I can progress from a much firmer foundation, and far quicker than my slow evolution was taking me...