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!

I am pleased to announce / preview the first public offering of my new 3 day PMI-ACP Exam Preparation course. This is my second generation PMI-ACP Exam Prep course, with new content and updated material based on a year’s worth of feedback from my PMI-ACP Exam Prep book. Participants will receive a copy of my book (or a discount if they already have it). The structure mirrors the book flow, providing in-depth explanations, examples and new sample questions for all the material in the PMI-ACP exam.

The course will provide the 21 Contact Hours of training required to take the exam and uses a small class size format so everyone’s questions can be answered. The first course will be held in Calgary in the April / May timeframe with full details and pricing to be announced soon. If you are interested in receiving further announcements contact [email protected] to be added to the mailing list.

An outline of the course can be viewed here.

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)

This is the first article in a series on Agile Certifications, Career Advancement, Exam Prep and Advanced Learning I am writing for www.ProjectManagement.com that I will also post here.

Many people believe agile methods and certifications are like oil and water. One is a context-sensitive, adaptive framework; the other is a prescriptive, rigour-based measurement model. Certifying agile methods is like trying to bar-code clouds – a misapplication of quantification in a domain that resists it.

Yet, if the research organizations are to be believed and Gartner’s predictions of agile being used in 80% of software projects, there are a large group of people doing it. Whenever an in demand skill exists in the workforce a few things happen:

1. Hiring managers and recruiters want a way to screen and identify potential skilled applicants
2. Individuals want certifications to recognize their skills and knowledge within a domain. (Both to promote themselves for career opportunities and for personal development.)
3. Organizations want roadmaps for employee growth and career development.

Certifications help address these needs. Of course certifications do not guarantee competency, job suitability, experience or even knowledge. They are not substitutes for interviews, background checks, or references, but they are a tool frequently used to pre-screen candidates before these activities occur.

Most people realize that certifications are neither evil nor silver bullets; they are instead an inevitable side effect of a maturing integration of agile into the work place. Future articles in this series will examine the value of certification and pitfalls of certification, but to begin with let’s get an appreciation of the popular agile certifications available, focussing in the project management space.

Certified Scrum Master – CSM is probably the most widely held agile based certification. Starting in September 2012, passing a multiple choice test is now required to be awarded the CSM designation. Up until this date the CSM was awarded to everyone who successfully completed a two day CSM training class.

If your organization uses Scrum then a Scrum based certification makes sense. The number of Scrum related certifications and offering bodies has exploded in the last couple of years. It is now possible to obtain Certified Scrum Master, Certified Scrum Practitioner, and Certified Scrum Developer designations, amongst others from the Scrum Alliance. Also available are Professional Scrum Foundations, Professional Scrum Master, and Professional Scrum Developer from Scrum.org and Scrum Master Accredited, Scrum Team Member Accredited from the International Scrum Institute.

Agile Certified Practitioner - PMI-ACP is a new certification from the Project Management Institute (PMI) that tests knowledge of agile, lean and kanban approaches. Similar to the PMP exam, the PMI-ACP exam requires experience working on projects, a mandatory training requirement, and a multiple choice test administered by a Prometric Test Center.

The PMI-ACP exam requirements are: 2000 hours working on any kind of project, plus 1500 hours of agile experience. Candidates must also have 21 contact hours of agile related training and then sit a 3 hour, 120 question exam. Further details can be found here

 Less well know agile certification options include:

The “Software Extension to The PMBOK Guide” is available for public review here. It is a PMI hosted site, but you do not need to be a PMI member to access the draft. This is the first full exposure of the draft. It was completed earlier in the year and sent to some subject matter experts for review, but has not been made publicly available before. So, if you have an interest in how the PMBOK Guide should be augmented/modified for software projects take a look and submit you comments.

As a parallel, the Extension to the PMBOK Guide for Construction, has been available for a number of years and it offers guidance to project managers in the construction business. The role of the Software Extension, is to fulfil a similar role, but this time for managers of software projects that often face changing requirements, evolving technologies, and bringing together divergent knowledge workers to collaborate on challenging problems. For these project environments the Software Extension describes a spectrum of Predictive, Adaptive and Agile Lifecycles that may be used and more people based, as opposed to process based, development strategies.

I know asking how the PMBOK Guide can best be changed for software projects will likely prompt some colourful suggestions, but that’s half the fun. We will have to review all the suggestion and having the odd passonate suggestion brightens up the review process. I once worked with a developer who used a copy of the PMBOK Guide to raise the level of his monitor to approximately the same height as his other monitor. When he heard I was working on the next version of the PMBOK Guide he said that he uses his copy every day, and it was indispensable, but could we add another 10-15 pages to the next version (so his monitors would be perfectly aligned).

So, please take a look, we really do value your feedback, both good and bad. The role of the Software Extension is to modify and extend the PMBOK Guide recommendations for project managers in the software industry. It will be published in mid/late 2013 with your feedback incorporated or politely passed over, as we see fit.

Yesterday I gave a presentation entitled “Inside the PMI-ACP Exam” with PMI Certification manager Priya Sethuraman at the PMI-SAC Professional Development Conference. The session was designed to provide an overview of PMI certifications offerings, explain the positioning and development of the ACP exam, and dive deeper into the ACP domains and question types.

Yesterday was also notable for the PMI-ACP certification reaching 1732 credential holders, overtaking the PMI-RMP for the first time making it the most popular credential offered by the PMI behind the PMP and CAPM. Overtaking the Program (PgMP), Risk (PMI-RMP), and Scheduling (PMI-SP) certifications (all of which have been available for several years) within its first year of offering is a really encouraging start.

The slides from yesterday’s presentation can be downloaded below.

Download File: "Inside the PMI-ACP Exam - Slides"

Like many people, I am a design and architecture enthusiast. Last week I had the pleasure of giving a keynote presentation at the Nordic Project Zone Conference in Copenhagen, Denmark. Most of the attendees were from Scandinavian countries (Denmark, Sweden, Norway, and Finland) and the conference was hosted at a Scandic Hotel. I also met a number of presenters who consult in these countries as well as the US, India and the remainder of Europe. Amongst them there was a common consensus that Scandinavian countries adopt agile practices well, and there is a close alignment between agile values and prevailing cultural values.

I discussed this alignment a little with Thursara Wijewardena who was presenting on “Making Agile Work on Virtual, Physically Dispersed and Diverse Teams”, she commented that many Scandinavian companies have flat hierarchies and a high regard for employee respect/empowerment which fits well with the values agile aim to instil.

With it being my first visit to a Scandinavian capital, I was also impressed by the minimalist design approach apparent at our venue. “IKEA inspired” is the wrong term, since this was all high-end furniture and fixtures, but to anyone not familiar with Scandinavian design it helps capture the idea of the sleek, stripped to its core form and purpose style. To me it seemed no surprise that a culture used to pairing everything back to its minimal form, would take to agile that also looks to “maximize the work not done” and use “just enough” and “barely sufficient” documents and constructs.

To many people, agile is the opposite of sound theory. Instead of proceeding in a structured, well-planned manner, teams “self organize” and iterate through prototypes to try and create something. Ants can self organize and create transportation systems and large, complex community structures. Yet when people self-organize, we tend to get slum ghettos with no sanitation. Which outcome do your projects most resemble?

Planning is a slow, boring, unpopular exercise that attributes accountability to the planning group; if something goes wrong, we know who to blame. If everyone has a go at creating something and it does not turn out, then the blame is harder to pin on someone; excuses can be made around the project being complex and requirements not clearly articulated, etc.

So, is it laziness and dodging accountability that drives the huge growth of agile approaches, or is there something else to it? The Standish Group, which studies software project failure and success rates, recently reported:

“The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.”[1]

They sound pretty impressed, so what’s behind it? It turns out there’s plenty, but in the human resources domain, not the project execution domain. Projects are undertaken by people for people; they involve getting people to work together on things, collaborate, create consensus and sometimes compromise. As such, it is only right that the real key to project success should come from “people science” rather than “scheduling science”. Don’t get me wrong: work breakdown structures, Gantt charts and network diagrams have their place, but they are not the right place to start your journey for successful projects.

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 )

 

The PMBOK v5 Guide draft text has been approved by the Consensus Body. This is the PMI appointed group of industry consultants, government representatives, and academics who vote on the final content, and they have reached agreement on the ultimate text to use. Some of the appendices are still being finalized, but the main text is complete and set.

My contributions were on chapter 6 and while I had submitted corrections and updates to the PMBOK Guide before, this was the first time I had worked on a Chapter Core Team. On the plus side it provides first kick at suggesting updates, but on the negative side you then have to reconcile the thousands of review feedback suggestions.

My hope was to get more agile content into the PMBOK v5 Guide since 65% of PMI membership work on IT projects and agile has penetrated the IT industry. This means for many readers the previous PMBOK Guide seemed oddly deficient in its coverage of common practices. We got some agile coverage included, but it was much smaller than I hoped for. Yet perhaps it opens the door for future expansion in later versions.

I am glad it is finished; it was a very large volunteer time commitment with many periods requiring 10-20hrs per week. As with any volunteer work, the cause, the people you “meet”(this was all remote work), and what you learn are the real rewards. The PMBOK v5 Guide will be available in January 2013 and will drive the update cycle of offerings like PMP Certification and associated PMI standards.

Linked below are my presentations from the Agile 2012 Conference in Grapevine, Texas. My slides are really just prompts and pictures to accompany the explanations and stories I tell , but if you were at the conference you will get the idea. For the longer “Collaborative Games for Risk Management” session I have also attached a full 20 page White Paper explaining agile risk management, and the games involved in more detail.  

Thanks to everyone who attended my presentations and, as ever, you are always welcome to contact me if you have an additional questions.

Download File: "Cowboys Presentation"

Download File: "Risk Slides"

Download File: "Collaborative Games for Agile Risk Management - White Paper"

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

On Monday June 25th Calgary’s Agile Leadership Network meeting with feature Dr. Lionel Laroche presenting on “Working Effectively with Off-Shored IT Resources” the session is free, so come along if you can. The slides will be made available to those how cannot attend after the meeting at the Calgary Agile Leadership Network website

Presentation Outline:

"On paper, off-shoring IT work is a no-brainer – the salaries of programmers in India, Panama or Romania are a fraction of the salaries of programmers in Calgary. However, as most people who have worked with off-shored resources have learned, things are not as simple as they may seem, because managing off-shored resources is not the same as managing Canadian resources. Because people in different parts of the world think, communicate and behave differently in the same situations, projects that involve off-shored resources often experience significant difficulties, particularly at the beginning. This presentation examines the root causes of these difficulties and provides practical tips and suggestions that participants can readily implement when working with off-shored resources."

About the Speaker:

Over the past 14 years, Lionel has provided cross-cultural training, coaching and consulting services to over 25,000 people on four continents. Lionel specializes in helping organizations and professionals reach their business objectives in culturally unfamiliar contexts. In particular, he has worked with organizations like Sun Life, CP Rail, Fujitsu, PwC, CGI, AMD, Microsoft, Gennum, and many other overcome the challenges associated with working with off-shored resources and reap the corresponding benefits. Lionel is the author of two books, "Recruiting, Retaining and Promoting Culturally Different Employees" and "Managing Cultural Diversity in Technical Professions"; he and his business partner, Caroline Yang, are working on a third book entitled "Turning Cultural Diversity into a Competitive Advantage."

To register for this even click here. After the event the slides will be posted here.

This is the third part in a series on agile risk management; Part 1 looked at the opportunities agile methods offer for proactive risk management, while Part 2 examined the benefits of engaging the whole team in risk management through collaborative games and cautioned us about groupthink. This article walks through those games and explains how to engage a team in the first three of the six risk management steps.

The PMI risk management lifecycle comprises of:

1. Plan Risk Management
2. Identify Risks
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
6. Control Risks

These phases can be addressed collaboratively via the following team exercises:

• Plan Your Trip (Plan Risk Management)
  • 4Cs: Consider the Costs, Consequences, Context and Choices
  • Are we buying a Coffee, Couch, Car or a Condo? How much rigor is appropriate and what is the best approach?
  • Deposits and Bank Fees – understanding features and risks

• Find Friends and Foes (Risk and Opportunity Identification)
  • Doomsday clock
  • Karma-day
  • Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)

• Post Your Ad (Qualitative Risk Analysis)
  • Investors and Help Wanted – classification and visualization of opportunities and risks
  • Tug of War – project categorization

• 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 (Monitor and Control 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

We will walk through the first three steps in this article and then the last three steps next month:

1. Plan Your Trip (Plan Risk Management)
This phase is about deciding and defining how to conduct risk management activities for the project. We want to tailor the process to ensure that the degree, type and visibility of risk management is commensurate with both the risks and the importance of the project to the organization. So we do not use a sledgehammer to crack a nut, or undertake a risky, critical endeavor with an inadequate process.

The other goal we have for this phase is to teach some risk basics to the team since they may not be familiar with the concepts or terminology. The name of the first exercise (“Plan your trip”) speaks to the goal of determining the appropriate level of rigor. Most people can associate with planning for a walk or hike, and this is the context we use for the activity called the 4Cs. Early in any collaborative workshop, I like to get people working. If you let them spectate for too long some will retreat into “observer” rather than “participator” mode.

Working individually (again to encourage active engagement, and avoid groupthink), ask the team to consider what they would pack for a two-mile hike in the country on a warm day. Give them a couple of minutes to create lists on Post-it notes and review their responses as a group. Some will suggest taking nothing, others just a bottle of water, rain jackets, bear spray (I live near the Rocky Mountains in Canada) and all sorts of other things. We then review the pros and cons of these items. They are useful if you need them, but a burden to carry. We then repeat the exercise changing some parameters such as making it a 10-mile hike or a multi-day trip in the mountains during winter. Now the lists get longer as people prepare for more eventualities.

For each situation, we review the 4Cs: the Costs, Consequences, Context and Choices. What we bring (and how we prepare for risk management) varies based on the cost of bringing/using it, the consequence of not having it (rain coat: get wet; warm jacket : cold/hypothermia). We also examine the context we are talking about: preparations for elite ultra-marathoners who are hardy, capable and resourceful, or a kids’ group that needs more protection. Finally, the choices we make should be an informed balance of cost versus consequence in the frame of the context.

We need to understand these same elements in planning our risk management approach, too. Is this project domain our core competency? What are the costs and consequences of project risks occurring? What is our company’s risk tolerance and preferred risk management approach? Make sure people understand the environment.

Another tool to relate the need to tailor the process appropriately is to ask the team to consider the decision rigor they put into their purchases. The way we consider buying a coffee ($2), a couch ($2,000), a car ($20,000) or a condo ($200,000) varies as the figures involved escalate. For a coffee, we probably just find something close, maybe at our favorite store. For a couch, people will shop around and likely buy the one they like the best without much further research. When it gets up to car territory, safety, economy and resale factors are routinely examined. For a condo purchase, the stakes are so high that most people engage professional help from home inspectors and condo document review companies. We need to do the same for our projects, asking what is appropriate for the endeavor.

Finally, if the team is new to risk management then a discussion on the tradeoff between business value and risks might be necessary. We undertake projects usually for the potential upside (or for compliance projects to avoid the downside)--we are hoping for business benefits. Agile projects use business value as an input into work prioritization; we do the high-value items first. We want to deliver business value, and getting business value out of a project is like receiving deposits into our bank account--we want them as often as possible, and preferably as large as possible. Given the uncertainty in the world, we want the biggest gains as soon as possible before anything changes that may threaten future deposits.

In this bank analogy, risks are like withdrawals or bank fees--should they occur, they set the project back, take away resources from delivering business value and threaten the delivery of future value. So to get the most out of a project we need to maximize business value while avoiding or reducing risks. These exercises and discussions aim to get the team thinking about the appropriate level of risk management for the project and gain consensus and support for the strategy that is agreed upon. Without this shared understanding of “Why?” we will not get people invested in the process.

2. Find Friends and Foes (Risk and Opportunity Identification)
The next step in the process is to identify potential risks and opportunities. Opportunities are the “good” risks or fortuitous events that have a positive impact should they occur. We want to avoid risks and exploit opportunities. The IEEE have some good risk profile models for software projects. They were created by collecting risk information from thousands of completed software projects, then categorizing and ranking the common ones. These models can be used in a group setting or, as I prefer, used as the inspiration for a collaborative game. The “Doomsday Clock” exercise is based on a risk profile tool I have written about previously.

Using a clock view pre-drawn on a white board or flip chart, we ask team members to think of project risks associated with each of the topics represented by an hour line on the clock--12 in total. (For a detailed description of the types of risks within each category we would be asking the team to identify, see the spreadsheet attached to the risk profile article.)

This is the doomsday part: Wwe encourage the team members to think of and record as many risks as they can about that topic. We work topic by topic, but if thinking of risks triggers ideas in other areas as we progress, it is not unusual to get risks being added to previously discussed risk lines. Again, I prefer having people working individually for coming up with ideas. Then we put them all on the wall and consolidate and remove duplicates as a group, which also sometimes identifies new risks.

This process takes a while; spending just five minutes on each topic requires an hour to go through them. Discourage people’s tendencies to want to score, rank and solve the risks. This is risk identification--we will have plenty of time to process them later.

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:

Listed below are 20 sample exam questions, which are aligned with topics on the PMI-ACP Exam Content Outline. People studying for the PMI-ACP exam should find them useful practice. The answers and accompanying explanations are provided at the end of this post.

1) Which of the following is an Agile Manifesto principle?

A) Welcome changing requirements, early in development. Agile processes handle changes for the customer's competitive advantage.

B) Welcome changing priorities, early in development. Agile processes harness change for the customer's competitive advantage.

C) Welcome changing priorities, even late in development. Agile processes handle changes for the customer's competitive advantage.

D) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.



2) When managing an agile software team, engaging the business in prioritizing the backlog is an example of:

A) Technical risk reduction   

B) Incorporating stakeholder values   

C) Vendor management   

D) Stakeholder story mapping   



3) Which of the following items is not a benefit associated with product demonstrations?   

A) Learn about feature suitability   

B) Learn about feature usability   

C) Learn about feature estimates
   
D) Learn about new requirements   

Trying to maximize business value while ignoring risks is a little like trying to heat your home with all the doors and windows open. Much harder work than it need be, unlikely to be successful, and just not very smart.

Risks and opportunities are ever present on complex projects. We can rely on them occurring much like we can rely on the tide coming in. How we choose to deal with them--our risk management strategy--greatly influences whether we rise with the inevitable tide of issues and navigate successfully, or become overwhelmed by them and don’t reach our goal.

Agile methods incorporate many mechanisms for dealing with late-breaking changes (an easily reprioritized backlog, short iterations, frequent inspection, replanning, etc.) that also lend themselves to proactively responding to risks. We can insert risk avoidance and risk reduction actions into the backlog to attack the risks before they have an impact on the project.

This can all be thought of as part of maximizing business value. The process of frequently asking: “What should we do next: build a business feature or reduce a project risk?” is valuable and often summarized by the term “The next best dollar spent.” It reminds us to think about risk avoidance and mitigation as part of the value proposition and agile planning cycle.

So when planning work for the next iteration, we balance delivering business value with reducing risks. Sometimes we select a feature since it is the best return on our investment; sometimes we will undertake a risk avoidance or risk mitigation step since the impact of the risk occurring would be greater than the ROI value of the next feature in the backlog. (This is a quick summary; to read more about putting risk reduction actions in the backlog see here.)

Over the course of the project, agile teams use tools such as risk burn-down graphs and risk profiles to illustrate the effectiveness of the risk-driven approach. The goal is to rapidly reduce risks on the project. (For more on these agile risk reduction techniques, see here.)

Another benefit of tackling risky work early is the cost of change-curve savings possible in software projects. By proactively undertaking risky work early, we can reduce the overall impact to the project compared to if those risks occurred later when their effect (in terms of rework or revision of approach) would be much higher. Simply put, risks solved early are more valuable than risks solved late.

Agile methods with their pull mechanisms and frequent reprioritization can readily take risk management actions as early as possible in the lifecycle, minimizing knock-on effects. Also, since testing is built into each iteration, toward the end of the project the chances of there being any risky elements not tested in the solution are greatly reduced. As such, agile methods can be called “risk-driven” since we are always looking to pull stories with risks forward in the backlog.

While agile methods provide some nice ways to proactively embrace good risk management practices, they do not “risk-proof” nor insulate projects from risks. Indeed, if the agile approach is new to your organization, then its introduction will be a risk itself--anything new represents a risk of misapplication, misunderstanding, confusion and failure. However, agile methods are hardly new anymore and adoption problems are well understood.

This post introduced how agile methods mesh well with the mechanics of risk management. Next time we will examine the next level of effectiveness in agile risk management: how engaging the team members in risk management through collaborative games brings far greater insight into project risks, and their avoidance and mitigation actions.

(Portions of this post first appeared in Gantthead.com here)

Please join me on Wednesday May 2^nd for a free webinar on “PMI-ACP: Adopting Agile into the PMP World.” This is part of Rally Software’s webinar series and we already have >2,000 people signed up. The session runs on Wednesday May 2^nd at 7am (PT) / 10am (ET) and then again at 1pm (PT) / 4pm (ET) You can sign up here. 

In the webinar I will be talking to Juie Chikering about the exam’s content, who it is aimed at, it’s positioning in the industry, and how it has changed since the pilot last year, amongst other things. There will be interactive poles and questions from the audience, so it should be an interactive and informative event.

I will be presenting the webinar from the RallyOn Conference in Boulder, CO where I am also speaking about agile PMOs and on a panel with Dean Leffingwell, Johanna Rothman, and Alan Shalloway about the future of agile. I am really looking forward to it and also spending some more time in Boulder which I especially enjoy.

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.

Forbes ran a nice article a couple of weeks ago on how agile is the next big thing for management, but its unlikely origin in the software industry may hamper its adoption. The article provided some nice analogies:

1)    When the British government, in 1714, offered a prize for determining longitude at sea, of £20,000 (£3M in today’s money), a Yorkshire carpenter called John Harrison eventually solved it, but the scientific community refused to believe that a carpenter could have solved the problem that had thwarted the best scientific minds. In 1773, when John was 80 years old, he received an award of £8,750 but not the actual prize. A Yorkshire carpenter was the wrong person to have solved the problem.

2)    In 1865, Gregor Mendel, an unknown professor created a theory about gene inheritance after studying pea plants. It answered inheritance issues that had stumped the finest scientific minds. The paper was ignored by the scientific community for the next 35 years until people eventually realized that Mendel had indeed come up with the solution. His theory later became known as Mendel’s Laws of Inheritance. His work had been ignored; a researcher on peas was the wrong person to have created the theory.

3)    In 1981, Barry Marshall, a pathologist in Perth, Australia, came up with a bizarre new theory that ulcers were caused by spiral bacteria. No one believed him so in 1984 he drank a batch of spiral bacteria and sure enough developed ulcers. Eventually in 2005 he received a Nobel prize for medicine for his work, but it took that long to be accepted. An unknown pathologist from Perth was the wrong person to have made the discovery.

So then we come to agile; for decades management had struggled to balance execution with innovation. How do we simultaneously get work done yet still drive improvements without one factor stifling the other? Now we know agile methods do a great job of balancing delivery with improvement.

Agile methods also provide a framework for sense-making and managing ambiguity when there are significant gaps in our understanding of requirements, approach, or technology. These uncertainties have a habit of stalling plan-driven approaches that struggle to reach escape velocity from the process of gathering requirements and planning. Agile methods instead choose to build what we know, evaluate, gain consensus on where to go next and iterate to a final solution.

The credibility problem we have is that software people, those weird IT geeks with poor communication skills are the wrong people to have proceduralized a complex communication and collaboration process. It should have been some management professors at the Harvard Business Review or Sloan School of Management at MIT. How can that IT crowd, who some believe have trouble making eye contact and describing an issue without resorting to techy speak, have figured out a way to collaborate and communicate on unique problems with unprecedented solutions?

On Wednesday March 26 the Calgary Agile Leadership Network (CALN) is very pleased to welcome Steve Adolph from Rally Software.

Steve’s talk is related to his PhD thesis and focused on why smart hardworking people often fail to deliver on their commitments? He asks if there is something missing from our Agile training programs? Also, is something missing from our Agile practices? Steve will explain how part of the answer to these questions comes from the theory developed during his research and a course of action is offered for improving agile teams.

This promises to be a fun filled talk with tales from the airline industry and practical advice on why we need training on how to work together. Registration is free, please join is if you can, click here to reserve your place.

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)

I finished my PMI-ACP Exam Preparation book a couple of weeks ago and now it is with the publishers for reviews and final edits. It turned out larger than expected, but I think better for the extra exercises and sample exam questions.

When designing the PMI-ACP^SM exam, we needed to base the content outline on existing books and resources so that candidates would understand what the exam would test them on. When choosing the books, we went back and forth on our decisions of which books to include, since there are so many good resources available. And while we recommend that people learn as much as they can, we also had to recognize the need for keeping the exam content—and the preparation process for the exam—reasonable. In the end, we selected the following 11 books:

1.    Agile Estimating and Planning, by Mike Cohn
2.   Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith
   
3.   Agile Project Management with Scrum, by Ken Schwaber
   
4.   Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen
   
5.   Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn
   
6.   Becoming Agile: ...in an Imperfect World, by Greg Smith and Ahmed Sidky
   
7.   Coaching Agile Teams, by Lyssa Adkins
   
8.   Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and James R. Trott
   
9.   The Software Project Manager’s Bridge to Agility, by Michele Sliger and Stacia Broderick
   
10.   The Art of Agile Development, by James Shore and Shane Warden
    
11.   User Stories Applied: For Agile Software Development, by Mike Cohn

Reading all of these books takes some time, since the 11 books add up to more than 4,000 pages. The books also cover a lot more material than you need to know for the exam. From each book, we extracted the portions that best covered the exam content outline topics, and the exam questions were then targeted at those specific sections.

By Mike Griffiths

The Mayans may have had the first timeboxed project. They had a strict 2012 timebox cut off with little room for extension since the world would no longer exist. Although agile methods have been preaching the benefits of fixed timeboxed schedules since their creation, it still raises concerns with many stakeholders.

The triangles diagram from DSDM created in 1994 shows the shift from fixed Functionality (vary resources and time) to fixed time and cost (vary functionality).
 


So, instead of fixing functionality (scope) via the signoff of a specification document and completing all of this functionality (hopefully within the time and budget specified), instead the resources and time are fixed and as much of the functionality as can be completed is done before the time and money runs out.

This sounds a bit like time and materials, but there is an understanding that the core functionality, the Must Haves, the Priority 1’s, or whatever you want to call them, will be delivered. In fact 80% of the outlined functionality should be delivered and it is the last 20% that is up for replacement with late breaking changes that could add even more value.

So, the best of both worlds then? All the important features and an opportunity to swap out low priority elements with things that might crop up as we go. However this is not how many stakeholders view it. Projects typically have three stakeholder groups: Sponsors who commission and fund projects, Users who, well, use them to do some work, and the Project Team who builds them. While at the 30,000 feet level all the these stakeholder groups want the same thing, a successful project, when we dig a little deeper other priorities emerge.


 

My PMI-ACP Book is coming along nicely and today RMC released some more content including sample questions and walked through explanations of the answers. Visit the RMC Site to access it and also sign up for future previews and special discounts.

Now if I could only write this stuff as quickly as they are giving it away, I would be doing OK! 

I am overdue for providing an update on how my work on The PMBOK v5 Guide is going. Well, it is on its way. The process is slow (sometimes painfully slow) but this is because of the number of people involved and the review process used. To give an idea, here is the plan for the next 6 months:

*  17 February – 20 March 2012: the exposure draft PMBOK® Guide – Fifth Edition will be open for comments

*  Late February 2012: team training for our adjudication processes

*  20 March 2012: our exposure draft period closes and comment adjudication begins

*  20 March – 28 April 2012: teams adjudicate exposure draft comments 

*  Early May – mid May 2012: core committee reconciles any comment adjudications that cut across chapters or where consensus has not yet been obtained

*  Mid May – early June 2012: appeals period for adjudication decisions; final draft QC and integration reviews

*  Early June – mid June 2012: appeals adjudication and resolution

*  Mid June – late June 2012: final draft cleanup and incorporation of QC comments

*  28 June 2012: core committee vote on finalized draft

The Exposure Draft process is a great mechanism for allowing members to review and comment on new material, but likely to generate a ton of review work for us. The Fourth Edition update, back in 2008 received over 4,400 comments during its exposure draft.  Since the membership of the PMI has increased significantly since 2008 we could be looking at close to double that figure.

That is a lot of suggested changes to review and I think March and April will be a busy time for me. Of course they will not arrive in one Word document, but I wonder what the PMBOK Guide would look like if we just did an “Accept All”? Right now it is the calm before the storm; I am going to make the most of it.

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 am currently in Miami at the PMI Agile Certified Practitioner Steering Committee Meeting. We have been reviewing the pilot program that just wrapped up and discussing proposed changes for the full program when it gets rolled out next year.

The pilot has been a success with 7,654 applications being opened which far exceeds other PMI specialized certifications offered to date. These came from 114 countries with the top 10 by volume being:

1. US
2. India
3. Canada
4. Brazil
5. UK
6. Australia
7. Sweden
8. Germany
9. Singapore
10. Switzerland

Overall 75% were already paid PMI members, and 70% were PMP credential holders.



Some of the changes we discussed (that are not approved yet) including extending the agile project experience qualification period from 2 years to 4years, change some of the questions from “Hows?” (e.g. NPV, IRR) to “Whys?” and tone down the software references.

Other work that will occur between now and when the certification gets reopened in January 2012 will include scoring the questions from the pilot. Questions that had a statistically higher set of people getting them wrong will be examined. As too will questions that people who otherwise did well on the test, seemed to struggle with. These poor performing questions will be swapped out with new ones and augmented by the new questions now coming out of the second round of question writing.

As always the best part has been catching up with everyone, always worth the journey.

I have uploaded the slides from my “Agile PMO” presentation and they can be accessed from the link below . I presented them last week at the Calgary APLN meeting and this week at the PMI-SAC Professional Development Conference. My session was well attended and I received good feedback; some of the slides are pretty sparse and really just visual reminders for me to tell a story about something. In the upcoming weeks I hope to post some more thoughts on the topic.

At the conference I attended some great sessions by Ed Merrow, Lee Lambert, and Jeremy Gutsche amongst others, that inspired some new directions of learning that I hope to write about too. Unfortunately release demos, and 2012 road-mapping sessions at my day job preventing me attending all the sessions I would have liked, but the event was very worthwhile.

Download The Agile PMO

On Wednesday Nov. 16th I will be presenting on how “PMOs often Present Multiple Obstacles for agile projects yet can also Provide Many Opportunities”. This is for our local A(P)LN chapter and is a dry run for next week when I am presenting it at the PMI-SAC Conference. Anyone who is around Calgary this Wednesday is welcome to attend this free event. Please just register in advance so we know how many drinks to plan for.

In the presentation we will explore:
•    What is a PMO supposed to do anyway?
•    How agile projects are often a misfit for PMOs
•    A different kind of Game Theory to illustrate how PMOs can help
•    Characteristics of an agile aligned PMO
•    What are today’s PMO challenges?
•    A case study for an award winning agile PMO
•    Tomorrow’s PMO challenges and opportunities

I am looking forward to seeing some old friends and meeting some new members too, I hope you can make it along.

What is project success? Is it just on time, on budget, with required functionality, and to a high quality standard? Or is there more, some missing X factor, a good after-taste, or resonance that we just know is great?

I did some training for a client recently who is interested in measuring project success. The traditional constraint measures of on budget, on schedule, happy stakeholders were not cutting it for him. They were missing this unknown element he was really more keen to measure. We talked about other measures of success including how people feel about the project and the act of leaving a valuable legacy.

There are plenty of examples of projects that might be judged failures by the constraint measures of on budget, on schedule, etc, but successes in terms of how people felt about them and the act of leaving a legacy. They include the Apollo 13 mission, the Titanic Movie, Shackleton and the Endurance, and the Iridium Satellite Network. I wrote about how these “failed” by constraint measures were successes by other measures in a post a couple of years ago.

This still was not satisfactory and these measures were often only apparent long after the project was done. They were too late and retroactive, my client wanted something he could use right now to get a better handle on projects. It turns out what he was looking for might be better explained by Actor Networks with Convergent and Divergent behaviour, (but I did not know that then, so back to the story.)

Bothered by not fully answering his question, I attended the Agile on The Beach conference in Cornwall, UK. I flew into London, where I worked in the 1990’s at Canary Wharf and saw the Millennium Dome being built. Seen in films such as James Bond: The World is Not Enough, the Millennium Dome project that, while on schedule, has been widely labeled as a failure. The white elephant that hardly anyone wanted, and struggled to attract or please visitors. I was even a little surprised to see it was still there, since I knew it had been left empty for a while, used as a temporary homeless shelter, and other things.
 

Conspiracies can be fun. Based on just enough superficial evidence or correlation, they allow us to indulge our imaginations and let off some steam. But what happens if we stumble onto a hush-hush cover-up that we were never supposed to find? Is your system just slow today, or is there a key logger running? You better conceal that camera on your monitor (hey, it’s not being paranoid when everyone is out to get you!) We are about to explore some agile conspiracies, so get your cover-up ready...

1. Agile as a Means to Prevent Outsourcing

Outsourcing software development to smart people working for less money overseas loomed large over the IT industry in the 1990s as giants like IBM and Fujitsu opened mega data centers in India and China. Fortunately, a ragtag band of visionaries met in Snowbird, Utah to thwart the threat before it became a reality.

Understanding that detailed specifications and good plans allowed for work to be successfully handed off to third parties, they set about undoing these best practices. If they could successfully sabotage the building blocks of successful handoffs, then the outsourcing trend could be stopped--or at least slowed.

By insisting that customers did not know what they wanted (and couldn’t explain it anyway), they undermined years of progress in requirements specification and project planning. When challenged on these claims, they played their ace card by saying that since publishing their findings there had been no business groups complaining or refuting their findings--so they must be true (when in fact no one outside of the software world had any idea what agile was or that anything had been published). Yet without anyone to call “Foul!”, their message stuck and began to grow.

Some early adopters saw the end goal and jumped on the bandwagon, reinforcing the cause through their own findings; others blindly followed the new calling, thinking it made sense. Even the agile manifesto founders were amazed when the real benefits were not discussed at the first Agile Conference as more and more people joined the cause. Knowingly or unknowingly, the movement grew.

2. Agile as an Excuse to Avoid Documentation

The Calgary Agile Project Leadership Network (Calgary APLN) 20011/2012 season kicks off with a social at the Barley Mill in Eau Claire, Thursday Oct 5, 4:00 – 6:00pm.

"To help build a vibrant Agile community in Calgary, we would like to invite you to a networking event. Come out and meet other Agile Leaders within Calgary, swap stories and share some laughs. Agile Recruiting has graciously sponsored the event by providing appetizers. Cash bar will be available.”

This is a great opportunity to meet and chat to other people in the agile project leadership community in Calgary. We have a limited capacity so register to reserve a place. I hope to see you there.

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

(This post, a draft sample from my upcoming PMI-ACP Prep book, takes a look at the “Value Driven Delivery” domain.)

Value, specifically the delivery of business value, is a core component of agile methods. This concept is woven into the agile DNA with its inclusion in the Agile Values (“Working software over comprehensive documentation”) and the Agile Principles (“Working software is delivered frequently” and “Working software is the principal measure of progress”). The focus on delivering value drives much of the agile activities and decision making on a project, and it manifests itself in many of the Tools and Techniques (T&T) and Knowledge and Skills (K&S) used. The focus on value is such an essential component of agile methods that the “Value Driven Delivery” domain has the most T&T and K&S of any of the 6 domains. This means we are starting with the biggest section early in this book.

What Is Value Driven Delivery?
Let’s start by defining value-driven delivery. The reason projects are undertaken is to generate business value, be it to produce a benefit or improve a service. Even safety and regulatory compliance projects can be expressed in terms of business value by considering the business risk and impact of not undertaking them. If value then is the reason for doing projects, value driven delivery is the focus of the project throughout the project planning, execution, and control processes.

It is the big picture view, the wearing of the sponsor’s hat when making decisions. By the project manager and team assuming this viewpoint, there is an opportunity to incorporate unique technical insights, such as technical dependencies or risk reduction steps, into the selection of features for a release that the sponsor may not be aware of. However value driven delivery remains a guiding vision for much local decision making, the selecting of choices that maximize the value delivered to the business or customer.

Risks as Anti-value
Risks are closely related to value. We can think of project risks as anti-value, i.e., things that can erode, remove, or reduce value if they are to occur. If value is the heads side of a coin, then risks are the tails side. To maximize value we must also minimize risks, since risks potentially reduce value. This is why the Value Driven Delivery domain addresses many risk reduction concepts and techniques.

I am excited to announce I will be working with RMC to create a PMI-ACP Study Guide book for the upcoming PMI Agile Certified Practitioner exam. When I was studying for my PMP exam many years ago, I used Rita Mulcahy’s PMP Prep Study Guide and was very grateful for the plain English explanations, exam guidance, and sample questions. So it feels right and a bit of a privilege to be working with the same company to help guide people for this new exam.

Working with the other PMI-ACP Steering Committee members over the last couple of years on the Agile Community of Practice and to define the exam has been a great experience, but the hundreds of hours of unpaid volunteer time has to be made up somewhere so hopefully this endeavor will help out. Assuming people still buy books that is, I read this Guardian article today that made me wonder. Anyway, embracing today’s publishing ideas; I will be posting snippets here for anyone looking for taster portions. The big picture views, sample exam questions, and cheat sheets will be kept for the main book, but key concepts around the tools and techniques, knowledge and skill areas will be posted here.

I would love to hear your feedback on these portions, please let me know if they are useful, need more explanation, or you think I am missing anything. I can then develop additional material to improve the final product. To help collect all my PMI-ACP content together (and exclude it for those of you not interested) I have created a Category tag called “PMI-ACP” and you can use the Categories filter under “Recent Posts” in the right hand navigation on my LeadingAnswers.com home page to find content.

Agile adoption outside of software is nothing new--it dates back very close to the origin of today’s agile methods, predating the term “agile”. However, what is new and noteworthy is the rate and scale of non-software agile adoption being witnessed today. Now--as more companies than ever are exposed to agile methods in their IT practices--these methods are being employed beyond the regular IT domain.

The key to understanding the applicability of agile outside of IT is the concept of the “knowledge worker”. Knowledge workers are people with subject matter expertise who communicate this knowledge and take part in analysis and/or development. This not only covers the IT industry, but also engineers, teachers, scientists, lawyers, doctors and many others employed today. In fact, knowledge workers have become the largest segment of the North American workforce; the so-called Third Wave of human socio-economic development after the Agricultural Age (land based) and the Industrial Age (factory based). In the Knowledge Age, value is based upon the ownership of knowledge and the ability to use that knowledge to create or improve goods and services.

Knowledge worker theory and agile theory are a little like twins separated at birth, growing up independently. As the agile community was determining the best way for software teams to collaborate, knowledge worker researchers were establishing ideas like Human Interaction Management--which asserts there are five principles characterizing effective knowledge work:

• Build effective teams
• Communicate in a structured way
• Create, share and maintain knowledge
• Align your time with strategic goals
• Negotiate next steps as you work

If you think this list sounds a lot like how we manage our daily stand-ups, prioritize the backlog and work in iterations, then it you are not alone. The two camps are very similar, and the ways to effectively collaborate when manipulating bits and not atoms (information not materials) are now widely taught. However, not all our guidebooks or practices embrace the subtleties of knowledge worker environments and many Industrial Worker relics remain. In the industrial age, after product design was complete, work was relatively predictable with only breakdowns, human error and raw material defects to content with. Change rates were relatively low and uncertainty can be largely planned out of a process through a management focus on process. In the knowledge worker environment, high value often comes from combining information from new or unlikely sources. Levels of uncertainty in job execution can be high, and management focuses on people rather than process.

This “Uncertainty and Management Focus” spectrum is shown below:

A uniting thread through the variety of different agile methods is the fact that they all employ work prioritisation schemes. While the terminology varies--Scrum for instance has a “product backlog”, FDD a “feature list” and DSDM a “prioritised requirements list”--the concept is the same. The project works through a prioritised list of items that have discernable business value.

Prioritisation is required because it enables the flexing of scope to meet budget or timeline objectives while retaining a useful set of functionality (Minimum Marketable Release).


 

Prioritisation also provides a framework for deciding if/when to incorporate changes. By asking the business to “Tell me what it is more important than?” and then inserting the new change into the prioritised work list at the appropriate point, it is possible to include changes.

 

It is worth explaining that while agile methods provide tremendous flexibility through the ability to accept late-breaking changes, they cannot bend the laws of time and space. So if your project time or budget was estimated to be fully consumed with the current scope, then adding a new change will inevitably force a lower priority feature below the “cutoff point” of what we expect to deliver. So, yes, we can accept late-breaking changes…but only at the expense of lower-priority work items.

A single prioritised work list also simplifies the view of remaining work. Rather than having separate “buckets” of work for change requests, defect fixes and new features, by combining them into a single prioritised list, people get a clear, complete view of all remaining work. Many teams miss this point to begin with and retain bug-fix and change budgets. This muddies velocity; a single prioritized list of work-to-be-done regardless of origin offers better transparency and trade-off control.

Behind Every Scheme is a Schemer
How we go about prioritisation (and the prioritisation schemes used) varies from method to method--and sometimes project to project--based on what works for the business. A simple scheme is to label items as “Priority 1”, “Priority 2”, “Priority 3”, etc. While straightforward, a problem with this is that there is a tendency for everything to become a “Priority 1”--or at least too many things are labeled “Priority 1” for the scheme to be effective. It is rare that a business representative asks for a new feature and says it should be a Priority 2 or 3, since they know that low-priority items risk missing the cut off. Likewise, “high”, “medium” and “low” prioritisations fall victim to the same fate. Without a shared, defendable reason for what defines “high”, we end up with too many and a lack of true priority.

DSDM popularized the MoSCoW prioritisation scheme, deriving its name from the first letters of its labels of “Must…”, “Should…”, “Could…”, “Would like to have, but not this time.” Under MoSCoW, we have some easier-to-defend categories. “Must-have” requirements or features are fundamental to the system; without them, the system does not work or has no value. “Should have’s” are important--by definition, we should have them for the system to work correctly; if they are not there, then the work-around will likely be costly or cumbersome. “Could have’s” are useful net additions that add tangible value, and “Would like’s” are the “also-ran” requests that are duly noted--but unlikely to make the cut.

An approach I have seen work well is giving sponsors Monopoly money equalling the project budget and asking them to distribute it amongst the system features. This is useful for gaining general priority on system components but can be taken too far if applied to question perceived low value-add activities like documentation, so keep it for the business features.

If you do not have any Monopoly money available, the 100-Point Method originally developed by Dean Leffingwell and Don Widrig for use cases can be used instead. It is a voting scheme where each stakeholder is given 100 points that he or she can use for voting in favor of the most important requirements. How they distribute the 100 points is up to them: 20 here, 10 there or even all 100 on a single requirement if that is their sole priority.

The Requirements Prioritisation Model created by Karl Wiegers is a more mathematically rigorous method of calculating priority. Every proposed feature is rated for benefit, penalty, cost and risk on a relative scale of 1 -9 (low to high). Customers rate the benefit score for having the feature and the penalty score for not having it. Developers rate the cost of producing the feature and the risk associated with producing it. After entering the numbers for all the features, the relative priority for each feature is calculated by considering the percentage of the weighted feature desirability to each feature. (For more details and link to an example, see Karl’s outline First Things First: Prioritizing Requirements; also, for more analysis on mathematical models on requirements prioritisation try this US-CERT paper.)

No Scheme as a Scheme
At the end of the day, it is the prioritisation of features and not the scheme we need to focus on. Sometimes refereeing the schemes themselves can detract too much time from meaningful discussions. For this reason, I am personally a fan of simply asking the business to list features in priority order. No category 1,2,3s; no high, medium, lows; no must haves, etc,--instead, just a simple list (whether this is in Excel or an agile requirements management tool). This removes the categories that people tend to fixate upon from the debate and leaves the discussion around priorities.

 

Conclusion
By all means get creative and try different schemes to engage the business in the prioritisation. There is no single best way to always prioritise; instead, try to diagnose issues arising in the prioritisation process, be it “lack of involvement” or “too many priority 1’s”, and then try approaches such as Monopoly money, MoSCoW or a pure list to assist if the problems cannot be resolved via dialogue. The goal is to understand where features lie in relation to others as opposed to assigning a category label. By maintaining a flexible list of prioritised requirements and having opportunities to revisit and reprioritise, we maintain the agility to deliver the highest value set of features within the available time and budget.

(I wrote this article originally for Gantthead.com and it appeared in April 2011 here)

♫ It is summertime, my posts are short, the days are long
Caught somewhere between work and play
(This blog just is not getting written in between)
It is summertime in North America! ♫

Summer in the Canadian Rockies is short and busy for me, I spend more time mountain biking and hiking than working, so not much gets posted here on my blog. To help fill the void I will be posting a couple of articles I wrote for Gantthead earlier this year. So unless you are an avid Gantthead reader, these articles should be new to you. Normal postings will resume at the end of summer here, i.e. much too soon.

Here is an update on the agile happenings at the PMI that I have been involved with. The pilot program for the PMI Agile Certified Practitioner filled up fast. 2,649 people opened applications for the program, a record for the PMI, and the full launch in October is looking like it will be very popular. Item writing for the exam questions is on track and Registered Education Providers (REPs) are in high-gear readying their courses.

The PMBOK v5 Guide continues to move forward too. My work is on Chapter 6 (Time Management) and we recently reviewed and incorporated the second round of approved comments. There was a meeting this weekend to review all chapter comments along with the updated Inputs, Tools, Techniques, and Outputs (ITTOs). I have suggested some agile content I am not able to discuss under the NDA, but I am hopeful it will survive the approval process. Other Chapters have agile content being suggested too. This is a slow process though and the PMBOK v5 Guide is not expected until late 2012.

I was also recently contacted about working on an Software Extension to the PMBOK Guide. This really excites me and is something I looked into leading a few years back (before I discovered the full extent of the work involved). There has been a call for Agile experts to help develop the new extension.

If you have ever looked through the Extension to the PMBOK Guide for Construction, you will know that the extension does more than add a bunch of industry related practices. It also suggests changes to the existing PMBOK’s outlines. So, for instance, instead of creating a detailed WBS, we could suggest creating a candidate feature backlog. Many of the suggestions for change to the PMBOK Guide have to be tempered with the fact that the guide has to remain industry agnostic and suitable for any project manager. An extension for the Software Industry allows us to go much deeper into agile techniques. I am looking forward to this work and learning who else is involved.

Finally the PMI Agile Community of Practice continues to grow and develop. I learned that Michele Sliger’s recent webinar had over 500 people in attendance. This is great and a sign of the levels of interest for agile present in the ever expanding PMI community. Taking agile to the PMI that used to have this “evil empire” feel felt audacious eightr years ago, now it seems natural and if anything, belated. People have strong opinions and the PMBOK Guide work has shown me that many people still dismiss agile methods, but it feels like the tide is coming in and neither King Cnute or the diehard traditionalists will stop it.

The 2011 Agile conference goes back to its roots this year, returning to Utah 10 years after the creation of the Agile Manifesto there in 2001. I won’t be there this year, since I’ll be taking advantage of Canada’s short summer to take part in the TransRockies mountain bike race.I was disappointed to be missing out on the conference, but am more excited by this multi day race through my backyard mountains.

Then, last week I heard of some other agile events that I can attend. The DSDM consortium is holding Agile roadshows in Cambridge and Newcastle. It will be great to catch up with Steve Messenger and others from Napp Pharmaceutical. Then there is “Agile on the Beach” happening in Cornwall, where I grew up, this September. So for me this year, I will not be joining my usual North American agile friends for their back to their roots conference, but will be embarking on my own back to my roots agile conference tour. Likely lower key, but I always manage to learn something new and make some good connections.

Washboarding is an instability that occurs when vehicles move on dirt roads. What starts off with a small bump turns into a whole series of small bumps as vehicles travel the road. Washboard roads are more dangerous than smooth dirt roads and have to be driven at lower speeds. All these bumps are a pain in the rear (literally) and make you go slower.

We see the resourcing equivalent of washboard roads in projects too. Traditional projects staff early with business analysts to do the bulk of the requirements gathering and then bring in developers and finally QA people. These peaks and valleys of specialization not only look like a washboard road, but they have the same effect, they are a pain in the rear and make you go slower.

 
Because the BA’s, devs, and QA’s are not used evenly throughout the project, they are brought in for a short period and then transferred to the next project. People try to share BA’s, QA’s and other roles between multiple projects and pretty soon most people are working on multiple projects. This is very difficult to schedule efficiently because projects rarely sync up exactly or stay on plan. Worse, task switching between multiple projects is time consuming, prone to errors, less satisfying, and a slower way of working.

Just as preventing washboarding on a road is difficult once it has started, breaking the resource washboard anti-pattern can be difficult too. A concerted effort and decision to staff whole team projects needs to be made. Acknowledging that it is impossible (or at least extremely unlikely) that all the final requirements can be captured up front, keep the BA’s around. Engage the QA team early so they hear from the business firsthand what they should be testing for, and encourage developers to work with the BA’s and QA’s beyond coding. Whole team staffing breaks down silos and prevents throwing things over a wall to another group that is inefficient and error prone.
 

Bringing the whole team together at the beginning of the project allows them to work collectively on vertical slices of the solution through to completion. Multidisciplined teams can help each other to minimize resource constraints and since the team swarms around solving small increments, there is no task switching penalty when asking for help.

Just as the advantages of smooth roads over washboard is clear to everyone, so too are the benefits of dedicated, collaborative teams. Dirt roads and small bumps lead to road washboarding, as specializations, functional groups and matrix management leads to resource washboarding.

Executive management are the best bulldozers, they can mandate the change and pave the way as it were. If you do not have that level of commitment, break the bumpy cycle on the projects you can control. Recruit combined BA/QA staff and keep them throughout the project, get all roles in the design sessions, and business discussions, resist task switching and prioritize projects. Then see how much faster you can go.

It turns out the original suggestion of “Agile Project Practitioner” (PMI-APP) was too close to “App.” as in an Application or phone app to easily trademark (in this case service mark). So the name will now be “Agile Certified Practitioner” ACP as in Fred Blogs, PMP, ACP.

The timeline for people wanting to apply will be:
•    May 23rd    - Launch of application to Public
•    Mid July    - Pilot Participants can schedule exams at Prometric test centres
•    September 15    - Pilot Program Testing begins
•    November 30    - Pilot Program Testing Concludes
•    January 1    - First set of individuals that passed the exam are notified.

I am getting lots of questions about the content of the exam, so I thought I would present a couple of ways of interpreting it. In my last post on this subject I showed the box model for reconciling the Domains with the Knowledge & Skills (KS), and Tools & Techniques (TT).

Here is a version with the KS and TT’s listed:

 
(click on any of the images above or on the continuation page to see a bigger version)

"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!

The PMI has now published the Agile Certification Examination Content Outline, you can download it here. It outlines the “Tools and Techniques” and “Knowledge and Skills” areas that the exam will be broken into. As we have it now, 50% of the examination marks will be awarded for Tools and Techniques and 50% for Knowledge and Skills.

 

As part of the Steering Committee it was interesting to take part the discussions around these weightings. As recent as a month ago the split being suggested for the exam weighting was 70% of the exam would be based on Tools and Techniques with just 30% on Knowledge and Skills. We had steering committee members suggest a 60, 40% split the other way, but in the end the 50%, 50% split was selected.

       

Doubtless people are reading through these categories trying to get a handle on the scope of the exam. My recommendation would be to focus less on these divisions (that overlap anyway) and focus on the domains that underpin them.

As an example we see Knowledge and Skills Level 1 mentions “Building Empowered Teams”,  Level 2 has “Building High Performance Teams”, and the Tools and Techniques section has items for “Communications” including “daily stand-ups”  and “collaboration”. These are obviously all closely related, but listed in separate areas which could be confusing,  but if you adjust your view to focus on the domains, there is a better separation into logical areas.

 
I am hoping that there will be a reissue of the Examination Content Outline, since the current form needs word-smithing. The text we generated for it was our short hand notes. For instance Domain 1 Task 1 reads:

“Define features and project work in terms of end-user and stakeholder value by focusing on maximizing value delivered and minimizing non-value-added activities in order to keep the delivery team focused on maximizing the value developed.” Is quite the mouthful that made sense to us, but could perhaps be restated along the lines of:

“Define project features and work items in terms of end-user and stakeholder value, by always looking for and clarifying the business value. Focusing on maximizing value delivered by the project and try to eliminate any non-value-added activities. This keeps the delivery team focused on maximizing the business value and reduces the likelihood of wasteful activities, feature bloat and gold-plating.” While this is longer, hopefully it is in easier to absorb chunks.

Anyway, as the categories evolve and the questions get developed I will keep readers updated here.

The PMI employs a Continuing Certification Requirements (CCR) program to encourage members to keep their skills and knowledge up to date. This basically means that to maintain your certification (be it PMP, CAPM, or PgMP) you have to meet the ongoing requirement for Professional Development Units (PDUs).


Money For Nothing
To some people this is viewed as a money grab, like selling you a cheap inkjet printer and then holding you to ransom on ink cartridges. You are now on the hook for continually paying to renew that credential you worked so hard to obtain, or lose it.

So every three years you have to prove you have taken enough courses and attended enough local meetings (both of which the PMI can happily provide to you for a fee) to ensure those valuable credentials stay on your resume.


Psst, it’s 2011, Things Have Changed!
Actually, while the picture just painted is the mindset shared by many project managers, it is out of date and severely limited. Starting March 1st, 2011 the PMI broadened the eligibility of qualifying activities and simplified the categories for PDU claims. Also, the CCR program is as much about encouraging members to give back to the PM profession as it is to learning, so your options may be much wider than you think.

For the budget conscious of you out there (and let’s face it you are here partly because the content is free) there are plenty of ways of fulfilling your 60 PDUs within a three year cycle that costs no money. Yep, all your PDU’s for free!

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:

I created the following fun periodic table of agile adoption to explain some of the ranges of adoption, adaptation and blending that we see in the workplace.

 

The Model
On the left to right (X axis) we see varying ranges of agile purity to pragmatism. On the left we have the agile zealots and fundamentalists for whom everything must be done exactly by the book or it is just not agile and therefore wrong. On the right hand side we have the pragmatists who are happy to take what works for them and forget the rest.

On the vertical (Y axis) we have the degree to which people blend other techniques and practices into their work. Low on the scale people use a simple implementation of the theory they have adopted. High on the scale we see a complex blend of multiple practices; perhaps agile, with the Theory of Constraints (ToC), Complex Adaptive Systems (CAS), or their own in-house standards.