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:

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)

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.

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

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)

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.

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.

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.

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

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

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

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

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

I like myths and have written on Leadership Myths previoulsy. For our next Calgary APLN Meeting we are hosting an Agile Mythbusters discussion. The idea being to debate some agile myths and through group discussion determine if they are Busted, Confirmed, or Plausible.

Now, likely an APLN audience might have a little bias, since the “A” in APLN stands for "Agile", but I hope that since we have cross posted the invitation to the local PMI group we might even things out.

Through my teaching for the PMI I get to hear many questions and rebuttals to agile’s claims and I think it is good to question benefits and have an honest reality check from time to time. Some of the myths proposed for discussion so far include:

•    You cannot accurately estimate agile projects
•    Agile methods promote scope creep
•    It is very difficult to negotiate contracts for agile work
•    Agile projects cannot be tracked with earned value
•    Agile projects employ counter intuitive planning practices
•    Stage gates don't work for agile projects
•    Agile methods avoid accountability
•    Agile projects are cheaper
•    Without specifications you do not know when you are done
•    You would not allow a housing contractor to proceed without a clear plan and estimate, why develop SW this way?
•    Agile scales naturally
•    Agile teams are happier
•    Since empowered teams self-organize and self-select work, the role of the project manager goes away
•    Agile methods erode the gains made towards recognizing SW development as a serious engineering discipline
•    Agile methods ignore enterprise architecture
•    Agile is quicker


Please send me your own agile myths for us to discuss. We will be choosing 5-6 to run through at the meeting. If you are in Calgary on January 26 please join us for the session. Registration details here at the Calgary APLN site.

If you cannot make it in person, I will write up some findings and publish them here later.

A big part of project management is working to grow a high performing team and then caring for that team so it stays healthy and productive. Agile concepts around empowered teams and team decision making support these goals and so there should be no surprise that agile project management aligns well with team development best practices.

However, it never hurts to better understand some of the things that can go wrong on teams so that we can quickly take action and hopefully resolve issues before they become full blown team problems. Patrick Lencioni’s book “The 5 Dysfunction of a Team” lists the following 5 common problems that build on from each other to undermine trust and eventually performance.

1) An absence of trust – an unwillingness to be vulnerable and honest within the group.

2) Fear of Conflict – Teams that lack trust cannot engage in unfiltered debate. Instead they resort to veiled discussions and guarded comments

3) Lack of commitment – without passionate debate, team members rarely if ever, buy in and commit to decisions, though they may feign agreement during meetings

4) Avoidance of Accountability – Due to the lack of commitment and buy-in most people will hesitate to call their peers on actions and behaviours that seem counterproductive to the good of the team.

5) Inattention to results – Failure to hold one another accountable leads to putting individual goals (or department goals) ahead of the project.

Fortunately agile methods and some common sense offer many tools and values to address these issues...

Agile methods encourage partnering more closely with the business customer to benefit from shorter customer feedback cycles. When this works, it is great; we get quick confirmation of deliverables and engage in collaborative evolution towards the true business requirements as opposed to the originally stated requirements that may have been flawed or incomplete.

Yet poor customer feedback can really undermine progress. Effectively the customer has become a more central member of our project team and just like a poor BA, developer, or QA, the impact of a weak customer link is significant.

Often customer engagement issues stem from confusion over roles and levels of involvement. Perhaps the customer has not been invited into development teams before and may feel uncomfortable speaking out about potential gaps in functionality early in the project when work is still underway. This is why it is important to clearly outline benefits of good feedback and the issues with poor feedback.

For project managers some warning signs of poor customer engagement can be:

1)    Little or no customer feedback – If following a demo or promotion of functionality to a test environment for customer review we get very little feedback, then the optimist in us may think “Great, we must have nailed it, there have been no complaints or requests for changes”. Yet, it is more likely that no one has thought about it much or used it in anger. In this instance “No news, is rarely good news” and is instead should be viewed as a warning sign that effective evaluation may not have occurred.

2)    Late reporting of errors – If as a release date approaches we see the reporting of errors or requests for change relating to functionality that has been in previous demos, but never commented upon, then it is a sign that this functionality was not seriously reviewed previously. Instead only now, as the release date is approaching does it appear the customer representatives are reviewing seriously. This is a problem since functionality may have been built on top of the early code, and opportunities for change and improvement have now been lost.

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

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

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

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

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

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

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

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

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

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

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

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

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

Does your PMO Produce Multiple Obstacles for your project or Promote Many Opportunities for success?

A Project Management Office (PMO) can act as an obstacle to agile projects. This can take the form of asking for inappropriate planning detail by not recognizing the likelihood of changes; or asking for conformance to templates that are not even used on an agile project. For these reasons PMOs often get a bad reputation on agile teams, but it need not be that way, they can also add tremendous support and be a great help.

First let’s look at what a PMO actually does (or what they should do, since implementations and services vary). In the September 2010 issue of the Project Management Journal (the PMI’s research publication) there was a nice definition of PMO roles:

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

This definition is good because it speaks to the “supporting” and “developing” roles a PMO should provide and moves beyond the “conformance” and “compliance checking” functions that many teams think of when they consider a PMO. However, when taken with a rigid, traditional-only view of how projects should be run, the PMO can lead to the Produce Multiple Obstacles issue:

  There has been some hubbub on the PMI Agile Yahoo Group these last couple of weeks. A lively back-and-forth about a slide deck published by the PMI Network magazine entitled “Is Agile Right for your project?”

The original slides were here, but interestingly the slides appear to have been taken down now, or perhaps they have been temporarily lost in the recent PMI web site reorganization. An example of some of the feedback can be seen here. On the one hand I think the PMI should be applauded for making some steps towards providing information for its members. On the other hand the material could have been vetted by some members of the PMI Agile Community of Practice before release to smooth out the contentious issues and avoid the backlash.

I recall the original request for information on agile adoption guidance was sent to the PMI Agile Community of Practice. I submitted my thoughts on the topic (posted previously here) and many other people joined in the discussion thread, but I am not aware of what, or if any, of this information made it to the original requestor.

Anyway, my point is not so much on the content of the slides and what was right or wrong, but more on the reconciliation of agile and traditional PMI mindsets.

Social Integration Problems
Whenever two different groups come together for the first time, we get some friction, clashing of norms, exposing of preconceptions and good old fashioned faux pas by one or more groups. But, hey, it at least means the two groups are coming together and providing we have thick enough skins to tolerate the friction progress can be made.

Jane Jenson, from the University of Montreal, provides a model for social integration that lists 5 characteristics that need to be in place to create good social cohesion between different groups:

1)    Recognition – Both groups need to recognize the other group’s position
2)    Legitimacy – Both groups need to acknowledge the validity of the other group’s point of view
3)    Inclusion – Neither group should be excluded from events, roles, or functions
4)    Belonging – The benefits of belonging to a combined whole need to be understood
5)    Participation – Both groups need to work alongside each other on shared initiatives

Researchers also provide the following model of how social cohesion works:

Project management has matured with many professional organizations, certifications, and bodies of knowledge, yet we still hear of numerous project failures. What has gone wrong; is project management broken? I don’t think it is broken in terms of any of it being fundamentally wrong, but certainly flawed in the view that good project management ensures success.

You see, what project management with all its plans, estimates and reporting omits is a good recognition for the huge impact people play in projects. Consider for a moment the roadblocks we encounter on projects, the most common and toughest to resolve are people related. Yet the classic project management guides focus more on Earned Value than Influencing, more on KPI’s than Knowledge Transfer, more on Project Tracking than Team Performance. Project management may be correct, but it is not sufficient for creating success.

Like considering only speed limits and traffic signals, but ignoring other traffic movement when driving, we will run into people, have accidents, and not get to our destination on time with such a myopic view of the big picture. A large portion of the missing part of project success is Emotional Intelligence (EI) and the EI skills most needed by project managers include:

•    Communication Skills
•    Persuasive Leadership
•    Conflict Management
•    Change Management
•    Adaptive Personality

For more information on the importance of EI for project managers and how these skills are applied see this recent White Paper.

Following my post on 5 Things to Think About Before Stand-Up, it is only right that I follow it up with the 5 things I think about after Stand-up.
 
1) Issues – Anything that was reported as a blocker, impediment, or issue to making progress needs removal or avoidance. Agile employs a “constraints view” of production systems similar to Eli Goldratt’s Theory of Constraints where the role of the manager is to remove impediments from the process. The impediments or blocker issues reported at stand-up should become the project managers To-Do list to ensure their resolution.
 
2) Velocities Deviations – We know the task estimates so when a 2 day task has taken 4 days and is still going with no end in sight, it is time to investigate. If there is time in the stand-up it might be appropriate to ask if there are any problems? Alternatively it might be better to follow up afterwards and determine the issue. Was it a poor estimate, a wicked problem, or sign that perhaps someone else should take a look? In isolation these occurrences are common; however repeating delays in work areas or with team members might be signs of deeper issues. Likewise overly high velocity (all the 4 day tasks being burned through in a day each) might be signs that we can re-evaluate our iteration goals. Just make sure “done” really is “done” and the tasks are all passing QA and user acceptance before booking the end of project party a month early.
 
3) Emotions – Consider what was said and what perhaps was not said. Was anyone upset or angry, were there tensions that need to be understood, a bubbly person abnormally quiet? All might be signs that a quick chat could be in order. These are impediments to progress just as much as reported problems. Some we may not be able to solve, but perhaps just enquiring and listening to what they have to say is a useful step towards resolution itself. (Thus allowing the worker bee to then produce more code... Buwahah!)
 
4) Questions – Perhaps we did not fully understand some progress or issue discussed at the stand-up. If a quick clarification during the meeting did not help then likely some follow up questions are required. (I used to be a developer and understood technical things, now I sometimes have to explain that I am a project manager and you have to speak slowly to me. If that still does not work I explain that I am actually a PMP certified project manager and so you will have to speak really s-l-o-w-l-y). We cannot fix what we cannot understand and while many things remain the domain of the technical team, when escalation and impediment removal is required (i.e. my job) I need to fully comprehend the issue so I can best resolve it. 
 
5) Recognitions – All work and no play makes for a dull week, month, or project. Look for opportunities for some kind of recognition, event or milestone to celebrate. We want to maintain motivation so people have the energy to blast through obstacles not run out of steam at the first hurdle. A great way to do this is to frequently recognize progress and contributions. This can be a simple thank-you explaining what people did that was useful and how it helped the project, or a team lunch, or gift. These events can make all the difference between a death march and rapid team progress.
 
Again these are my Top 5 today, on a different day I may include different things like the skills fit for selected tasks, resource load balancing, or if we are mitigating the remaining project risks, but these are currently not as high priorities on my team. What about you? Please share what you consider following stand-up?

Stand-up meetings are familiar to agile teams and as the saying goes “familiarity breeds contempt” or at least complacency. It is all too easy to drift into a daily routine of holding a stand-up meeting without getting the full set of benefits out of it. So this led me to consider: what are the 5 most important things to think about as a project manager before stand-up?
 
(If you are using Scrum and have a Scrummaster role that is distinct from the project manager, then I would suggest these are things the Scrummaster should be considering)
 
1) A View of the WIP – A view of the work in progress is critical to understanding the items reported from the team. If you thought invoicing was a focus right now and no one mentions it, chances are we have an issue somewhere! Appreciating the work areas helps oversee new work selection, areas that might be falling behind, or where extra help may be required.
 
2) Yesterday’s issues – What did people report as issues yesterday or earlier? Have these issues been resolved now, or do we at least have an update on the resolution plan. It is pretty disheartening for people to report impediments to progress day after day and not have them worked on. It does not show much respect for their concerns or our valuation of their time. So, what is the news? Are there any follow-up items that need to happen?
 
3) Team View – Projects are more than tasks and schedules, they are networks of collaborating individuals. We need to understand the people elements of the team to build a shared commitment to a goal. Show an interest, recognizing a birthday, or upcoming wedding or vacation. Know what is going on with your team as it will colour their behaviours and provides a good opportunity to demonstrate an interest in them. If some people dial-in, try to follow the headlines there so you can ask them about the heat wave, giant sink hole, or whatever it is that is happening, this also helps them feel more integrated.
 
4) Areas of Spin and Churn – not all issues are reported specifically as issues or blocks to progress, some are more subtle, perhaps dragging anchors that slow progress rather than road blocks. Are there any tasks that have been going slower than anticipated, perhaps people are struggling to get traction (spinning) on a new task? Be especially attentive to the discussion of these items during stand-up. If things are moving again now, then great, here was a potential for micro-management interference avoided. A fact of project life is that some tasks will take longer than anticipated. If however team members are stuck on a task for a couple of days or flip-flopping on decisions or approaches (churn) then perhaps it is time to suggest a fresh set of eyes to pair on the problem or help move things along.
 
5) What you are going to say – just like the team members who we expect to have a list of accomplishments, planned tasks, and any impediments ready to report; it is important to have the same items to describe. I report on my progress on impediment removal and since I believe in transparent project management, run through the main project items too. While my issues may not be of as much relevance to the technical team, a review of any budget, hiring, and steering committee items is generally welcome (or at least politely tolerated!)
 
Obviously there are many other things to consider (shared commitment, vision, energy), but I am interested in understanding what you think the Top 5 are? If you have suggestions for items to replace any of these 5 please leave a comment, I would love hear your thoughts.

Agile methods are powerful approaches that bring many benefits to how we undertake project work. However, they are not immune to misuse or failure. The following list of 5 common pitfalls are often seen in organizations switching to agile. “To be forewarned is to be forearmed” as they say, so look out for these pitfalls and if you see any developing, a side step can be useful to help avoid the mistakes of others.

1) Agile as a silver bullet - Yes, agile methods can save time, increase business buy-in, and create a high quality product, but they are no silver bullet. They will not bend space or time and allow you to deliver more work that is possible within the constraints of limited time, budget, and resources.

Deciding to switch a doomed project to an agile approach will not make it succeed. You may fail faster, or at least discover realistic progress indicators (velocity) earlier than with a traditional approach, but unachievable goals will remain unachievable. By all means use an agile approach to salvage a core set of valuable functionality from a failing project, but don’t expect agile methods to miraculously make the impossible possible.

2) Agile as an excuse for no discipline – Contrary to some people’s beliefs, agile methods do not abandon discipline and jump straight to coding without the need for plans and estimates. Agile methods involve many high discipline activities and techniques like Test Driven Development, Wideband Delphi estimation, and bi-weekly iteration planning and estimation sessions take a lot of discipline.

If team members are pushing back on estimating or cannot explain the release plan, these are warning signs that they may not be following the agile practices. Instead they could be using agile’s preference for low ceremony documents as an excuse for avoiding doing the disciplined activities that make up each of the agile methods. Hold them accountable, ask for their estimates and request their retrospective findings.

Why so much Communication?
“We work with bits not atoms”. This phrase speaks to the distinction of IT projects from physical construction. Our tools and processes manipulate ideas, concepts, and models, not steel, concrete, or plastic. Given the intangible nature of software, it is no surprise we need more focus on communications, collaboration and information sharing to keep everyone informed and aligned towards a common goal.

Agile methods recognize this increased need for communication and provide a variety of tools and checkpoints to help avoid the classic project mistakes of mismatched expectations and confusion. In the absence of a visible physical product to point at and measure, we need to be constantly confirming understandings and aligning ideas against increments of the final solution. Otherwise we get the “That’s not what I asked for” or “That’s not what I need” of yesteryear’s IT projects.

Why So Often?
Daily Stand-Up meetings are common on agile projects, not because IT folk are more forgetful than other workers and need to discuss work goals and results more often; but instead because the potential for misunderstanding is higher when working on novel, hard to describe problems. Stand-Up meetings keep the team informed of work and issues that change quickly and also provide a forum to raise obstacles to progress so they can quickly removed before they unduly impact performance.

Why So Many Demo’s?
Software projects typically contain a lot of uncertainty. You would have to be clairvoyant to accurately predict the final business requirements of an organization 18 months out into the future in today’s rapidly changing business environment. So agile methods accept some requirements are likely to change and rather than have a change control process that should really be called a “Change Suppression Process” they welcome new ideas and then seek priority within a backlog of requested features. Obviously changes cost money, but if it is more important than some previously discussed item, then why not incorporate it and deliver some late breaking competitive advantage?

Agile methods promote the frequent demonstration of software for a couple of reasons. One, to get feedback and make sure it is fit for business purpose. Quite often it is not until we see something that we can better articulate what we really need, now with reference to a visible prototype. Another reason is that it is often during these demonstrations we learn about business changes and new requirements. Many times I have heard comments along the lines of ‘Oh, and for product ABC we will need to way of entering X” when this has been news to us. That’s OK, visual demo’s tap into the right hand side of our brain, not used much in analytical, left brain list making and requirements gathering. It is the combination of lists and visual cues that frequent demo’s provide that create our final views of what the system should encompass.

Decision making is both analytical and emotional. We need to make decisions to move forward beyond the forks in the road, but when exactly is the best time to make them? Agilists have the automatic response of “At the last responsible moment” drummed into their heads so often that you may think they are drones rather than free thinking individuals.

Delayed
Agile and Lean gurus have explained the benefits of delaying decisions until the last responsible moment for many years. It prevents us from committing to potentially harmful decisions too soon and instead enables us to gather more information and then make a better decision when we actually need to. It keeps design options open, enhances agility, and allows agile teams to be more responsive to change than teams who have locked into a defined approach early.

Dated
Real Options adds some math to the picture. It supports the same general idea of decision delaying and providing some dates and values for our decision making calendar. This could be reassuring for people left feeling a little uneasy by all the “up in the air” decisions. Now, it is not that we are just putting them off, but instead have agreed that there is an optimal time to make each decision and when that arrives we will make them.

Done
I recently read the excellent “Rework” book by Jason Fried and David Heinemeier Hansson of 37 Signals and it was refreshing to read about their thoughts on Decision Making. They say: “Decisions are progress. Don’t wait for the perfect solution. Decide and move forward. You want to get into the rhythm of making choices. When you get in that flow of making decision after decision, you build momentum and boost morale. You can’t build on top of “We’ll decide later”, but you can build on top of “Done”.

Plus, you don’t have to live with a decision forever. If you make a mistake, you can correct it later. It doesn’t matter how much you plan, you will still get some stuff wrong anyway. Don’t make things worse by overanalyzing and delaying before you even get going. Long projects zap morale. Make the call, make progress, and get something out now – while you’ve got the motivation and momentum to do so.”

I like this a lot. We can often get caught up in the analysis of the perfect moment to make a decision and forget the very real motivational impact of not deciding. Decisions are emotional and our emotions impact our productivity. Yes it might be marginally better to decide on that reporting tool at the end of the month, but if everyone is non-committal until then or only 90% focussed, perhaps not sure on what will happen, then what is the real cost of this Real Option?

People’s ability to deal with ambiguity varies from person to person. However many people find it disconcerting to work with little bits of their commitment parked at each of these delayed decisions. It is foolish to try and schedule being happy on Thursday at 2pm, likewise it is foolish to assume delaying decisions comes without motivational penalties.

Like most things, we can’t live by a single mantra such a “Delay decisions to the last responsible moment”, instead we need to balance the analytical benefits of delaying decisions against the emotional costs and remember that, as Rework goes on to say: “Momentum fuels motivation. The way you build momentum is by getting something done then moving on to the next thing.” Rework keeps it real, and for that is a great read.

“…we need to balance the analytical benefits of delaying decisions against the emotional costs …”

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

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

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

A “Pendentive” is an architectural converter that lets you fit a domed roof on a square base. The pendentive shown in the image on the right is the yellow part.
 
When working in a traditional project management setting we often need agile pendentives that let us fit agile practices onto a traditional base. Here are some examples:

Traditional to Agile
1.    WBS –>  Prioritized Backlog. When asked to show the Work Breakdown Structure (WBS) sponsors and PMO are likely looking for a breakdown of the project deliverables. Traditional project management approaches recommend creating a WBS early in a project lifecycle after gathering requirements and defining scope.

Agile projects acknowledge this upfront design is likely to change and so deliberately go a little lighter on these definition activities, preferring to invest the time in building portions of application and arriving at agreement of functionality through feedback.

2.    Detailed Gantt Chart –> Release Plan. Detailed Gantt charts are another example of a detailed upfront design deliverable that is likely to be brittle and changing too frequently to warrant the update effort in project environments that have high levels of requirements uncertainty or technology uncertainty. It is not that we cannot create Gantt charts for agile projects – I do for some stakeholders. Rather that the time and effort required to update them is probably best used elsewhere in gaining agreement of the true business requirements.

So, instead of producing detailed Gantt charts that list tasks and do not survive contact with the reality of software projects, release plans that layout iterations and release timeframes are a more robust planning tool.

Agile methods emphasize and encourage empowerment and creating empowered teams, but empowerment is not enough. Empowerment, according to Daniel Pink author of “Drive: The Surprising truth about what motivates us“, is just a slightly more civilized form of control. This control is part of a broken motivation system corporations use that he calls Motivation 2.0.

Here’s the quick summary. Motivation 1.0 is our basic desire to find food, shelter, sex, etc. Once met, people look to higher levels of rewards to motivate us. Motivation 2.0 has been traditional management’s carrot and stick motivation system. If you do this…, then you get this…. The trouble with IF-THEN rewards is that while we like them at first we quickly tire of them. Then because the reward can never continue to escalate at levels that excite us, we grow used to them and get discouraged if we fail to meet the IF condition and do not get the reward or worse, if the IF-THEN reward is removed.

Daniel Pink states several MIT studies where adults and children were rewarded for conducting work, hobbies and play activities. Once the reward is removed people stopped doing them, even if the had previously happily voluntarily done them before. Once tainted by IF-THEN rewards, the motivation was sucked right out of it.

Pink asserts the current IF-THEN extrinsic motivation corporations use, that he describes as Motivation 2.0 is flawed and needs an upgrade. Hence the need and rise of Motivation 3.0 based on the intrinsic concepts of:
•    Autonomy
•    Mastery
•    Purpose.

Autonomy means giving people control over how they work. Moving beyond empowered teams who are required to be in work for stand-up meetings at set times each day, instead giving them control over:
    Task – the work then do and how they undertake them
    Time – when they choose to work in the day, week, year
    Technique – How they perform tasks and from where
    Team – How they organize, interact and collaborate

I have written previously on Results Only Work Environments (ROWEs) where people are given these freedoms and Ricardo Semler’s Semco is the poster child, but Pink offered additional examples of Meddius and Best Buy headquarters. Not only do people prefer it, but productivity and profits increase as satisfaction and motivation blossom.

Mastery describes the pleasure we get from doing what we love and following our passion. This can be seen when someone is so absorbed in a task that they are in the zone, or what Pink calls finding their flow. “Flow” is a great term to describe the state of mind when time seems to disappear and we are just immersed in the task. This feeling of flow can be difficult to find when our work environment puts obstacle after obstacle in font of us, whether it is admin and rules that limit our time in the role that we love, or restrictive work processes that impinge too much to allow us to get into this flow.

Mastery comes from:
    Flow – having the time, space and freedom to find and exercise your passion for a profession
    Goldilocks Tasks – Not too difficult and not too easy, but just right. We need enough Goldilocks tasks to stretch, engage and indulge our desire for completion and satisfaction.
    Mindset of learning – people who believe intelligence and knowledge is not a fixed capacity we are endowed with, but rather a muscle or skill we can grow. People who are happy to face their limitations and continually find new learning opportunities achieve mastery easier.

Purpose describes tapping into people’s belief that there should be more to work than just making money and being successful. Instead aligning company goals with individual’s aspirations for doing good and meeting a higher guiding principle.

This is why companies like TOMS Shoes were created that give away a pair of shoes to poor countries for every pair sold. Buyers feel good since their purchase has a charitable impact and the workers at TOMS feel good since they are doing more than just generating shareholder value. Instead they are tapping into their motivation 3.0 principle of a compelling Purpose.

Motivation 3.0 for Agile Teams

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

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

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

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

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

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

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

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

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

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

Personas get little mention in project management guidelines, yet they can energise the dullest of requirements and remind us of absent stakeholders. So I was pleased we Mike Haden suggested the topic for our next Calgary APLN meeting. Here’s the outline:

Title: "Using Persona to Move Your Project Forward"

Outline:
The use of personas has received scant attention in project management literature. First utilized in the late '90s as a tool of business analysis, a persona is a detailed description of a fictional end-user including how they use and perceive the product you're delivering. However, personas can have a strong impact on projects by providing a project team with a human face to enhance otherwise abstract data about customers. From streamlining communications, to managing stake-holder expectations, to maintaining the team's alignment with the project goals, personas can engage your team and enhance your capability to move the project forward rapidly.

This presentation touches on the origins and definitions of personas, the benefits and criticisms of their use, and includes a case study of persona implementation on a complex application development effort. Focused on how personas can galvanize a project team into action, it is an engaging, interactive presentation lasting of interest to all members of systems and application development teams.

Bio:
Mike Haden is an independent consultant with over 20-year's experience in Application Development, Project / Product Management, and Global Product Development. Throughout his career, he has delivered complex data analysis tools to the demanding Canadian oil and gas industry. Mike has experience in bridging the business and technical domains, balancing the communication needs of multiple stake-holders, and aligning project teams to the end-user.

While working in commercial software firms leading development teams that utilize agile project methods, Mike gained valuable experience in delivering application development projects ranging from true R&D through new commercial developments to replacements of “industry-flagship” applications. His current role at EnergyIQ is focused on a new data analysis product for the US oil and gas industry, developing business processes and technology to support distributed product development.

Mike is a Project Management Professional, a Certified ScrumMaster, and a Six Sigma Green Belt. He is presently the VP Communications for the Southern Alberta Chapter of PMI. He dreams of eventually finishing the rejuvenation of a 100-year-old house and having more time for his outdoor pursuits in the mountains near Calgary.

Date: Wednesday April 28, 2010  Noon-1:00pm

Location: Fifth Avenue Place (Conference Room) Map

Register: Attendance is free, but please register in advance to guarantee your spot.

Agile methods typically don’t cover the early stages of projects very well. They often assume you are ready to start gathering requirements as user stories, or that you even have some candidate features or stories magically ready to go. This is shown by the scope coverage diagram below.
 

 
 

Yet for all but the smallest, most process-light organizations, there are stages of envisioning, feasibility, and setup that happen before we are ready to jump into requirements gathering. This is where many companies come unstuck with agile. Either they jump straight to stories and miss out the early project stuff and suffer disoriented stakeholders and disengaged project offices. Or they go too heavy with the upfront chartering and scope definition, create brittle plans and lose some of the advantages of adaptation and iterative development.

The following diagram is a good place to consider starting from. It combines some of the bare necessities from a traditional approach that will satisfy the project office. Yet it does not go too far into Big Design Up Front (BDUF) to create problems or consume too much time that could be better spent working directly with the business to determine their requirements via collaborative development.

 
 

The overall duration is short, just 15% of the likely (guestimated) project duration, but yields lightweight versions of the key deliverables familiar to the PMI process police. We get stakeholders informed and engaged, the project office placated, and the bulk of the project duration dedicated to iterative development. 

Instead of a Work Breakdown Structure (WBS) I would recommend a candidate prioritised Feature List or prioritised Story list.

 

Kick-Off meetings using the Design The Product Box exercise, or Shape the Poduct Tree are a great way to start identifying candidate features and then follow them up with Feature Discovery Workshops. The length and number of feature workshops will vary depending on the size and complexity of your project. A three month web project with a team of three people might be scoped in a day or two. Yet a three year project with 30 people will take longer to drive out all the candidate features.

I am actually quite a fan of the early project deliverables like Project Charters since they explain important W5+ (What, Why, When, Who, Where + How) elements of a project, but believe these documents don’t have to be verbose or costly to create.

Instead cover the basics, get people onside and the whole endeavour will go quicker than if you try to start without these things and have to catch people up later.

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

 

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


March 10-11 Anaheim, CA

April 13-14 Scottsdale, AZ

September 15-16 Las Vegas, NV

November 10-11 Scottsdale, AZ

December 15-16 San Diego, CA

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

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

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

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

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


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

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

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

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

Registration Link

I have just started my second season of mentoring for our local PMI chapter. This week’s launch workshop was facilitated by Right Management and they introduced a great model for building (and rebuilding) Trust and Respect that I would like to share. It was used to help explain how to build trust and respect with those we are mentoring, but it is a useful model that has much wider applications.

Establishing trust and respect can build tremendous support for goals, and likewise losing trust and respect puts us back at the beginning in a relationship or even further behind and the process has to start again. I am sure we have all experienced it, I know I have. Trust is a slow process to build and can be quickly eroded by a single bad deed or poor choice, as shown in the graph below.


 

While this is common sense stuff, what I liked about the workshop is the Howard Jackson Model for systematically building trust and respect. It is a repeatable series of steps that build on from each other in sequence to establish better collaboration.
 

 
In this model we start at the bottom of the pyramid with Straight Talk, and move through the steps of Listening for Understanding, Making Commitments, being Reliable, creating Trust, and then finally earning Respect.

Straight Talk  - Open and direct communication is the first building block for trust and respect.

Listening for Understanding – Focus your attention on understanding the meaning behind what people are saying. There is a big difference between waiting for your turn to speak and really listening. Hear, Understand, Interpret, and then Respond.

Making Commitments – Be clear about what you will do. Agree on the What, By When, By Whom, and How steps. Communicate your intentions and stick to them.


Reliability – Do what you say you will do without fail. If circumstances have changed and it no longer makes sense to do what you said you would do, communicate back and explain why, and discuss and agree on the new steps.  Follow through over-and-over, be reliable, unfailing, dependable.


Trust – Trust results from the firm belief that another person can be relied upon. Trust is the result of straight talk, making sure you understand and are understood, and keeping confidences as well as commitments.


Respect – Although there are many levels of respect, the respect that follows trust leads to deep esteem for another person. We value their thoughts and input, and we know we can count on them because they have proven themselves out to us.

Why so much focus on soft skills for an Agile PM Blog?
When I started this blog in 2006 I wanted to explain the new techniques used on agile projects in an easy to understand format, with real life examples. Now I find myself writing more on soft skills than agile techniques.

This is because people are the engine that drives a high performance project. Without a good team that embodies trust and respect, the best process and tools in the world will not help you. I am as geeky about process as the next agilist, I love experimenting with Kanban and Lean and know that they offer better ways of executing projects. However, bigger improvements can be had from the people side of things.

Another passion of mine is mountain biking. I lust after lightweight exotic bikes like the Super Fly 100 and S-Works Epic, imagining how much faster I could go, the hills I could finally climb. I am sure they would help, but the advantages are small, a good rider will dwarf the performance gains of the machinery and it comes down to the person powering the bike not the bike its self. It is like this with people and process too. Yes we can tweak and improve the process and I encourage you to, but the biggest gains come from within the team. From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes. We undoubtedly need a combination of soft skills, tools, and process, but when considering where to focus effort I believe the biggest payback is on the people side.

"From trust and respect comes great commitment and creativity which cannot be made up for with tools and processes."

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

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

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

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

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

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

So a standard Parking Lot diagram like this...

becomes a scaled Parking Lot diagram like this...

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

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

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

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

Solving problems with innovative solutions is fun, exciting and rewarding. Yet, being told what to do is generally boring and not very motivating, but why is this? Why exactly do some ways of working seem enjoyable and satisfying while others the total opposite? Well, the explanation involves chemistry and electricity.

I had coffee today with Dr Michael Aucoin, author of Right Brain Project Management, that I have discussed previously. He has been in Banff working on his new book and we chatted about empowered teams and productivity.

He explained that simply presenting work as questions rather than statements can engage mental models that make work more engaging, rewarding and in turn productive. More and more research on the brain is showing that we are hard-wired to reward ourselves for solving problems. Thinking about this, it makes sense, evolution rewards problem solvers and so an appropriate response is to make it feel good so that we continue doing it.

When we solve a problem and get that “ah-ha” moment, pleasure circuits in the brain light-up and endorphins are released that give us the buzz of solving the problem.  We also generate ownership for the solution and motivation to make it work, even if we encounter obstacles during the implementation. Contrast this level of enthusiasm with the prospect of having to do mandatory administration tasks or form filling. It is no surprise people enjoy working on empowered teams more than being directed exactly what to do, and some teams are orders of magnitude more productive than others.

So, as a project manager looking to increase productivity and motivation, is it simply a case of posing all work as questions and problems to be solved?  Obviously not, asking “Can anyone get our time recording entered?”, “Or, how can we write up these meeting minutes?” is likely to elicit the deserved response of “Yes, you need to stop wasting our time with dumb questions and do it!”

However, most projects could greatly benefit from engaging people’s problem solving skills and the motivation from solution-finding. Rather than over analyse difficult problems and prematurely decompose complexity into simple tasks, instead invite the team to find solutions. Make use of people’s problem solving skills and increased motivation it brings to create a more rewarding environment.

Is this manipulation, a mind trick to get people to work harder? I don’t  think so, instead a more insightful and respectful way of engaging a team. After all “We manage property and lead people. If we try to manage people they will feel like property”. Research on the brain is helping us understand what we instinctively feel. I am looking forward to Mike’s next book and learning more about working smarter.

What characteristics do you look for when hiring for an agile team? Our next Calgary APLN meeting is a panel discussion on the topic and looks set be a great one.

 

Some broad characteristics identified in the planning emails for the panel include:

Characteristics of a high performing team:

• Collaborative / effective communicator
• Willing to cross boundaries
• Work side by side / discuss work out problems real time
• A lot of face to face communication required
• Humility - accept feedback
• Able to compromise / support team decisions
• Able to reflect back on events and provide insights (critical for retrospectives)
• Always looking to improve
• Think about things rather than blinding moving forward…..
• Pragmatic - Knows what “just” enough is, Do what it takes
• Adaptive / Flexible - Change direction as required
• Takes initiative / self motivated
• Willing to try new things (may be evident by a desire for continuous learning)
• Can figure out the most important thing to do next. Doesn’t need to be told what to do.
• Risk tolerant – able to make a decision and act based on the information known
• Able to work in fast pace / intense
• Willing to work in a team room – little privacy, very noisy, no prestige
• Can challenge ideas in a respectful manner
• Work incrementally - Willing to revisit work
• Accepting that the big picture will evolve over time

Detecting these characteristics:

• Behavioural descriptive questions – tell me a time when….give me an example of….
• Interests / desires may be evidence of the characteristics
• Informal references from prior projects / peers etc.
• Auditions – pairing on an activity
• Trial periods

The panel members have also identified a set of technical requirements based on the various roles (developer, test, architect, etc), but I am most excited about who we have on our panel...

Zombies and Project Managers; to many people the images are synonymous, fools blindly shuffling from one goal to the next. Not too smart, but a major annoyance if you are trying to get somewhere, or get something done.

Yet, as a project manager I have a weakness for zombie films, they appeal to my inner urge to cut down those who impede progress or just don’t get it. I know you can not really do that, and these feelings are more likely a reflection on my inability to communicate effectively, but none the less, a socially acceptable demographic for outpourings of frustration seems to have wide appeal, and box office success.

So, other than some people thinking project managers are lumbering dullards, and this one occasionally thinking of chainsaws, what does the film Zombieland and project management have in common?

• The Insecurity Complex
• The Goal Obsession

In the film comedy Zombieland two mismatched characters team up to survive zombie attacks, find love and pursue a goal. Our hero is Columbus, a socially awkward young man who’s obsessions and aversions in normal life had made him a lonely misfit, now keep him alive in a time when most people have succumbed to zombies. His partner is Tallahassee a hard hitting, shoot first ask questions later, type guy who is driven by an overwhelming desire to find the world’s remaining supply of “Twinkie” cakes.

The Insecurity Complex

An Insecurity Complex is a common feeling for new project managers. Linda Hill describes it well in her book “On Becoming a Manager”. She explains how people who did well in technical and sales roles often struggle and experience “Self-Doubt” when first in a management position.

I attended the Agile Business Conference in London this week and presented on Tracking Project Performance. I missed this conference last year and so it was especially good to catch up with people again and hear what they have been doing. Also, after working in London for six years, but then living in Canada for the last nine years, it is always interesting to see how things have changed since my last visit. This year it was video screens replacing all the paper billboards going up and down the escalators on the Underground that caught my eye.

 

The conference was very good, and had the general theme of “Agile Grown Up”, focussing on the organizational impacts of using agile. This may not have been as much interest to technical people, but was right up my street. On Tuesday there was a great session about agile at Nokia where 1800 software developers are using agile to develop the Symbian mobile phone platform. They are using a version of Dean Leffingwell’s “Agile Train” approach for scaling agile to such a large team and most agile practices, but not pair-programming or emerging architecture. However, the main emphasis was beyond the technical process scaling and more on the ongoing coaching, mentoring and training that is required for such a large undertaking. In a discussion with the presenter Simon Buck after the talk I learned that they aim for one full time coach/trainer for each set of 5 Scrum Teams (each about 7 people). Quite the undertaking.

For the attendees of my recent Las Vegas course, below is a link to the PMBOK v4 to Agile mappings we discussed. My previous course material mappings were based on PMBOK v3, and before that the 2000 edition, which are out of date now.

 

Quite a lot changed from the PMBOK v3 to v4; all the processes were renamed into the new verb-noun format. Six of the old processes were merged into four new ones, two processes were deleted, and two new ones added. So it seemed like time to redo the mappings and post them online this time.

 

Cautions

Process guidelines and templates are not an acceptable replacement for common sense, thought, dialog, or collaboration. A fool with a tool is still a fool, but can be especially dangerous since they give the impression that they have a potential solution to tricky problems. Beware of simply following any project guidelines that seem counter to your objectives.

 

So, why would you want to be mapping the PMBOK v4 to Agile techniques anyway?...

The Calgary Agile Project Leadership Network (Calgary APLN) 2009/2010 season kicks off this week with a social at the Barley Mill in Eau Claire, Thursday Oct 1, 4:30 – 6:30pm.

“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 chance 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.