The Dangers of Visual Project Management

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

Optical Illusion

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

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

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

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

Continue reading "The Dangers of Visual Project Management" »


Helping Your PMO Help You

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

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

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

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

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

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

PMO Agile Coordination
 

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

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

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

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

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


It is not the Process, Stupid

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

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

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

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

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

Sense making – agree information gathering steps and prioritize exploratory work

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

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

Prioritization – build mindful to risk reduction and business value

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Posting Update

Thank you for visiting my site or subscribing to this feed. Regardless of how you access this content thanks for your patience. I have not been writing recently, instead using my spare time to enjoy the great summer weather we have had here the Canadian Rockies. However that is about to change, I intend to post more frequently and am excited about the new content, training courses and opportunities I have planned for the fall.


Thinking Tools for Scaling Frameworks

Light bulbsScaling agile is a hot topic these days. Frameworks like LESS (LargE Scale Scrum), SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) are in the limelight as too are companies training up ‘’Agile Transformation Consultants’’ to transition entire organizations to agile. However, successful scaling is not easy, it is one thing to put a company through a week’s worth of training and mentoring, but another completely to make lasting changes to working practices and resolve all the issues that get surfaced along the way.

 The logic is simple, when executives see a successful agile project their initial thoughts are often: “Great, let’s do more of this!”, yet the solution is complex. Solving the simple question of “How do we reliably duplicate exemplary performance?” is anything but simple.  Moving from one or two successful agile projects to transitioning an entire organization to use agile methods is a challenging and daunting task.

Factors such as people who do not understand the problems with current practices and a lack of agile thinking are difficult issues to overcome. Strategies for transforming an organization to agile vary. Some favour a top-down education process, others a bottom-up, grass roots initiative.

Should the approach be Buddhist (teach the principles and allow local adaptations) or more like Catholicism (everyone must follow a strict standard protocol)? Insights into these concepts of scaling up agile can be found in the book “Scaling Up Excellence: Getting to More Without Settling for Less” by Robert Sutton and Huggy Rao. 

The authors describe this Catholic vs Buddhist split along with strategies for bridging the two. The In-N-Out Burger chain popular in California takes a very Catholic view to replication where common practices are replicated with very little deviation. This is akin to proclaiming all teams will follow Scrum by the book. The KFC food franchise on the other hand, allows lots of local customization and sells egg tarts and soy milk in its stores in China that are not offered in other countries. This is like explaining the agile manifesto values and principles and allowing variations in team implementation.

There are times when the need for local uniqueness is obvious. Stanford researches tracked a software company who opened offices in Silicon Valley and India. The Silicon Valley offices had bare concrete floors and rough unfinished surfaces to provide a funky, urban-contemporary look. Yet in India rough finishings send a different vibe and some locations have more dust and are impractical for women wearing long saris that quickly get dirty as they drag along the floor. So the company quickly dropped its Catholic approach and installed carpeting.

There are also times when people can suffer from “delusions of uniqueness” when they think they are “special” or more unique than they really are and miss out on some improvement. Brigham and Women’s Hospital had very high rates of doctor customization occurring in its selection of joint replacement products despite no evidence suggesting these new products were any better. It seems doctors just enjoyed trying out new technology - a problem common to many industries.

It is possible to bridge the two poles of Catholicism and Buddhism by using swappable sub-assemblies. Like reusable chunks of Lego, these proven successful components can be used to quickly get the benefits of some standard process while allowing for local customization.

In an agile setting this could be as simple as moving the 9:00am Stand-up meeting to 11:00 to ease co-ordination with a West Coast team, or more sophisticated such as swapping iterations for a continuous pull of features via kanban and DevOps in a high change environment.

When discussing the top-down education or bottom-up change, Sutton and Rao assert that success comes from a ground war not just an air war. During World War 2 commanders often called in bombing raids with the hope of devastating the enemy. Unfortunately only 20 percent of bombs dropped fell within 1,000 feet of their target. More recently with the advent of GPS and laser targeting it is easy to think air wars are now effective. However a review of NATO’s seventy eight day air war on Serbia to stop ethnic cleansing by Slobodan Milosevic concluded it was “a major blunder that the use of ground troops was ruled out from the beginning’’.

All the research and case studies in Scaling Up Excellence find that “Scaling requires grinding it out, pressing each person, team, group, division or organization to make one small change after another in what they believe, feel or do.”

Air assaults are often useful first steps, but are rarely long term solutions. More often, territory must be won inch-by-inch working through issues as they are encountered. This requires persistence, lots of work and slow progress to reliably instill a new way of thinking and working.

For these reasons we should be wary of “agile transformations” that claim to transition an entire organization over a 2 week or 2 month period. This is more akin to an air battle. Yes, maybe everyone in the organization was exposed to some agile training and this is a necessary step, but true understanding and adaption only come through use, failure, learning and growth which take much more time.

Before planning to scale agile (or any other approach) discuss the “Catholic vs Buddhist” and “Air-war vs Ground-war” concepts with those who will be engaged in the rollout. Learn to detect Delusions of Uniqueness and employ Lego Bridging Strategies. These techniques can avoid “Clusterfugs” - an enterprise friendly word used to describe a poorly received transformation and instead can pay huge dividends.

[I first wrote this article for ProjectManagement.com here]


PMI-NAC Conference

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

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

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

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

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

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

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

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

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

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


Are Virtual Teams the Next Revolution of Work?

Virtual Team T ShirtVirtual teams may well be the next step-change in the evolution of work. So it is interesting to ask if today’s management principles and processes are optimized to support them? To help answer this question let’s take an illustrated tour of work through the ages and also review how management has progressed along the way.

Work patterns have evolved through revolutionary and evolutionary waves. Some have brought major, irreversible shifts; others step-changes and refinements. Tens of thousands of years ago population densities were generally low as people worked at farming, fishing and still some hunting and gathering. You needed space to do this and too much local human competition was not helpful. Then, as crafts, trading and specializations emerged towns became useful hubs for exchanges and population patterns changed. Access to fresh food sources was still a major concern, but trading and money allowed for easier centralized living.

These were slow, likely imperceptible advances, quite unlike what happened next with the Industrial Revolution of the 1800’s. People were needed to work in factories and a major migration from rural to city living occurred within decades. Factory funded schools began focusing on time keeping, discipline and following instructions to better condition children as future workers. The Victorian work ethic promoted by many leading entrepreneurs was a useful conditioner for taking farmers, who were used to working following the daylight hours and seasons, and adapt them to a regular 7:00am to 7:00pm work days favored by factory owners.

How industry shaped cities is also an interesting topic. Steam engines where large machines that could only transmit power via shafts and belts over relatively short distances.  So early factories were tall, square buildings to maximize machine capacity within close reach of the steam engine. Electrification made power easy to transfer and factories became long, low structures that were cheaper to build and required less lifting of materials. As work patterns evolved so too did our industrial complexes from tall to sprawling.

Shown below is a picture of the moving production line at Henry Ford’s Piquette plant completed in December 1913.  This approach to manufacturing, generally known as progressive assembly, heralded a major increase in productivity that was adopted by most manufacturing industries. It was inspired by the time-in-motion studies done at the Bethlehem steel plant by Fredrick Taylor which showed increases in efficiency for specialized labor. Ford was the first to employ moving production lines and specialized labor on a large scale to increase productivity and drive down costs.

Model T Assembly

Photo Courtesy: Ford Motor Company

We still see examples of these decomposition principles today when software project work breakdown structures reduce complex systems into small components and assign “Developer 1” and “Developer 2” type resources.

The next photo shows the Tesla production facility at Freemont California.

Tesla Assembly

Photo Courtesy: Tesla Motors

The Tesla factory has a rich history of manufacturing and management evolution. Starting out as a General Motors Freemont Assembly plant in the 1960s it embodied the modern interpretation of production line thinking. A downside of working in a specialized labor role in a highly mechanized environment can be a feeling of being a machine yourself and the plant suffered many worker disputes and union clashes during the 1970’s and 80’s. There were reports of deliberate protests and cars being sent out with Coke bottles in the doors to rattle and annoy customers.

Relations broke down and the plant was closed in 1982 only to be reopened in 1984 as a joint Toyota / General Motors plant known as New United Motor Manufacturing Inc (NUMMI), rehiring many of the same disgruntled workers. Toyota introduced lean manufacturing processes including respect for staff and empowered workers to stop the line if problems were encountered. The Japanese / American relations during these transition years created many stories and was the motivation for the comedy movie “Gung Ho” that Toyota later used in training sessions of how not to motivate American workers.

The switch from traditional manufacturing using production lines and large inventories of materials and sub assemblies to lean, just in time (JIT) production systems was driven by new philosophies of management. Lean and JIT techniques follows the work of James Womack, Peter Senge and Eli Goldratt who reposition management from schedulers and task masters to identifiers and removers of impediments to workers. They encourage and reward team problem solving and promote continuous improvement.

As capitalism and the pursuit of labor cost reduction continued, many manufacturing plants moved to cheaper labor markets. North American and other previously industry focused countries saw a rapid drop in local production. In their place however we saw an increase in design, finance, research, health and education services. This was the birth of what Peter Drucker called the Knowledge Worker – professionals with subject matter expertise that work together to solve new or novel problems.

These three big shifts in work are shown below:

Evolution of Work

Picture Courtesy: www.LeadingAnswers.com

In 2009 the joint venture between GM and Toyota at the NUMMI plant ended and neither company could find a suitable use for it. In 2010 Tesla, then a startup Electric Vehicle research and development company struck a deal with Toyota and bought the 380 acre site previously valued at $1Billion for just $42M. Toyota also invested $20M in stock of Telsa and some of the Toyota staff were rehired as more traditional industrial work gave way to newer exploratory knowledge work.

Agile methods are very effective for knowledge worker projects. They provide Sense-Making activities for gaining consensus from diverse stakeholders during the early stages of projects where uncertainty is high. They also provide tools like short iterations of build / feedback cycles to help reduce risk, prove approaches, and surface deficiencies in designs when tackling novel problems or using new technologies. Finally, they have process adaptation and goal seeking reviews built into their operation that helps teams refine their approaches and work more effectively.

Yet the changes have not stopped. Now with the widespread adoption of email, video conferencing, real-time chat and an emerging workforce who “grew-up-digital” and fully embrace these technologies, virtual teams are poised to revolutionize work once again. We just discussed the car industry, but it is telling that for the first time ever fewer teenagers who are becoming eligible to drive are buying cars, the cost of ownership is perceived as too high, but don’t try and take away their smart phones! Maybe since communications are so easy and prevalent, texting your friend is easier than driving to see them?

One thing for sure is that talent is distributed and technologies for finding and linking teams is improving rapidly. If I want a logo designed or web site built I can log onto a freelance site like Guru.com or Elance.com and access a global marketplace of talent showing examples of their work and hourly rates. Escrow services exist to ensure work and payments occur fairly and help with arbitration if the need arises. Or, if I want a custom door handle or even a titanium bicycle I can download the design and print it in my home or at a local 3D Printing shop.

What these technologies mean to how we work and live in the future remains to be seen. Alvin Toffler wrote about the “Electronic Cottage” in his 1984 book The Third Wave that describes people living where they want in a future paperless society and communicating electronically. Many of the technologies we need for wide scale virtual teams working are in place but we need to overcome the C.U.T.E. problems:

  • Communications – how do we meaningfully communicate complex issues across geographically dispersed teams with different languages, time zones and cultures? How do we clearly articulate requirements, issues and feedback in universally understood ways?
  • Unity – How do we instill a sense of team in people who have never physically met? Why would people be motivated to go beyond their regular roles to help out people they have only seen on a computer screen? Remote working is easier with people we have previously worked with physically, but such relationships may be the exception in the future.
  • Trust – How do we build trust that people are working when remote? How do we strike the balance about remote work monitoring tools and trusted, empowered teams? How do we overcome differences in laws and ethics on a world scale?
  • Economics – How do we fairly compensate team members based on their skills and contributions? How do we effectively price, tax, invoice, collect payments and pay contributors on projects that may only take days or hours to perform?

The building blocks of each solution are already available. Video conferencing with real time translation, peer based endorsement networks, community voting, and bitcoins all might play a role. However what about our project management tools? Where do Microsoft Project plans, PMBOK Guides and Stage Gates fit travelling at the speed of trust?

In a poetic twist of fate, just as Victorian classrooms were engineered to condition children to the discipline of working in textile factories, maybe the Instagram, Facebook and text messages of today’s school children will shape the workforce and workplace of our future. Using these tools and their replacements, virtual teams will be the norm, today’s CUTE problems will be overcome and a new era of work practices introduced. If the past is anything to go by these changes can happen quickly so we should keep our eyes and options open!

[Note: This article was written by Mike Griffiths and first appeared on ProjectManagement.com here]


Agility as an Enabler for Local Intelligence

Team intelligenceMuch has been written about agile processes, how they can better respond to changing requirements and be used to tune approaches over time through retrospectives and adaptation. While this is true, it masks the importance of human involvement. It is people that respond to change and teams who update and tune their processes. Agile methods give more freedom and autonomy for teams to do the right thing, but it is the team members that act intelligently to improve things.

Understanding this distinction that agile methods don’t directly help much, instead it is the actions of agile team members, allows us to better explain why some agile projects go well and others do not. Agile processes are an enabler for intelligent action, but not a guarantee of it. Teams that are asked to follow agile methods, but not motivated or equipped to improve the project environment will likely fail.

This is why we often see some agile project teams do very well and others struggling to produce results within the same organization. If you look at the processes both teams are following they look the same. They might both be doing daily stand up meetings, iteration planning sessions, backlog prioritization, demos to the business and retrospectives. However, these processes don’t ensure success; it is the local decision making that comes from them (which we observe in different ways) that lead to successful projects.

The concept of “Local intelligence” is described nicely by Malcolm Gladwell in his book “David and Goliath: Underdogs, Misfits, and the Art of Battling Giants”. Gladwell tells the story of Lawrence of Arabia, an archaeologist conscripted into the British Army in World War 1 who led the Arab revolt against the Turkish army occupying Arabia.

Lawrence’s goal was to destroy the long railroad being built to set up operations deep in the Hejaz desert. The odds were against him, the Turks had a modern army and Lawrence commanded an unruly band of Bedouin nomads who were not trained in combat. However they were mobile and self sufficient they travelled extraordinary distances, attacked quickly and were gone before major battles ensued.

Lawrence is best known for leading a daring attack on the port town of Aqaba. The Turks expected an attack to come from British ships offshore, but Lawrence attacked from the unprotected East desert during summer, leading his men on a 600 mile loop no one thought possible and to anyone but the Bedouin nomads likely fatal.

His success was attributed to a number of factors. First, as a historian and archaeologist he had little regard to traditional military order or standards and that helped with unconventional thinking. Second he made great use of the local intelligence of his men who were very self-reliant and skilled in dessert survival and travel to mobilize and do the right things to be successful.

This enablement of local intelligence is the key to agile success too. The agile process is only a framework, the real work happens in the discussions and decisions made by the team. I used to be concerned by how much time some teams spend talking about work compared to actually doing work until I saw a correlation with project success. The teams that spend lots of time discussing options, priorities and business requests were actually thinking and refining strategies to be more effective. They were using local intelligence to be more successful and it showed in their results.

When my current team stopped holding daily stand-up meetings I was a little concerned. I wondered if we were getting lazy. If the process was devolving and should I intervene? However I trusted they must have had the same thoughts and the frequent discussions both face-to-face and online for remote members negated the benefit in these daily updates. To them these meetings felt unnecessary and low value. So, stand-ups became three times a week then twice a week then more sporadic. We have not had a daily standup meeting for three months now and things are going great.

One practice we are doing extra is a weekly technical show-and-tell meeting so developers and QA’s get to see what people have been working on and ask more technical questions ahead of, and separate from, the bi-weekly business demonstration. I am not suggesting that agile teams drop daily stand-ups and adopt weekly technical reviews. For most agile teams the daily stand-up is core and critical for effective communications between team members.

Instead, my point is that success is more closely aligned with the application of local intelligence from the team members than adherence to agile process. What works for one team may not work for another. As leaders of agile teams we should not be looking for conformance to process but signs of effectiveness and the application of local intelligence. High levels of “productive work related discussion” appear a good sign.

By “productive work related discussion” I mean new discussions that cover fresh ground and solve issues, not Bill and Ted having the same argument about architecture X or tool Y. Ask if the discussions result in solutions, are they business results focused, and inclusive to all team members that want to participate? These are indicators that they are productive.

In addition to productive discussion, team led modification of process is another sign of local intelligence applied. The fact the team diagnosed, discussed and agreed on an amendment to regular working process is a good indicator that they are applying local knowledge. Alistair Cockburn’s Shu, Ha, Rei model, describes a progression from obeying the rules (Shu, which means to obey, or follow), consciously moving away from the rules (Ha, which means to break or change), and finally unconsciously finding an individual path (Rei, which means to separate, or release).

Organization adopting agile and teams using agile methods are encouraged to first “use it out of the box” i.e. without modification. Then, only when everyone understands why things are as they are might we want to change process. Many of the agile processes balance each other. Rigorous testing allows for light documentation for instance. Dropping one without addressing the other and you could be headed for trouble.

However, in my view agile processes are a default starting point for teams. They work well and cover all the basics. Yet if the team sees a problem, or an opportunity for improvement then we should not stop them trying to become better. Iterations provide short test cycles to try new approaches and revert back if they are not working or build on success if they are.

When leading teams look for and encourage high levels of engaged debate and productive discussion. Support team based process adaptations and change. They are both signs of an engaged team applying local intelligence to improve their ability to deliver. Agile methods should be enablers of change not strict frameworks to work within. Our goal is performance not conformance so we should provide support and encouragement accordingly.

When asked if my team is agile I answer “kind-of, “mostly” or “predominantly” depending on the formality of the question. However I don’t really care about the label, they are kicking butt and delivering a ton of high quality software the business loves, which is my real focus and measure of success. Methodology labels help shorten conversations about process but are of a lower importance than results, we should act accordingly and spend more time encouraging local intelligence - a critical key to success for today’s knowledge worker projects. 

(Note: This post was first written for ProjectManagement.com here)


20 Years of DSDM

20This post is a personal reflection. 2014 marks the 20th anniversary of DSDM (Dynamic Systems Development Method). Ten years ago, back in 2004 I wrote the article “DSDM 10 Years on, RAD Relic or Agile Advocate?”, on re-reading it 10 years later I think it still holds true. It can be found on page 49 of this Agile Times newsletter.

Just looking at the names of contributors to that newsletter (Ken Schwaber, Martin Fowler, Mike Cohn, Lisa Crispin, Ester Derby, Brain Marick, Kent McDonald, Dianna Larsen, J.B. Rainsberger, Barbara Roberts, Linda Rising, Deb Hartmann, etc) reminds me of some of the great people I have been fortunate to work with over the years. Also how lucky we were to have such excellent collaboration from these thought leaders in a single publication. Good luck trying to get them all to contribute to a single conference today let alone an unpaid newsletter!

Realizing I have been doing pretty much the same thing for the last 20 years stirs up a few emotions. First of all there seems a worrying lack of career progression. Today I am managing agile projects along with training, consulting and writing. Back then I was also managing agile projects and consulting. However, just to prove my career councillor wrong - who said I would never go far, I did move from England to Canada which by anyone’s standard is pretty far!

I have tried other roles; I have had several stints as a program manager, development director and in various PMO roles. However I have always gone back to project management. It is what I love and what interests me. I read, on average, two project management books a month and am not getting tired of them. In fact the stack of new books to read on my desk is growing faster than ever.

I just don’t feel the same enthusiasm for program management or PMO work, for me, it is a little too far removed from actually executing projects. It is the problem solving, stakeholder coordination, execution and sense of achievement from delivery that gives me a buzz and keeps me excited about work.

Over the last 20 years the methods that we now call Agile have matured and morphed enormously. The whole Agile Manifesto popularity explosion of the early 2000’s opened up a tide of mostly good awareness and opportunities. Yes, a bunch of people jumped on the band wagon without really understanding things and caused some harm, but the vast majority of growth and adoption that I have seen has been extremely positive.

All in all I feel very lucky, I get to work in a field I find extremely interesting. While many of my colleagues have created large agile consulting and training companies, they now don’t get as much hands on project work. Maybe I lack their entrepreneurial spirit, business drive or sales skills, maybe my career councillor was right, but I can honestly say I’d be really happy to do what I am doing now for the next 20 years. I have no exit strategy planned or dreams of escaping it all.

I graduated in 1986 when the Timbuk3 song “The Future is so bright I gotta wear shades” was popular. From that song the line “Fifty thou a year -- buys a lot of beer” may no longer be true, but It feels to me that agile concepts are just getting started and the future is so bright. Hence, maybe like a family doctor who practices for many years, learning more but still in the same role, I will appease my uneasy guilt of treading water with a justification that is OK and hope I get to continue for the next 20.


Agile Horrors

ZombieI know it is Christmas time not Halloween, but think of it as holiday re-gifting. Here is an article on agile horrors I wrote for ProjectManagement.com Halloween Edition that we should be on the lookout for on our projects in 2014.

Frankenstein Process – This is the methodology designed by committee that tries to combine iterative, empowered development with linear scheduling and command-and-control task assignment. Perhaps created in an attempt to satisfy the desires of competing groups, but this half goose, half salmon abomination neither flies nor swims.

Agile practices are in a balanced network. Ruthless testing balances the need for comprehensive documentation; colocation, demos and daily stand ups reduce the need for detailed status reporting. Changes made to this web of practices can easily create risks, gaps and duplications if they are not carefully considered.

Think candy apples not pumpkin pie; hybrid methods work best when there is a core of agile for the team to own and execute, surrounded by a wrapper of more traditional process to buffer and integrate into a less agile aware environment. Don’t try and glom disparate process pieces together, it becomes a monster nobody loves or defends.

Zombie Projects – some projects should just die but won’t seem to. Doomed from the outset with unrealistic deadlines, overly ambitious scope, or ill equipped skills and support; everybody knows it will not end well, but nobody seems willing or able to kill it.

These death marches to eventual failure or cancelation are damaging to the people working on them who see the futility and mismatch of progress to targets. However, like the emperor’s new clothes there is a shared acceptance that this is unlikely to work, but nobody seems to speak out. Perhaps thinking that the “higher ups” must know what they are doing and would intervene if there are problems; they continue shuffling forward like an army of undead looking for brains.

Unfortunately, there are no brains here and the higher-ups rarely have some cunning plan that turns struggling forward progress into an elegant solution. More often if it looks, smells, and behaves like an undead zombie, it is one. Just like in the movies, it is best not to start shouting and bring attention to yourself if you are surrounded by zombies. Instead try to find an opportunity to exit quietly, see if there is a reset or restart initiative planned. Offer to be part of the solution, instead of bitching about the issues, usually others have reached the same conclusion and are looking for support to fix things.    

Vampire Scrum Masters and Project Managers – These people just suck the life out of things and never give back. Scrum Masters who look for process compliance but do not own or remove impediments; or project managers who push for velocity improvements, but don’t want to hear about quality improvements or refactoring plans.

Agile teams generally work very hard to deliver as many high quality features as they can. When they report problems or ask permission to undertake maintenance work it is so they can be better equipped to deliver high quality features long into the future. Like ignoring a Check-Engine light in your car or missing regular maintenance, you might save some money in the short term but it is a false economy longer term.

Scrum Masters and project managers need to learn enough about their teams and their technical domain to distinguish genuine reports of problems and requests for investment from everyday complaints and unnecessary requests for resume boosting technology upgrades.

Teams who routinely get their requests ignored by leads that just want results without investment will correctly draw the conclusion that they are not valued. When this occurs, the motivation to try hard, delight customers and go the extra mile to overcome an obstacle is removed. The delivery of results will decline and then the whole process sucks.

So, show some interest, ask people to explain why issues and requests are important. If all the solutions are not possible ask them to prioritize. Try as hard as you can to fulfill these requests and usually the teams will reciprocate with improved effort and results.

Product Owner Ghosts – these are business representatives that are kind of there, but not really, they tend to vanish or dissolve when pressed on anything. Whether it is a tough decision on a product feature, or their attendance at a demo; product owner ghosts are unreliable.

The product owner / business representative role is integral to agile processes. They are needed to ensure requirements are understood, refined and prioritized, along with providing prototype feedback and resolving design decisions. Like missing or getting a poor developer or QA person, a project with a “hardly there” product owner will suffer tremendously.

So, look out for signs of less than real product ownership. Warning signs of a non-committed or weak business involvement include:

C - Contrary – decisions flip-flop with no clear explanation

A - Absent – you cannot find them or get their time when needed

S - Switching – the person changes, no dedicated product owner is assigned

P - Passive – without prompting we would not hear from them for long periods

E - Elusive – they will not provide clear feedback on the suitability of a prototype

R - Reclusive – they withdraw from priority discussions and decisions

Instead try to staff projects with product owners who exhibit more solid, proactive business representations.

C – Collaborative – willing to discuss and evaluate alternative solutions

O – Owners – owning the backlog of work, taking reasonability for its grooming

N – Nearby – available when required to ask questions and get clarifications

C – Committed – having the same person or people throughout the project

R – Representative – representing the group we are building for, not personal goals

E – Expert – knowledgeable about the domain at hand to answer team questions

T – Traceable – contactable when needed or with a proxy available if away

E – Experienced – experienced in the field to warn of outliers and exceptions

(I prefer these attributes over Barry Boehm's CRACK mnemonic that does not emphasize the Nearby, Experienced and Expert qualities that can really save teams time.)

Getting the best users is always difficult since the best people are busy doing real work. Try to explain the costs and risks of building the wrong or a sub-optimal solution. Offer to back fill admin work from the project for the best people even just to free up some of their time each week for input and feedback.

Summary

Hopefully this light hearted view of some agile anti-patterns in the guise of Halloween ghouls reminds us of things to be on the lookout for. Unlike Halloween these problems are year round threats. More than just something that goes bump in the night, these problems are ever present in our lights-on projects. Look out for them and use your garlic and silver bullet awareness to keep them from impacting your projects.

 


Agile Requirements Uncertainty

Requirements
<I wrote this article first for ProjectManagement.com here as part of their Requirements series>

Agile approaches are often used on projects where the end goals are not fully known or may change during the life of the project. This seems unusual to my engineering PM friends who manage the fabrication of facilities. To them, not knowing what it is you are supposed to be building or letting things change along the way is a sign of poor scope definition, requirements gathering, and change control. I hear quips from them along the lines of: “You guys need some rigor and decent specifications, maybe then you could build IT systems that work and don’t go over budget!”

They are right of course, for their domain of defined repeatable projects; first establishing a well formed scope definition and complete specification is the way to go. However, many IT projects are not defined, repeatable endeavors, but instead design explorations into unchartered territory for that organization. The mix of technology has not been used that way before. Sponsors have a vision of the end state, but not a lot of specific detail. No matter how much upfront work is done there seems a host of unknown issues that surface during the journey to the destination. Build/ feedback cycles with adaptive plans and progressive elaboration of requirements is the way to deal with these inevitable uncertainties.

These intangible, unprecedented, emergent, evolving characteristics of IT projects are difficult to explain, but need to be understood. They impact how we plan and execute today’s knowledge worker projects as well as how we should manage requirements. When the specifications are clear such as “A kitchen reno with new counter tops and appliances” then simple, signed off requirements can work well. Yet when things are more vague such as “A winter vacation to someplace warm” remaining flexible to changes and new ideas can be valuable.

Let’s look at some of the differences between plan driven, traditional practices for requirements management and those used in agile methods:

Requirements table

Learning and applying traditional methods of requirements management is easy, it is akin to a shopping list approach. We ask questions like “Did you get milk?”, “Did you get the bread?”, “What else do we need?” Changes may be declined or accommodated. “Billy wants some chocolate!” too bad, tell him he can’t have any, or “Oh, I remember we need light bulbs!” We can then ask do we have enough money for light bulbs, do we have time to go find them, etc. It is all pretty much second nature.

Agile requirements management on the other hand is less intuitive. The constant reprioritization, comparison of new ideas with remaining features, and focus on business value has more balls in the air. Like packing a backpack for a multi day camping trip we are always weighing up the benefit verses the size / weight penalty of bringing something along while keeping an eye on an ever changing weather forecast. There is more re-evaluation, more substitutions, more “Do you really need it?” type questions.

Traditional requirements management has a more satisfying progression of closure – Feature A is in the signed off spec, so we are doing it! This is like saying it was on the shopping list so we will buy it. The fact that it may then sit in a cupboard and never be used is a separate discussion. Agile requirements management lacks this reassuring closure since all remaining items are up for reprioritization or substitution until the completion of the project. Our shopping list is being changed as we walk around the store and that makes some people uncomfortable. However, fewer items should go unused.

In the end it comes down to trading off certainty against flexibility and value optimization within your purchasing decision. If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs.


Mike Griffiths Receives “PMI-SAC Fellow” Award

Fellowship AwardOn November 12, 2013 Mike was presented with a PMI-SAC Fellow award at the PMI-SAC Awards Gala. The Fellow Award recognizes and honours members who have made sustained and significant contributions to the project management profession and the Institute for more than a decade.

Mike was recognized for his work developing agile project management techniques and promoting agile project management including:

Mike is very grateful to receive this award and hopes to be active in the next 10 years of project management promotion and development.


Overdue Update and Designing the Pontiac Aztek

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

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

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

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

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

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

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

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


9 Ways PMOs Can Help Agile Projects

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

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

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

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

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

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

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

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

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

(This article first appeared at projectManagement.com here)

Next PMI-ACP Exam Prep Class with Mike Griffiths

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

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

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


Methodology Wars – Contradictory Constraints or More Options?

Methodology WarsSome rifts are occurring in AgileLand - a world supposedly driven by cooperation, trust and appreciative inquiry! Debate is arising about first generation agile methods (XP, Scrum) and newer upstarts like Kanban and the Scaled Agile Framework (SAFe). Perhaps because market shifts carry training and consulting revenue with them, but a few people don’t seem very happy, as evidenced by some recent blog posts.

Ken Schwaber’s UnSAFe at Any Speed article describe SAFe as a RUP based dinosaur focussing on processes and tools rather than individuals and Interactions. Ian Mitchel summarises the Scrum vs SAFe debate well in his piece Method Wars and speaks to his own SAFe experiences.

David Anderson wrote a post on how Kanban is Anti SAFe in the way the two methods approach adaptation for an organization. He describes SAFe as a collection of (somewhat outdated) software development best practices that you engage an expert or team of experts to tailor for your organization. Kanban on the other hand is based on the idea that knowledge workers know more about their domain than their supervisors or outside experts do and should therefore be the people selecting and tailoring the approach.  So, instead of using experts to select and tailor process, the team does this work as part of the innovation culture fostered by Kanban.

Alan Shalloway describes Why Net Objectives Supports SAFe; they are a SAFe Silver partner organization, and believe it offers a proven, documented approach to scaling agility that is underpinned by sound lean and agile principles.

When I read these different accounts I find myself agreeing up to a point with each perspective. I don’t go quite as far in my beliefs as each author, but if I was talking to the authors I’d probably just nod and bite my tongue for the small portion I feel they are pushing too far. So does that make me a hypocrite, or an easily persuaded novice?

Feeling a little uncomfortable, but not caring enough to worry about it too much since I’d rather be solving business problems rather than debating religious wars that rarely deliver much value, I found an explanation from an unlikely source. A friend had sent me a link to a DiSC Leadership profile tool, it asks a series of questions about your preferences in a leadership role and generates a nice report on your Leadership style.

My assessment indicated a “D” Dominance preference for Getting Results, Taking Action and Offering Challenge.

DiSC 1

 The tool lists some good tendencies of having a strong drive to:

  • Achieve results
  • Overcome  obstacles
  • Get things moving
  • Work towards challenging goals
  • Convincing others

The assessment also pointed out some potential negative traits including:

  • Problems following strict rules and protocols
  • Performing routine tasks
  • Getting bogged down in inefficient procedure or meetings
  • Things that slow down your pace
  • Dealing with people who don’t meet your standards

Generally I am not a big fan of personality profiles, perhaps I hope to be not as stereotyped or easy to categorize as they suggest. I like to think people are unique and multifaceted, but this DiSC Leadership assessment summarized my tendencies very well and helped me understand why I feel the way I do about agile, Kanban, SAFe and even the PMBOK Guide.

Basically I am more results driven and will employ and adapt whatever tools and processes I think will help me achieve those results. As I have said before, if abandoning agile principles and instead wearing silly hats got my projects done better, I would be all for it. Instead however building motivated, empowered teams and championing smart behaviour from all stakeholders through servant leadership and savvy project management is the best I have so far.

So, when I look at the SAFe framework I don’t see too many problems, but instead tend to employ the elements I think suitable to solve my current project’s issues. Due to my “Problems following strict rules and protocols” I probably would not engage SAFe consultants to guide its implementation, but instead discuss the framework with the team and gain consensus for elements to incrementally trial. Being told “That’s not how we do it” or “The PMO has a different standard” tend to fall into my blind spot of “Getting bogged down in inefficient procedure or meetings”, “Things that slow down your pace”, and “Dealing with people who don’t meet your standards” etc.

I do see that these are weaknesses I should work on, but I am hired to get results and deliver value. When this occurs without breaking too many rules or upsetting too many people I call it a good day. I see bending rules and flexible interpretations of process as an enabler of value delivery. For example, in the recent upgrade from the PMBOK v4 Guide to the PMBOK v5 Guide some new “Subsidiary Management Plans” were introduced, but I see this as a boost for adaptability not more control or rigor to follow.

The new PMBOK v5 Guide processes:

  • 5.1 Plan Scope Management
  • 6.1 Plan Schedule Management
  • 7.1 Plan Cost Management
  • 13.2 Plan Stakeholder Management

These could be interpreted as more Draconian control of how we manage scope, schedule, etc. However I see them as my opportunity to tailor the process and define a more lightweight, adaptive approach.

Since the goal of “5.1 Plan Scope Management” is to “… describe how the project scope will be defined, developed, monitored, controlled, and verified” here is my opportunity to explain that we will be using  a vision statement and prioritized feature list instead of a WBS to better support reprioritization and accommodate changes.

Likewise, the new process “6.1 Plan Schedule Management” is a great place to explain the use of release plans, iteration plans and story maps. In my half-full world, these new processes are there to help us be more agile or whatever we need to be (perhaps more structured for your project) in order to be successful - they support tailoring and specialization.

So, where does this all leave us? Well, I found a way to justify my methodology indifference and explain my disregard for rules or process. Maybe your DiSC profile can help explain your feelings towards these recent methodology debates. Likely if you are more of a DiSC "CS" style you would have a different view and very strong opinions about their importance.  Please let me know what you think.


Planning Balance

Planning BalanceLife is all about balance, live too conservatively and you run the risk of missing out on life’s adventures and opportunities. Live too wildly and you run the risk of misfortune and regret, we have to walk a fine line guided by our personal view of where that correct boundary is.

Planning is similar; the adages of “Look before you leap” and “Cross that bridge when we come to it” speak to the differing views towards project planning. However, instead of being guided by some moral compass, we should be guided by the quality of our planning inputs and likelihood of changes.

To some people a mentality of “Cross that bridge when we come to it” strikes them as the irresponsible abandonment of project management rigor and fiscal responsibility trusted to them by project sponsors. Why would you not always do as much planning as possible before starting a project? Surely, that is only right and proper! Well, not if doing so would be harmful, it all depends on the quality of that input data. When the input data is good, we can reliably plan, when the input data is bad, or the project’s final destination is likely to change then we need to get better data and keep evolving the plans.

When aiming at a fixed target it is appropriate to aim, aim, and aim some more and then fire. In the project world this is akin to plan, plan, and plan some more and then execute. However, when trying to hit a moving target this approach is ineffective. Where do you aim? Where the target is right now, where you think it might be next, where you hope it might be at completion time? Instead a different approach is needed; something more like a guided missile that makes many mid-course adjustments to hit a moving target.

When we know our project requirements may change, or there is technological uncertainty, or market volatility from competing products, we need to equip the projects with the abilities to make multiple mid-course adjustments. Instead of plan, plan, plan we point the team in the right direction, get them started and give them the tools and authority to make these mid-course adjustments through build feedback cycles to hit that moving target.

Jim Highsmith says it best, there are times when “You cannot plan away uncertainty; you have to execute away uncertainty”. It is not really in the best interests of the sponsor to consume project time and budget trying to plan something with incomplete or erroneous data. It would be more prudent to get closer to the problem, try a few things and then come up with a better plan now we have more information.

Yet this idea of doing less upfront planning presents a large obstacle to many stakeholders because the words we often use to describe exploratory information gathering are poor. For a start we don’t often call it “exploratory information gathering” instead using phrases like “we will build a small portion”, “start coding”, or “do a spike”. To people not familiar with why we are doing this work it seems counter intuitive and rash. So, we can do ourselves a favour and use words like “more data gathering”, “proof of concepts” and “options exploration” instead of “development” to explain the goal of this work.

Another tool we can use to convince the skeptics that less upfront planning is sometimes better value is the planning-risk graphs developed by Barry Boehm. The first risk presented by Boehm is the obvious risk of not doing enough planning and running into problems of people not knowing what they are doing, duplicating work, and building poor solutions that need to be corrected.

Planning Balance 1

From the graph above, we can see that as more time is invested in planning, the risks due to inadequate plans reduce. While these risks are intuitive, there exists another set of risks that are less intuitive or obvious; the risks of doing too much upfront planning. 

Planning Balance 2

This second, red line denotes how the risks of creating very detailed, brittle plans that do not survive contact with reality increase as we spend more time planning. So too do the risks of delaying the project and getting a late Return On Investment (ROI) because the project spent too long in the planning phase.

Continue reading "Planning Balance" »


Mike Griffiths to Present at PMI Global Congress in New Orleans

PMI Global Congress 2013I will be presenting a paper at the PMI Global Congress in New Orleans, October 27-29. Entitled “21st Century Risk Management: Supporting Mathematical Analysis with Social Influence” it is about bringing the local influence of people and persuasion to the analytical world of risk management.

All too often risk management is treated as a dispassionate science of probabilities. However projects are people oriented with risks (and opportunities in particular) being greatly influenced by behaviour. Experiments made in moving risks and opportunities from the methodical risk analysts and project managers to social “project charmers” have shown great results in risk reduction and opportunity exploitation. This partnership between math and social influence seems to be a winning combination and the presentation explains some case studies where this has been applied with great success.

I hope to be presenting the session with Dennis Stevens who shares many of my views on agile risk management. I have worked with Dennis on a number of initiatives including the PMI-ACP certification and the Software Extension to the PMBOK Guide. I enjoy Dennis’ sense of humor and depth of knowledge. I am really looking forward to the event.

Shown below is the outline description for the paper:

21st Century Risk Management: Supporting Mathematical Analysis with Social Influence

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

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

This session explains the need for proactive risk management through an examination of the “Flaw of Averages”, it walks through the risk management process examining traditional and lean/agile based processes. Then the importance of social influence in risk mitigation is explored. Using case studies, a shared team approach to risk management is described. Through collaborative games, new risk visualization techniques, and empowered teams, examples of risk avoidance and risk mitigation actions are examined.

21st Century risk management should be a whole team activity facilitated by the project manger or risk analyst. Not only is relying on a single person to identify and analyze risks and opportunities inadequate, it also represents an unacceptable risk of its own.  Also, often there is a mismatch in personalities between the people best able to analyze risks and those best able to influence them. A new framework that leverages people’s strengths while optimizing the whole value stream is presented. 

Agile For Oil and Gas - mixing lifecycle models

Considering Alternative LifecyclesIntroduction

This post is about Implementing agile at the organizational level across multiple technical domains. I was in Bogotá, Colombia recently working with an oil and gas company to introduce agile to their organization. They were not looking to improve their IT delivery, they were seeing if it could bring benefits to their whole business value stream. Since moving to Calgary 13 years ago I have worked with many oil and gas companies, they are the major employers here and the predominant industry. Lots of energy companies employ lean approaches to exploration, facilities creation and operations to maximize efficiencies and optimize the value stream.

Applying agile techniques to lean processes are a natural compliment and fit especially well with the unique problem solving and collaboration needed to undertake complex projects. Yet, oil and gas projects present a mixture of both these knowledge worker challenges that are a great fit for agile, and industrial engineering that requires traditional approaches. The real benefits come in knowing how to mesh these approaches together and provide some mental models to facilitate planning and problem solving. This is still an emerging field and I don’t think we have all the answers yet, which makes it challenging and rewarding. At the end of the post I outline some questions that I am trying to solve.

The Bigger Picture

Oil and gas development is a long value chain engaging many different groups with unique specializations. Like designing a new car, bringing it to market, producing it, selling and then sustaining it, the skills needed along the way are diverse and often conflicting. Oil and gas development includes the following disciplines:

  • Surveys – identifying areas with favourable geological conditions.
  • Surface Rights Negotiation – arranging for land access with land owners, environmental surveys, native and community outreach.
  • Exploratory Drilling – verifying the presence or absence of hydrocarbon reserves and quantifying the reserve.
  • Facilities – creating the infrastructure for oil or gas extraction, initial processing and transportation to market.
  • Operations – managing the safe extraction and operation of the well and associated facilities. Performing maintenance and projecting production declines and decommissioning work.

Oil Lifecycle

 Mixed Project Types

Some of these activities like the collaborative work of the G & G groups (Geologists and Geophysicists) are classic knowledge worker activities. Here specialists with subject matter expertise come together to share information and as a group and build consensus on the most likely areas for further exploration. No two regions are the same, no two geological formations are the same, and just like software teams use agile methods to collaborate on solving complex problems and gain consensus on the direction to move in, so too do G&G teams.

Further down the chain though, some pieces of work can be more traditional in nature. After determining an area to explore, the execution of a seismic survey might involve mobilizing a large workforce of several hundred people and scheduling constrained equipment. While this can be done in an iterative, prioritized manner, many of the benefits of short iterations, reviews and adaptation are diminished so a hybrid approach is preferable.

Agile Processes

Surface rights negotiation and exploratory drilling are very much expert driven, collaborative problem solving exercises. Starting the process with incomplete information and uncertainties is the norm. There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty. Activities progress with the acknowledgement of ambiguity and proceed through stages of:

1) Embrace ambiguity – getting stakeholder agreement of areas of uncertainty

  • List areas of uncertainty
  • Discuss and agree known scope boundaries

2) Sense making – collaboratively forming consensus on exploratory work to undertake

  • Agree information gathering steps
  • Prioritize sense-making exploratory work

3) Iterate through cycles of Plan, Explore, Learn, Adapt – Learn by doing rather than speculate via planning

  • Plan – agree and assemble work plans, guidelines, objectives
  • Explore – undertake short period of exploratory work
  • Learn – collaboratively analyze findings and gather results
  • Adapt – retune upcoming work plans, incorporate learnings

4) Maximize value – once it is agreed that the “Next Best Dollar Spent” is elsewhere on the project AND the iterative learnings have been maximized, finish the experiments

  • Gain consensus that the exit criteria has been reached
  • Articulate findings, learnings and decisions

Agile Lifecycle

Continue reading "Agile For Oil and Gas - mixing lifecycle models" »


Promoting Shared Leadership

GeeseAgile methods suggest replacing top-down, command-and-control management with empowered teams and shared leadership. That all sounds nice, but what exactly is shared leadership and how do you get it to happen?

Katzenbach & Smith authors of the book “The Wisdom of Teams” explain that shared leadership can occur “where a small number of people with complementary skills who are committed to a common purpose, performance goals and approach for which they hold themselves mutually accountable” - in other words, when we have a well formed team with a strong sense of commitment. In these circumstances team members know that they possess the technical knowledge necessary to make the best local decisions and will self-organize and encourage each other to achieve results.

Examples of effective shared leadership include the Orpheus orchestra that I wrote about in 2008. The Orpheus orchestra has no assigned conductor, instead performers rotate the role, providing unique perspectives and also broadening their experience. Unlike your first guess, this conductor-less orchestra does not sound terrible, but instead have won a number of Grammy awards and perform to sold-out audiences worldwide.

The other classic example is geese flying in “V” formation that reduces drag and extends daily flight range by up to 50% compared to individual birds. All birds take a turn on the front, maintaining direction and parting the air for the following birds. The rest of the flock “honk” encouragement at the lead bird to keep up the speed and when it tires it returns to an easier position in the “V”. If any bird gets too weak or injured, usually two other birds will drop out of formation to rest with it and form a new “V” once it is ready.

These examples are used because they easily show the advantages, but they do not hint at how to transform a dysfunctional group or even normal team into a high performing team using shared leadership. The good news is that providing you have some patience the process is achievable and within your control.

We have to start by understanding and believing in the benefits of leadership ourselves. Jeffery Pinto author of “Project Leadership: From Theory to Practice” describes these core leadership practices:

  • Willingness to challenge the status quo – Search for innovative ways to change, grow and improve, experiment and take risks by constantly generating small wins and learning from mistakes
  • Creating and communicating a vision – sharing your ideas of where we could be
  • Modeling desired behavior – acting honestly, admitting where we lack information, being passionate
  • Enable others to act - Foster collaboration by building trust and strengthen others by sharing power
  • Encouraging each other - Recognize contributions by showing appreciation for excellence and Celebrate the values and victories by creating a spirit of community

Continue reading "Promoting Shared Leadership" »


Agile for Fragmented, Part-time Teams

VolunteersI have a client who uses lean and agile-like processes outside of IT on research and development projects. They have been doing this for a number of years to help optimize constrained tools (drilling platforms) and resources (specialist inspectors). They like the agile concepts of prioritizing based on business value, working in short cycles, expediting rush jobs and frequently validating results and adaptation.

Recently they asked for help with some improvement initiatives that use multi-disciplinary teams to investigate and improve cross-department processes. These groups are staffed by senior engineers who volunteer to help make improvements, but the work is low priority and their time extremely limited. They are also geographically dispersed. Obviously that creates problems for agile practices like daily standups if team members get on average of two to four hours per week to contribute on an initiative.

At first I saw lots of challenges--agile promotes dedicated teams (co-location where possible), daily conversations with business stakeholders, etc. These groups had none of those things, yet three months later they were pleased with the successes they had. It seems when you are trying to coordinate the work effort of distributed, low-availability resources, the structure and visibility of tasks that agile brings is a great strength.

This somewhat counter-intuitive application makes more sense when you consider how such improvement committees traditionally function. Historically, similar work groups had faltered and failed to deliver benefits. The company was mature enough to look for inter-departmental improvement opportunities, but because it was no one’s full-time job (and they spanned departmental jurisdictions), work started but then failed.

Continue reading "Agile for Fragmented, Part-time Teams" »


Learning Analytics

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

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

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

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

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

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

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

ACP Results 1
ACP Results 2
ACP Results 3


An Antidote to Velocity Obsession

Agile velocityGetting things done is great; to get things done is why we start things in the first place and why we follow through even when presented with obstacles and setbacks. We do things because they will (hopefully) bring us to some better state. So getting these things done quickly is good because we arrive at this better state sooner.  We track our rate of development (velocity) as a useful measure of progress and also as a leading indicator towards when we should be done. However focussing too much on velocity is dangerous; it leads to myopic mindsets and even moronic behaviour.

Yes, velocity is good, but not at the expense of quality, good-will, or noticing subtle changes in direction. At the Agile 2012 Conference Jim Highsmith and Pat Reed hosted a session called “Velocity is Killing Agility” which examined how velocity (which should be as much a measure of team capacity as it is a measure of their output) is being misused. When organizations overly publicize and analyze velocity, misguided attempts to “Go Faster” lead to gaming velocity scores and not project team improvements.

A Measurement Parallel

For the last 6 months I have been using Strava.com to track my running and biking exercise. It is a social web site for tracking and sharing workout performance data that creates maps, leader boards of hills climbed, point-to-point fastest times, etc. Using your phone or GPS device while out running or riding your performance is automatically recorded and then uploaded and compared to everyone else that has ever covered the same route. Individual rides and runs become virtual races against people you have never met. After posting the fastest time for a segment Strava will send you emails such as “Uh Oh, <fast guy’s name> just beat your record on Heartbreak Hill, go out there and get it back!” It can all get pretty competitive and silly if taken too far.

I have found Strava to be a fun, addictive work-out analysis tool that has led to a few special outings just to retake some records back and generally push harder to beat my own previous times. I have also met a few new people who run and bike locally and found some new trails by looking at the maps of where people train.  The trouble with obsessing on getting the fastest times for segments is that it can drive stupid, myopic behaviour. Stories of people barrelling down trails on mountain bikes at crazy speeds yelling “Strava, get out the way!” at people are getting more common.” Similarly, if you can’t ride the last technical descent on “Coal Chutes Drop” – then just throw your phone over the finish line and you should get a better time!”

Continue reading "An Antidote to Velocity Obsession" »


Less Test Anxiety and Improved Exam Scores in 10 Minutes

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

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

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

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

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

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

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

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

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

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

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


PMI-ACP Exam Prep Class with Mike Griffiths

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

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

Continue reading to see further details from the Course Outline

Continue reading "PMI-ACP Exam Prep Class with Mike Griffiths" »


How Will Agile Be Remembered?

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

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

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


PMI-ACP Exam Prep 3 Day Course

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

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

An outline of the course can be viewed here.

Project Zone Congress Discount Code

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

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


Autonomy and Empowerment from an Unlikely Source

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

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

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

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

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

  Basic Spend Tolerance

There are three components to the Tolerance / Exception process: 

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

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

Basic Spend Tolerance with Actuals


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

Sponsor Tolerance

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

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

Velocity Tolerance

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

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

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

  Cycle Time Tolerance

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

User SatisfactionTolerance

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

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

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


Agile PM Certifications - What's Out There?

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

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

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

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

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

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

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

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

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

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

 Less well know agile certification options include:

Continue reading "Agile PM Certifications - What's Out There?" »


"Software Extension of the PMBOK Guide" Open for Review

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

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

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

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

Inside the PMI-ACP Exam

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

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

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

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


The Impacts of Iterative, Barely Sufficient Design

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

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

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

Continue reading "The Impacts of Iterative, Barely Sufficient Design" »


Linking Agile to HR Theory

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

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

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

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

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

Continue reading "Linking Agile to HR Theory" »


Go Talk To Your Stakeholders

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

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

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

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

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

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

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

IT Failure Costs

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

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

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

(I wrote this article first for Gantthead, here )

 


PMBOK v5 Guide is Good to Go

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

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

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

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

Agile 2012 Conference Downloads

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


Collaborative Games for Risk Management - Part 2

Team ContributionsThis 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

Continue reading "Collaborative Games for Risk Management - Part 2" »


Calgary Presentation - Working Effectively with Off-Shored IT Resources

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


Collaborative Games for Risk Management

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

Doomsday Clock

Continue reading "Collaborative Games for Risk Management" »


Agile Risk Management – Harnessing the Team

Team ideasLast 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:

Continue reading "Agile Risk Management – Harnessing the Team" »


PMI-ACP Sample Questions

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

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

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

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

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

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



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

A) Technical risk reduction   

B) Incorporating stakeholder values   

C) Vendor management   

D) Stakeholder story mapping   



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

A) Learn about feature suitability   

B) Learn about feature usability   

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

Continue reading "PMI-ACP Sample Questions" »


Risk Driven Development

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

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

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

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

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

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

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

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

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

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

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


Free PMI-ACP Webinar

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

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

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


PMI-ACP Book Discount

PMI-ACP Exam Prep CoverI picked up a copy of my PMI-ACPSM 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 codeXTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.


Unlikely Origins

Agile ExceptionForbes 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?

Continue reading "Unlikely Origins" »


Wednesday’s ALN Talk – Training in Teamwork

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


Agile Interruptions

By Mike Griffiths

Agile Communications“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.”


Task Difficulty

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.

Work Productivity and Enjoyment

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)


PMI-ACP Book Coverage

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

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

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

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

Continue reading "PMI-ACP Book Coverage" »


Timebox Alternatives

By Mike Griffiths

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

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

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

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

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

Agile success intersection
 

Continue reading "Timebox Alternatives" »