Artificial intelligence promises to revolutionize project management; it can assist with data analysis, automate routine tasks, and predict project trends.

However, as a veteran project manager (read “slightly skeptical older person”), I am concerned AI will cause a tsunami of project failures before improving the state of the practice.

People tend to be lazy, and a fool with a tool is still a fool. Worse yet, a fool with a tool that produces well-written, convincing project deliverables is a very dangerous fool.

Attempting to Solve the Wrong Problem
Producing project charters faster (or communications plans, risk management plans, etc.) is not the right goal. Project management does not have a typing speed problem.

Unfortunately, AI vendors and people looking to implement AI tools with only a superficial view of what project managers do tend to pick these visible outputs as places to implement AI. In doing so, they miss the collaboration, analysis and coordination that must occur before these visible outputs can be accurately created. They only see the outwardly visible part of the PM iceberg.

It is very easy to use AI to generate these visible deliverables by providing some high-level project information in the prompt. Unfortunately, these will be a poor foundation to start from without undertaking all the under-the-surface work. To begin with, they have not engaged all the necessary stakeholder perspectives.

Pesky People Problems
Indulge this older person in a rambling story of questionable relevance. Back in school, I had a teacher who liked to tell us how much they would love teaching if it were not for all the pesky students. It was his not-so-subtle reminder that we caused most of his headaches and issues.

However, teaching without students is meaningless. His love of the subject matter may have led him to study it and eventually brought him to teach it, but the purpose of teaching is to spark a similar love for the field in students and help them navigate their learning journey. Someone who loves a topic but does not like interacting with students has a hobby but is not a teacher.

As a junior PM, I loved the science and theory of project management. I liked elaborating charters to plans, going from tasks to a WBS and schedule. Techniques like critical path, the theory of constraints, and resource levelling to convert estimates to timelines brought me joy. There was a purity and mathematical validity that was dependable and satisfying…and then always ruined by the inconsistencies of people.

People in the role of sponsors give us incomplete and conflicting requirements to deliver within unlikely deadlines. Our teams give us unrealistic estimates and then spend ages working on tasks they did not even list or estimate. Vendors lie to us to win work, and customers want our products to solve all their problems at no cost. Project management would be wonderful if it were not for the inconsistencies and unpredictability of people spoiling our plans.

Yet projects without the messiness and unreliability of people would be as worthless as teaching without students. Projects are people-driven. Projects are conceived by people, developed by people, and the outcomes are used by yet more people. However, these people are often busy, antisocial, located far away; they can be fickle, fallible, furtive and some other “f” words that come to mind.

There are No Short Cuts to Anyplace Worth Going
Attempting to plan our projects without sufficient engagement of all these problematic people is very tempting, but completely pointless. AI tools can draft project charters, write task descriptions, create work breakdown structures, and outline estimates and schedules in <1% of the time it takes us to do it manually—what progress! For agile projects, AI tools can create well-formed user stories, product backlogs, acceptance criteria, sprint plans, and complete release roadmaps.

All these outputs will be well written—likely better than 80% of those produced in their organizations previously. They will be detailed and appear plausible, which is especially dangerous. They will incorporate most industry norms (which is good), but they are almost guaranteed to fail.

They fail because they were generated without enough input from all the annoying people. The people who tell us they are too busy to start, our technology is old and needs updating, we cannot work with vendor X, and department Y has a competing project.

There is a saying that "No plan survives contact with the enemy," which has been repurposed for project management into "No plan survives contact with reality." We manage this risk by engaging with stakeholders to inject reality into our plans. In predictive/traditional environments, this involves extensive stakeholder interviews, detailed requirements gathering, and then lots of due diligence to review and get acceptance of statements of work, task estimates, etc.

In adaptive/agile environments, this involves learning about our customers and understanding their needs and frustrations, then working iteratively with our teams to identify tasks, draft short-term plans, build product increments, get feedback and refine our direction/plans accordingly. There may be less upfront stakeholder analysis and estimation, but it happens as details emerge. The people side of projects cannot be safely avoided, as this is where the realities of projects are surfaced.

However, it is shockingly easy with AI to generate convincing-looking project deliverables without proper stakeholder consultation.

A Recipe for Disaster
Using a short prompt, anyone can ask an AI tool to generate a project deliverable, and it will dutifully comply. Here is an example using ChatGPT-4 on April 17^th, 2024.

Prompt: You are an expert project manager. Generate a project charter for a new software development initiative. The project aims to develop a mobile app for a large e-commerce company to improve customer experience and increase sales. The project charter should include the following sections: 

1. Project Overview 

 - Brief description of the project 
 - Project objectives and goals 
 - Alignment with company strategy 

2. Project Scope 

 - Inclusions: features and functionalities of the mobile app 
 - Exclusions: any items not covered in the project 
 - Assumptions and constraints 

3. Stakeholders 

 - List of key stakeholders and their roles 
 - Stakeholder communication plan 

4. High-Level Timeline 

 - Estimated start and end dates 
 - Major milestones and deliverables 

Generate the project charter clearly and concisely, using bullet points where appropriate. The charter should be easy to understand, including non-technical stakeholders. 

Response: Certainly! Here's a project charter for the new software development initiative to create a mobile app for a large e-commerce company:

Project Overview

• Brief Description: Development of a user-friendly mobile application to enhance customer experience and increase sales for a large e-commerce company.
• Objectives and Goals:
  • Improve user engagement and navigation ease.
  • Incorporate advanced features for a personalized shopping experience.
  • Increase sales through enhanced mobile accessibility and functionalities.
• Alignment with Company Strategy:
  • Supports the company's vision to expand digital presence and accessibility.
  • Aligns with the goal of leveraging technology for market growth and customer satisfaction.

Project Scope

• Inclusions:
  • User account creation and management.
  • Product browsing, search, and purchase functionalities.
  • Integration with existing payment gateways.
  • Customer support chat features.
  • Review and rating systems.
• Exclusions:
  • Development of a new payment gateway.
  • Back-end inventory management system overhaul.
  • Physical store integration and functionalities.
• Assumptions and Constraints:
  • Assumption: Customers will prefer mobile app usage over the website.
  • Constraint: Must be compatible with both iOS and Android platforms.
  • Constraint: Six-month timeline for the initial launch.

Stakeholders

• List of Key Stakeholders and Roles:
  • Project Sponsor: Company CEO.
  • Project Manager: [Your Name/Designated PM].
  • Development Team: In-house software developers.
  • Marketing Team: For promotion and feedback analysis.
  • Customer Service Department: For input on customer needs.
• Stakeholder Communication Plan:
  • Weekly project status meetings with the development team.
  • Monthly update meetings with all stakeholders.
  • Email updates after major milestones.

High-Level Timeline

• Estimated Start and End Dates:
  • Start: June 1, 2024.
  • End: December 1, 2024.
• Major Milestones and Deliverables:
  • Prototype Completion: August 15, 2024.
  • Beta Testing Phase: September 20, 2024.
  • Marketing Campaign Launch: November 1, 2024.
  • Official App Launch: December 1, 2024.

I deliberately asked for a concise response for brevity in this article, but the more detail you ask for, the more convincing these deliverables can seem. I find this disturbing, not because I fear losing my job as a project manager (I now think I have job security for the rest of my career rescuing these doomed endeavors), but because of the stupidity of creating estimates and plans on such poor input data.

Some immediate questions that come to mind about this charter include:

• Where did the six-month timeline come from?
• Do we have a team with the required skills?
• What technology stack are we using?
• What products are we selling, how many, and in what markets?
• Apparently, it aligns with our corporate strategy, which is good, and it seems we do not even need to know what that strategy is.

If six months is too long, that is no problem. Ask it to adjust the schedule to four months, and presto, it will—without any pesky engineer interactions.

"Use at your own risk," I hear you say, "If you are stupid enough to generate a charter this way, you deserve the consequences."

These are valid points, but people are time-pressured and lazy. Most people do not even read articles like this anymore. I suspect that for every person who has read this far, 50 people have used AI to unwittingly generate an impossible project plan.

PREPARE to use AI Smarter for Project Management
Used correctly, AI is a boon. We can use AI to improve our plans, look for omissions, and suggest improvements. It can identify risks and suggest supporting tools and techniques we may not have considered.

However, we should use it after we have engaged with all the pesky people who list problems—and not as a replacement for talking with them.

PREPARE is a mnemonic for more responsibly using AI within project management. It focuses on improving artifacts we create with the consultation of relevant stakeholders and collaboration with our teams. The PREPAIR mnemonic stands for the following attributes:

• Protect – Protect your data (anonymize it) to prevent sharing sensitive information.
• Revisions – Ask AI to make improvements or updates to enhance the deliverable.
• Exclusions – Identify what is not included, but perhaps should be.
• Problems – Check for errors in the process or output.
• Assessments – Evaluate potential risks and suggest risk responses.
• Resources – Consider additional tools, technologies or methodologies that could support and enhance project outcomes.
• Explore – Investigate industry trends that could impact the project's direction or implementation.

So, instead of using AI to generate a project charter in one minute (then engaging a team of 10 people and spending six months failing at it,) I suggest we do this work the old way by talking to all the relevant stakeholders (sponsors, customers, architects, teams, vendors, etc.) to learn their goals, desires, issues, and constraints, etc.

Then, go through the process of engaging the people who will do the work in forming the estimates, along with consulting historical and industry data. Apply contingency, convert estimates to budgets, and do all the usual project management work.

Then, engage AI in what it is good at—making stuff up and creating lists. Ask it to review our plans and suggest improvements.

However, first, we need to protect our data. AI services might seem like helpful assistants we can have conversational chats with. Some even have friendly names like "Claude," but they are not your friends. They are front ends to large language models (LLMs) that learn based on the data they are trained on—including any data you give them, along with your prompts and responses.

Let’s look at each stage of PREPARE more in depth:

1. Protect Your Data
So, consult your organization's policies on the use of AI tools. Even if your organization has not yet developed AI usage policies, ensure you anonymize your data and do not share, upload or mention any proprietary, customer or non-public product information.

Learn the basics of data anonymization, synthetic data generation, and data masking. Tools such as µ-ARGUS, sdcMicro, and Anonimatron are free and/or open-source solutions that can help protect your data and IP.

When we know our data is anonymous and protected, we can engage AI with the remaining PREPARE-inspired prompts.

In the following examples, I am using [project charter] as the manually created deliverable I want to improve. However, this could be any project output, such as [project plan], [WBS], [Product backlog], [Persona List], etc. Likewise, I am using [groundwater analysis] as my domain, but it could be [software development], [residential solar generation] or whatever your project domain happens to be.

2. Revisions – Ask your AI agent of choice to critically review your [project charter] deliverable you created yourself, looking for ways to improve it.

Prompt: You are an expert project manager. Analyze the attached [project charter] and suggest improvements for its structure, flow, layout, readability, and clarity. Explain the reasoning behind your recommendations.

3. Exclusions – Ask what might be missing.

Prompt: Is anything missing from the document? Check the content for poorly explained content, omitted details, and missing sections commonly found in such documents in my industry of [groundwater analysis]. Explain why this element would be a helpful addition.

4. Problems – Look for errors, problems and conflicts.

Prompt: Are there any potential conflicting statements or errors in the document? Check for mutually exclusive statements, contradictions, and statements that may be incorrect or questionable for a [project charter] used in the [groundwater analysis] industry.

5. Assessments – Evaluate risks including threats and opportunities. Ask for a candidate risk list. It is always good to be forewarned of potential threats and opportunities.

Prompt: As a project management expert, experienced at executing projects in the [groundwater analysis] industry, create a list of potential risks (threats) and opportunities that might be associated with the project. For each risk, outline the potential impact, and a risk response plan.

6. Resources – Suggest supporting tools, techniques and documents. Ask for suggestions on additional tools or techniques we might use to make our case better. I might be old, but I am always on the lookout for more effective approaches, new tricks and better ways to succeed.

Prompt: As an expert business analyst, project manager, and product manager; consider the goal and purpose of my [project charter] in the [groundwater analysis] domain. Recommend supporting tools, techniques and deliverables that might help support the case I am making. Explain your suggestions with rationales of why they might be helpful and provide links and references to examples and explanations.

7. Explore – Search for alignment (or disruptions) from your industry norms. We should look for shifts in the market that may indicate our product/project is headed in the right direction for our industry (or deliberately forging a new path.)

Prompt: You are an expert in [groundwater analysis,] well versed in the latest developments, research, and industry trends. Is there anything in this [project charter] that indicates a deviation from the most probable market direction? Explain how the document aligns with industry trends and if any parts deviate. Support your points with links to relevant sources.

These prompts and acting on the results to improve our deliverables will help us be more effective and manage risk. They leverage the strength of AI while recognizing the complexities of people-based projects that require further analysis and collaboration.

Projects are Complex Adaptive Systems
Projects behave as complex adaptive systems (CAS). They are a network in constant movement pulled by stakeholder groups with competing demands, such as sponsors that want things fast and low cost, but of a high quality; customers who want things to be easy, attractive, comprehensive and cheap; and development teams who want meaningful work, career development, work flexibility, and high pay.

Projects do not get completed without managing these opposing forces, and there is no universal best way to do it. From a system's thinking perspective, today's projects operate in domains 2) Complicated and 3) Complex of the Cynefin framework:

The Cynefin framework is a way for us to classify how simple or chaotic a system is. It describes varying levels of complexity and suggests approaches for dealing with them. It starts in the lower right quadrant of 1) Simple environments. Here there is order with a clear cause and effect. This was the idealized view of projects I held as a junior project manager doing my planning without the unpredictability of people. In simple environments, universal best practices can be used over and over with predictable results.

Then we progress through 2) Complicated domains and into 3) Complex domains. In these environments, the cause and effect between project variables may only be possible to understand after events have occurred. Projects using new technology or working in emerging fields add extra complexity to projects. This is why adaptive/agile approaches build and assess small increments of product to determine viability. Their short iterations and feedback cycles mirror the Probe – Sense – Respond guidance for complex environments.

Understanding the complexities of projects and the variables at play can help us manage them more effectively. AI has a huge future in assisting us in the below-the-surface activities.

PREPARE for the Future
AI is a great tool when used appropriately. It can help us plan and improve our project management processes, stakeholder engagement, team interactions, project outputs, and their eventual outcomes.

However, it also has the potential to hamstring us if used to generate project charters, plans and estimates without the required stakeholder engagement and due diligence.

I am a fan of AI, just not the premature document creation capabilities of it. I used AI to improve this article after I had written it. I also used AI to create the PREPARE mnemonic from my initial list of Errors, Omissions, Risks, etc. improvement ideas that did not spell a recognizable word.

We can use AI to help interview all the necessary stakeholder groups and undertake the appropriate analysis. For example:

Prompt 1: I am meeting with a representative from the Finance group to discuss the goals for the ABC e-commerce project. Create a list of questions I should ask to understand the project scope and requirements from their perspective. Also, create a list of questions to capture their definition-of-done and project success criteria.

Prompt 2: We have an initial orientation meeting with the lead IT architect for the XYZ CRM project. Create a list of questions we should ask to clarify the infrastructure needs for the solution. Also, create a list of questions to explore the security, compliance and regulatory requirements we need to be aware of.

I would probably not use the exact questions these prompts generate in my interviews. However, the value comes from the topics it suggests. Most likely, it will suggest something I had not thought to inquire about, but could be helpful.

Projects are people-driven, complex adaptive systems. If we resist the temptation to use AI to generate convincing (but flawed) documents that lack underlying consultation and analysis, we can really benefit from AI.

Using the PREPARE mnemonic, we can use AI to assist us in vetting, improving and supporting our plans and processes. This smart use of AI plays to our strengths as a PM—and AI as a supporting and enabling technology.

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com in April 2024 here.]

Inflection Point – a critical change in direction.

Yesterday, a couple of data points crossed my desk that got me wondering if the Agile movement has succeeded and will now be absorbed into the mainstream. First, Jurgen Appelo posted about how the Agile Movement is Shrinking, but the Agile Mindset is Growing. He explained that some Agile conference attendance numbers are shrinking while business change is accelerating, and the most sought-after skills are collaboration and agility.

An alternative explanation is that people do not go to in-person conferences as much anymore. COVID taught us that remote is possible. Anyone who tried to get Taylor Swift tickets knows in-person can be expensive, and maybe on video is the next best thing.

Then I learned the upcoming PMI Global Summit in Atlanta has already outsold all previous PMI conferences and will be the largest in-person event in PMI history with over 3,300 attendees and still rising. The program has many agile and business agility sessions, and I will be presenting on Introducing Agile to Non-Agile Organizations.

Confirmation bias – The tendency to favor information that confirms or strengthens our beliefs.

Also this week, Stefan Wolpers wrote a great article about Should We Change Scrum? He describes circumstances where interfaces or changes to Scrum could improve its adoption and increase business agility.

Hybrid-approaches and integrating agile techniques with more structured approaches are nothing new. In 2000 (before the Agile Manifesto was written), I co-authored the first white paper about using agile approaches with structured project management Using DSDM with PRINCE2.

If the agile movement is declining because it has succeeded in introducing agility, I guess that is good. Heck, I have dedicated a bunch of time towards spreading agility within PMI and know many others who have also.

Explaining agility will continue to be necessary, but maybe we are seeing an inflection point? Maybe these data points are just confirmation bias? I’d be interested to hear people’s thoughts.

Suitability filters are models that offer simplified views of a decision-making process. They help people identify and discuss the variables at play and make a recommendation. The British statistician George Box said it best “All models are wrong, but some models are useful.”

A good model provides insights, usually a basic view of how something works or the interactions between variables. From this perspective, models are interesting and can speed up our comprehension of something. However, the greatest benefit of models is as a group alignment tool.

Visual Models Create Group Consensus

Much of today’s work is knowledge work. Subject Matter Experts (SMEs) contribute their expertise and collaborate to solve problems or build new products and services. This work is largely invisible and intangible. There are few physical or visible increments in the process. So, when someone describes a requirement, decision, or problem, there is a high chance that other people interpret that description differently.

The Telephone Game and Tree Swing cartoon are classic examples of how even well-meaning interpretations can be distorted, leading to bad outcomes. Left unchecked, our mental models of a product, project or process can diverge from our teammates. This is where visual models offer significant benefits.

Models visualize the previously invisible and, if dynamic, allow us to manipulate the intangible. In doing so, they bring SMEs together by pointing at and discussing the same variables, goals, and interactions we see.

Since knowledge work is now pervasive, tools that can get people on the same page are incredibly useful. This is why I created PMillustrated.com to explain project management to visual learners, and I am a fan of the PMI product Wicked Problem Solving (WPS). They illuminate the invisible and allow us to manipulate the intangible nature of knowledge work. Models unite stakeholders and help avoid divergence.

Some Example Models

Project Plans, Release Roadmaps, and Kanban Boards are examples of familiar visual models designed to help get people on the same page about timelines, what will be released, and work in progress. They are all simplifications since listing every task or feature for non-trivial projects or products would not be practical – yet they are still valuable.

Project plans and release roadmaps are mainly static. While we can edit them to pull and push at the variables (scope, people, estimates), it is generally discouraged since we quickly lose the original view created by the project manager or product owner. Kanban boards are deliberately more interactive. Team members move their own tasks, select new items to work on, and we can see the impacts on queue length, WIP and maybe cycle time or throughput.

Models that invite more people to interact, capture more diverse insights, facilitate better conversations, and generate stronger consensus to the final configurations. So, ideally, good models are interactive, easy to reset and invite manipulation and conversation.

“Good models are interactive, easy to reset, and invite manipulation and conversation.”

Approach and Life Cycle Suitability Filters

I have long been a fan of approach suitability filters. Not because these are infallible or inherently superior to letting people discuss how to undertake something. Instead, because they make the invisible factors visible and get people talking about what common aspects are significant.

Without suitability filters, people can be stuck in old ways or recommend unsuitable approaches because “that’s just how we do things here”, “what our standards say”, “a cool new approach I just read about”, etc.

My first exposure to suitability filters was in 1994, working on the DSDM Project and Organizational Suitability Filters. I have written about the evolution of suitability filters several times on this blog. This comprehensive list post dates from 2007. More recently, I created the Agile Suitability Filter for the Agile Practice Guide by synthesizing elements from Boehm & Turner’s model, DSDM’s Organizational Suitability Filter and new elements.

The trouble with these models was that they were published as Standards, books, or static web pages. This meant people had to print and hand them out or implement them as spreadsheets to share for use and get feedback. These clunky implementations hampered the quick reset and shared manipulation we want from a good model. DA also has some good material around scaling factors, but they are currently static models with links to static pages of text. There is no interactivity or feedback gained from manipulating values.

Web-Based Interactive Tools

Web-based tools are less likely to get lost or need preparation before use. Anyone with a web browser can access them, so they promote use by many stakeholders. Plus dynamic web controls also allow users to interact and manipulate the model parameters and see, then discuss, how the model responds.

1) The Beyond Agile Model

<Link to Beyond Agile Model>

The Beyond Agile Model is a web-based tool initially sparsely populated with suggestions for approaches, training, webinars, etc. Dragging the Project Characteristics sliders expands or contracts the dotted-red line depicting the Recommends Lens. Choosing the “Simple”, “Medium”, or “Complex” options from the Choose Model drop-down adds more sliders.

My book “Beyond Agile: Achieving Success with Situational Knowledge and Skills” describes the model, which is fully reconfigurable based on a public Google Sheet spreadsheet as a starting point. You can copy the sheet, amend it to your organizational needs, save it privately, and point the tool to this new private version. Then continue adding or amending Recommendation Types (Approaches, Training, Artifacts, etc) Recommendations (Team Charter, Release Roadmaps, etc) and Project Characteristics you wish to model (such as Team Size, Criticality, etc.)

Organizations use it to describe their proprietary approaches or create hybridized implementations of DA and SAFe with other techniques. You can read more about the Beyond Agile Model here and here and here and here, or just get the book for all the info.

2) Agile Suitability Filter

<Link to Agile Suitability Filter>

This is a pilot implementation of the Agile Suitability Filter published in the Agile Practice Guide. Making the model available online makes it quicker to share, easier to reset and open for all to play with and discuss as a group.

3) Citizen Developer (CD) / Low-Code No-Code (LCNC) Suitability Filter

<Link to CD Suitability Filter>

This is a new pilot filter based on the existing Citizen Developer suitability assessment 2x2 matrix and personal experience. Are the assessment parameters complete?  - Probably not. Are they helpful in discussing with stakeholders about the risks and opportunities of using LCNC – Probably.

What factors do you assess when determining if a product or problem is a candidate for LCNC? I would love to hear from you and create alternative models for testing.

Likewise, what are your thoughts on dynamic models to help facilitate better conversations and decisions? What models do you use, and what would you like to see developed?

Communicating project issues is challenging. Exactly when should we escalate? Who to, and how much of a chance to correct things should be given first? This is why some projects create control limits around critical parameters and develop escalation plans to communicate exceptions and agree on the next steps.

However, on most small to medium size projects, these escalation plans are often missing or left to the project manager's discretion. This creates further problems if the response is too late, not far-reaching enough, or not aligned with sponsor expectations.

Also, what are the expectations for communicating delays, risks and issues at the team level? Do we want to hear when something takes a couple of hours longer than planned (probably not), a couple of days (probably, yes), or a couple of weeks (no, we should have been informed much earlier!)

A "Definition of Broken" (DoB) helps identify and trigger previously agreed exception plans. It is a list of events that allows us to flag and start addressing a problem without the emotions and delays of arguing if it is significant, warrants immediate action, whose responsibility it is, etc.

Just as you do not want to invent a fire evacuation plan during an actual fire, so should exception plans be created before problems arise.

Origins

Agile approaches often use a "Definition of Done" (DoD) to describe the attributes that constitute acceptable. For an increment of software, this may include items such as:

• Coded
• Tested
• Refactored
• Integrated
• Reviewed
• Accepted by customer
• …

Some teams also use a "Definition of Ready" DoR to describe the desired state of requirements. For example, this could be an appropriately sized user story that meets the INVEST mnemonic attributes. Similarly, “Goldratt’s Rules of Flow” describes creating a Full-kit that lists all the items required before starting work on something. Then a sprint or iteration transforms the selected items that meet the DoR into increments that satisfy the DoD.

A Definition of Broken (DoB) is a shorthand way of referring to tolerances and exception procedures. Creating a DoB allows us to objectively describe future issues and resolutions before the stress of a problem clouds people's judgment. I have used DoBs with teams for over ten years and found them valuable shorthand terms for significant impediments.

PRINCE2 popularized tolerances and exception plans procedures in the 1990s. While PMI literature does reference risk tolerances and escalations, the PRINCE2 coverage is much broader. Tolerances can be set up around spending trends, quality metrics, sponsor confidence, widget output, or any project parameter you like. The example below shows a tolerance range around projected spend at +10% and -20%.

So, tolerance is an agreed range of variation, like a control range. However, unlike control ranges, tolerances are paired with an exception procedure to be executed if the tolerance range is breached.

The Downsides of Tolerances and Exception Plans

While it would be helpful to create tolerances and exception plans for a wide variety of project variables, project managers typically do not have time to document them all and get approval from the necessary stakeholders.

As a result, the good practice of defining tolerances and exception plans is often omitted from projects that do not mandate them for safety, regulatory compliance, or quality reasons. Project managers are too busy to create them, and sponsors don't want to review a long list of "What if this happens…" procedures.

Definition of Broken (DoB) Can Help

This is where a Definition of Broken (DoB) comes in, as a lightweight pre-approved emergency response plan. Without all the documentation and signoffs, critical issues that would require sponsor or steering committee intervention can be agreed to in advance. Then, should any of these events occur, there is much less debate before action is taken. This pre-approved action plan speeds remediation and increases the likelihood of recovering from a significant issue.

A Couple of Examples

On a project to implement a 3^rd party membership management software package and write new custom code to link the membership system to various in-house developed systems, DoBs were created for likely but high-consequence scenarios. These DoB situations triggered an escalation report to the project steering committee and automatic inclusion as a discussion item at the weekly sponsor review meeting.

Example 1: Vendor Schedule Delay

The vendor's implementation plan showed the core member billing module configured, installed and tested by the end of May.

DoB Trigger: "Billing module not operational on June 30^th" 

(This was a month after the vendor planned to do it. So the vendor was happy to agree to the DoB trigger. Predictably, come June 30^th, the billing module was installed but still not operational. Having the DoB clause with an approved escalation plan meant no debate or weaseling opportunities for the vendor. The item was escalated, bringing in new vendor staff to expedite the issue resolution.

Example 2: Integration Team not Available

Since the micro-services group was a critical dependency, it seemed prudent to get pre-approval to resolve any delays.

DoB Trigger: "The project team waits more than two weeks for an integration or test- environment to be created."

(In this event, the issue will be raised with the Integration director and escalated to the steering committee. Due to many projects requiring work from the Micro-services team, this happened on three occasions. Fortunately, the team anticipated the delays, and the escalation resulted and quicker turnarounds than other projects experienced.

How is this Different from Basic Risk Management?

DoBs certainly overlap with risk management. The critical difference lies in the socialization and pre-approval of the escalation procedures to expedite action. Having a risk occur and turn into an issue then requires communication and issue escalation.

Using the risk response route is akin to sending a high-importance email to everyone at the affected location that there is a fire and they must evacuate. Then hope they read it, take it to heart, and act on it with the appropriate urgency. Having a DoB with a pre-approved escalation plan is more like sounding the fire alarm. It has been discussed and approved before; now we just need to do what was agreed. Since issues are like fish smells (they get worse the longer you leave them), things we can create upfront to speed resolution are often worthwhile. 

How to Implement DoBs

First of all, we need to be realistic about the effectiveness of DoBs. If we try to create too many, we will not gain the agreement or buy-in for the resolution we need to make them effective. I suggest no more than 5-10. Likewise, they need to be based on critical-consequence threats, not minor impact problems. If we cry-wolf too often, we will be correctly ignored. So, only use them for issues that would threaten the success of the project.

For serial, plan-driven projects, DoBs can be added to the project charter and updated at phase boundaries. Wording can be as simple as:

"The following Definition of Broken (DoB) items identify scenarios that would trigger immediate escalation to the sponsor and addition to the issues list reviewed at biweekly steering committee meeting:

• Building permits not obtained by June 15^th
• The pumping station is not operational at full capacity by year-end
• Telemetry software not completed and accepted by Feb. 28^th“

For hybrid and agile projects, DOBs can be drafted alongside the Definition of Done (DoD) and reviewed and updated at retrospectives as necessary. They can be recorded in the team charter you posted somewhere visible. "Our Definition of Broken (DoB) items that signifies immediate team resolution comprises:

• Customer satisfaction ratings less than 80%
• Servers not installed and acceptance tested by May 1^st
• Page load speeds over 3 seconds
• Critical bug cycle time > 2 days
• Team eNPS below 30”

Parting Thoughts

If the Definition of Done (DoD) is a broadly accepted and understood concept in your organization, consider discussing a DoB. Maybe it makes sense to try them? The criteria can be agreed upon with vendors and team members, product owners, business representatives and any group with a stake in the project.

The goal is not to set traps for future punishment but to promote constructive dialog and consensus about what constitutes a significant problem. Then collaboratively define the escalation procedure and gain agreement to expedite these issues, should they ever occur.

The process has a subtly different effect than documenting risks which is often not a collaborative process agreed to by both the triggering and impacted stakeholders. Creating a list of DoBs and making it visible can change behavior and impact outcomes.

Also, discussing issues and escalation plans with sponsors can uncover priorities not identified in the chartering process. The more we learn about what constitutes success, acceptable variation, or failure, the better we can navigate project decisions and direction to better outcomes. 

Note: I first wrote about the Definition of Broken (DoB) in my book Beyond Agile.

On Friday, September 30, I will be presenting a session on Beyond Agile at the HTEC Project Management Virtual Conference. The session is free to attend and is part of a program that also features Scott Ambler, Sanjiv Augustine, Nader Rad, and Frank Turley. You can register here.

“Yes, And, And”

A colleague recently described Beyond Agile as a “Yes, And, And” toolkit, and I thought it was a great way to summarize the two elements of combining hybrid agile with the Theory of Constraints, and value stream view.

“Yes, And”

“Yes, And” is a term from improv comedy that refers to the idea of not undermining what has come before and adding valuable new elements. For example, we can say, “Yes, Scrum has been tremendously popular partly because of its initial simplicity, And when we add ideas from emotional intelligence, it can be even more effective.” We acknowledge the strengths of Scrum And add valuable extras.

The First “Yes, And” – Welcome Hybrid

Beyond Agile takes a “Yes, And” approach to hybrid agile. It acknowledges that agile approaches are a great place to start for knowledge work projects, And adds that sometimes, traditional approaches can bring useful elements for risk management, dependency analysis, etc.

Of course, Beyond Agile does not just add traditional approach elements to agile. It also adds ideas from leadership and emotional intelligence, along with recognizing the need for industry knowledge. These elements form the 4 overlapping circles of ideas in the Beyond Agile Model.

The Second “And”

The second And in “Yes, And, And” is the removal of insufficiently performing process. So, Yes, we use a hybrid of approaches And relentlessly remove processes that no longer justify their expenditure. This is the elastic property of the Beyond Agile Model Recommendations lens. It is always trying to contract and asking us to see what we can do without, so we focus more time and effort on value delivery.

The Beyond Agile Model defaults to a small set of recommended practices. We must manipulate the project characteristic sliders to open the recommendations lens to suggest more processes. Then we are always asking:

• What can we drop?
• What is no longer worth the effort?
• Can we try without X for a week and see what happens?

For most teams, this takes conscious effort. We get used to activities and events, so asking if we need them or if they are worth it seems unnatural. However, we carry the time and concentration burden of all processes, so asking if they deserve space in our ways-of-working backpack is valid.

Techniques such as visualizing our work time help us see the weight of our processes. It is an application of the Lean concept of removing waste. Any process that costs more than it delivers is wasteful, and the team should ask if they can get the same or similar benefits for less expenditure.

Ultimately we should expand our toolbox with as many valuable techniques as we can since knowledge is weightless. We can hone our skills through training and progressively larger-scale practice. Then become agnostic; it should not matter what camp the tools and techniques come from if they are valuable. Finally, we focus on value delivery, which means relentlessly removing excess process (agile or otherwise.)   

 “Yes And, And” captures the hybrid and value delivery focus nature of Beyond Agile. I look forward to explaining the concepts further on Friday and discussing case studies from teams that have used them. Please join us if you can, or sign up for the event so you can view the recording later.

This is part one in a series on leading agile teams from the Beyond Agile book. We will examine what leadership entails and how it applies to agile teams. Then discuss the transition from servant leadership to shared leadership.

EQ as a Foundation for Leadership

As we saw in the previous articles about Emotional Intelligence (EQ), leadership is built on top of EQ. We need good EQ to be able to recognize and manage our own emotions. This is a prerequisite for others to consider us credible and worth listening to. So, a firm grasp of EQ, either gained intuitively or improved through study/training, brings us to the starting line with engaged stakeholders. Then leadership involves bringing this collective willpower to bear on a vision or a journey to our project or product outcome.

We can create backlogs and release plans all we like, but until there is a motivated team with a shared vision of the end goal, it is like trying to push a rope—ineffective. Leadership is focused on creating the pull from the team and giving the team the goal and tools to overcome obstacles.

Leadership is a Huge Topic

Leadership has been around far longer than project management (which primarily grew from the Industrial Revolution.) Leadership goes back as far as people have lived together and worked together to achieve common goals, whether invading a neighboring tribe, traveling to new lands, or building a large structure.

There are over 70,000 published English-language books on leadership. If you read one daily, it would take you 191 years to finish them (by which time there would likely be 70,000 new ones to read). With such a deep history and broad scope, we need a focus to best direct our guidance toward knowledge-worker team execution.

So we will take a product-focused view toward leadership and concentrate on the leadership traits and steps necessary for building and leveraging high-performing teams in complex knowledge-work environments. Unlike many leadership books available, we will not cover leading companies or organizational change; instead, we will focus on leading projects and programs to deliver desired outcomes.

What Leadership Is Not

Unfortunately, there are many myths and misconceptions about what leadership means. So, before we get into how to become a better leader, we should dispel some of these myths that are common barriers to understanding.

The best metaphor I’ve heard for dispelling leadership myths is the “Cowboy leader” by Pinto et al.  When we think of a cowboy, we often picture the lone-wolf movie character who acts independently, often above the law, thinks on his feet, and saves the day. He cuts through bureaucratic red tape, circles the wagons, and rallies the people to overcome the bad guys. Then our hero rides off into the sunset with the pretty schoolteacher and onto his next adventure.

Yet this is just a movie-star definition of a cowboy, portrayed by the likes of John Wayne, Roy Rogers, and Clint Eastwood. Do you know what a real cowboy does? They lead cows. They use their dogged determination to turn and drive bovine herds toward the desired goal. I am not trying to be derogatory here, comparing your company’s staff to unintelligent cows; I am making the point that real cowboys do not typically do a lot of shooting of bad guys and rescuing damsels in distress.

Also, John Wayne, Roy Rogers, and Clint Eastwood are Hollywood actors, not cowboys. They live in big, fancy houses and do not spend much time around farm animals. Would you really trust them to look after cows? Your cows?

The term leadership is often loaded with this romantic notion of a swashbuckling go-getter with a larger-than-life rockstar personality. Yet, in reality, some of the best leaders are quiet, introverted people who care deeply for their teams and stakeholders and quietly grind away toward a common goal.

Real leadership is based on sound theory. It can be learned and exercised on a small scale before being brought to bear on larger groups. Authentic leadership is practiced on mundane things, yet when more significant events occur, the skills and trust of others can be used to overcome significant hurdles.

Additional leadership myths include the beliefs that leadership needs to reside in a single person and that all groups need leaders. Quite often, leadership roles are shared between team members. In fact, it is unlikely that any one person would be solely equipped to lead a team in all circumstances.

Establishing environments where people can step up to lead when the need arises creates resilience and competitive advantage. Likewise, some small teams without the need for high-consequence decision-making can operate just fine without a leader.

What Leadership Is

So, having established that leadership is not swashbuckling behavior or an innate quality of character, let us look at what it is. There are many different leadership models, but the same roles crop up repeatedly. Listing them is the easy part. We will then focus on the more difficult topic of how we achieve them, given all the challenges of project constraints, opposing demands, and people conflicts.

Leaders exhibit the following attributes:

1. Vision
2. Good communication skills
3. Ability to inspire trust
4. Ability to empower
5. Energy and action orientation
6. Emotional expressiveness and warmth
7. Willingness to take personal risks
8. Use of unconventional strategies

Let’s look at each of these characteristics in turn.

Vision - The ability to create and describe an exciting view of the future state. This includes what success looks like and the benefits it will bring to the sponsoring organization, the users of the end result, and the team members who created it. It provides a common goal to guide the team in times of questioning and decision-making. It is what we are aiming for.

Good communication skills - A vision, support, and guidance are useless unless we have a way to communicate them to people. Communication skills are required to inspire, inform, and advise stakeholders. They are also crucial for receiving information and quickly building rapport with a wide variety of groups and individuals.

Ability to inspire trust - Studies show that the greatest attribute people look for in leaders is honesty and trustworthiness. Working for someone we do not trust undermines our feelings of self-worth and respect in the long run. To be an effective leader, we must act honestly and with integrity—otherwise, people will not work with us.

Ability to empower - We should make use of people’s knowledge and skills by trusting them to do a good job. We must also be able to make the team feel capable and develop team members to their fullest potential.

Energy and action orientation - Effective leaders have elevated levels of energy and enthusiasm for work, which is contagious. We must understand that it is impossible to inspire others if we are apathetic or lukewarm in our reaction to the challenges.

Emotional expressiveness and warmth - Leaders must be able to express their feelings openly, but without venting or alarming people. They should not keep others guessing about their emotional state, but instead, be approachable and warm cheerleaders for the endeavor.

Willingness to take personal risks - It is desirable to have some skin in the game, to be personally invested beyond just a role, and to have some reputation or repercussion invested in the outcome. Like successful entrepreneurs, leaders are not risk-averse.

Use of unconventional strategies - Leaders must think creatively and not be constrained by conventional approaches. They are happy to model the desired behavior by trying new techniques and experiments.

These characteristics are the goal; things get more difficult when it comes to achieving them under challenging circumstances.

Shared Leadership: Primary Colors® Model

The Primary Colors Model of leadership was one of the first to recognize that it is extremely difficult, if not impossible, for any individual to possess all the attributes needed to be a complete leader. Instead, it recommends leaders build leadership teams that comprise all the necessary skills.

The Primary Colors Model offers ideas similar to those found in “In Praise of the Incomplete Leader,” a 2007 paper published in the Harvard Business Review. Its authors suggest that successful leadership comprises four capabilities:

1. Sensemaking: Understanding the context of the company and how people operate. Having a talent or knack for explaining these complexities to others.
2. Relating: Being able to build trusting relationships with others.
3. Visioning: Creating compelling images of the future by collaborating with others on what they want and then explaining it.
4. Inventing: Developing new ways to bring the vision to life.

The Primary Colors Model contains three intersecting domains of strategy, operations, and interpersonal skills. It also uses a human-anatomy metaphor to explain these functions and how they interact. The strategic domain is like the head, responsible for thinking; the operational domain is the hands and legs, responsible for getting things done and moving the organization or product forward; and the interpersonal domain is the heart and deals with forming relationships, motivation, and EI.

These domains and functions are shown in figure 11.2.

FIGURE 11.2 The Primary Colours Model of Leadership

In this human-anatomy analogy, the Primary Colors Model places leading at the center, like a central nervous system. It senses, balances, and coordinates all the other functions.

At the intersection of these overlapping functions are three key roles of a leader. Creating alignment is at the intersection of strategy (head) and interpersonal (heart) since it deals with creating a rational and emotional commitment. Team working, the skill of getting things done, is at the intersection of operational (arms and legs) and interpersonal (heart) since it deals with work and motivation. Finally, planning and organizing is at the intersection of strategic (head) and operational (arms and legs) since it deals with planning the work that needs to be done.

Now we know what functions need to happen and that it is unlikely that any single person has all the necessary skills. So, the next logical step is to assess our own skills, recognize our gaps, and go find people with the skills to fill those gaps. This is another instance where having diversity on the team is helpful. Diversity is Darwinian: The greater the diversity in the resource pool, the greater the range of external events that can be responded to successfully.

Tom Peters, author of In Search of Excellence, once joked, “If you find anyone in your organization who agrees with everything you say, fire them! Why pay twice for the same opinions?”

So, diversity is good, but how do we measure it? A simple approach is to assess people’s affinity for or attraction to different work types. Vocation-planning tools used in schools try to determine likely “fit” by assessing people on two ranges. The first range is things or people, and asks if individuals are happier working with things (be they animal, vegetable, mineral, or machine) or happier working with people. People who are interested in things enjoy collecting, constructing, and categorizing them, and analyzing them and their functions. People who prefer people enjoy emotions and idiosyncrasies; they are drawn to people for stimulation and support.

The second range is data or ideas, and asks if people prefer working with data and facts or with ideas and possibilities. People who prefer facts and data tend to be practical, data-analytics types. They are persuaded by logical, here-and-now facts and data. People who are drawn to ideas, possibilities, and theories enjoy what-if scenarios and are divergent thinkers. They may be thought of as creatives or dreamers.

Assessing people on these two ranges helps us determine where we fit and where others on our teams fit. The ranges and categories of preferences are shown in figure 11.3.

FIGURE 11.3 Two Dimensions of Vocational Preference

Here we see three roles and their positioning based on work preference. “Strategic” indicates someone who leans more toward the ideas end of the data-to-ideas spectrum and who is happy dealing with ambiguity. ‘Operational/Technical” shows someone who leans more toward the data end of the data-to-ideas spectrum and toward the things end of the things-to-people range. Finally, “Interpersonal/Supervisory” shows someone who is more comfortable with people than things and who prefers data over ideas.

Incidentally, full personality assessments such as Myers-Briggs, Belbin, or the Big Five typically take about an hour or so to administer. But having team members indicate where on this chart they rate themselves is quick and makes a great retrospective or team-building exercise to illustrate and respect diversity.

In figure 11.3, it is difficult for people to move between these roles as it requires major shifts in focus and interests. The nearer people are toward the center, the easier it will be for them to move into each of these roles.

Combining the Primary Colours Model of leadership with these personality traits reveals additional useful ways to categorize the functions and roles of leadership. Figure 11.4 shows the two models superimposed.

FIGURE 11.4 Primary Colours Model Combined with Personality Traits

Here we see the two job-preference dimensions of things/tasks to people on the x-axis and data/ present to ideas/future on the y-axis. Also shown are ovals representing the personality traits of the people who operate well in that domain and boxes representing the classical elements of air, fire, earth, and water.

Does your team have people that can assist in the roles of Influencer, Relationship Builder,  Implementor, or Strategist? Of course it does, so tap into those abilities. Lean thinking tells us that Non-utilized Talent is a form of waste, let’s not be wasteful and instead increase the team’s effectiveness and the likelihood of success.

The Primary Colors Model is powerful for several reasons. First, it legitimizes the idea of shared leadership and the need for collecting a set of competencies from the team and distributing power. Second, the human-anatomy metaphor creates an easily understood structure for uniting the skills and functions necessary for leadership, which are often described as discrete, unconnected, or vaguely connected elements in other models. Finally, it aligns well with vocational preference models and work types.

Key Takeaways

• Leadership can be shared.
• People have distinct preferences for dealing with things or people, hard facts or ideas.
• Holistic leadership needs to address all these dimensions.

<This is an excerpt from Beyond Agile. In future posts, we will explore additional shared leadership examples and introduce Host Leadership as a framework for implementing shared leadership in an agile team setting.>

Agile approaches "Crossed the Chasm" a decade ago. The organizations we see adopting it today are in the "Late Majority" and "Laggard" categories of Geoffrey Moore's Technology Adoption Life Cycle.

As companies adopt agile because they have to / it's now expected / the industry norm / required to stay competitive / <insert your own reason>, we see more push-back and failures than ever.

Doing something because you have to, rather than because you want to, leads to shortcuts and the wrong mindset. The image below, from Ahmed Sidky, shows agile as a mindset.

In the image above, agile is a mindset described by four values, defined by twelve principles and manifested through an unlimited number of practices.

The correct way to learn agile is to start on the left of this image and learn about the four agile values in the mindset. Then learn about the twelve principles that define agile. Once you understand those, you will see all the agile practices are just implementing agile principles and values in various scenarios to solve different problems. This is the correct, Left-to-Right agile adoption.

Unfortunately, many organizations reluctantly adopting agile are impatient. Mindsets and values sound like unnecessary fluff. "We are serious engineers and don't have time for that kumbaya nonsense. Our people are smart, just show us the practices, and we will figure out the rest." So they start on the right-hand side, and adopt a set of agile practices, not appreciating the values and principles necessary for them to work.

Some practices work; others do not. They struggle to get whole-hearted buy-in and see only patchy pockets of success. Some teams continue trying agile; others revert back to how they were. They become an "Agile? Yeah, we tried that, but it did not work well here" shop. They experienced the right-to-left copying of practices without understanding the mindset, values or principles.

Incorrect Right-to-Left adoptions of agile (or anything) fail because they copy behavior without understanding the supporting structures. The practices we see agile teams undertake are just the visible components of a much larger ecosystem. This is known as the Agile Iceberg.

Supporting the visible practices above the water line is a larger, more significant commitment to the mindset, values and principles below the water line. Without investment in the below-the-waterline components, any attempts to copy and duplicate agile practices will sink and be dropped from practice.

Cargo Cults

Another analogy used to depict right-to-left attempts to cut and paste agile is the Cargo-cult. "Cargo cults" is the term used to explain the phenomenon of blindly replicating outward behavior, hoping that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the wartime aircraft runways, control towers, and radios out of wood on remote islands, believing that they would bring back the cargo planes that brought Western goods during the war.

The islanders did not know how control towers or radios worked; they just copied what they had seen, hoping it would bring the benefits they had also seen. Implementing sprints, demos, and daily stand-up meetings without valuing individuals and interactions over processes and tools is just as ineffective as an all-wood radio. All it achieves is to frustrate people and give agile a bad name.

The Solution

Like anything worth achieving, the solution requires some thought and hard work. We need to work one-on-one with people and provide maps, not pamphlets, of how agile works so people can make their own informed decisions at the junctions on the pathway to value delivery.

This may sound like a lot of work, but it saves time and reduces workload in the long run.

Making Sense of Agile

There are thousands of agile practices documented in books, blogs and presented at agile conferences every year and likely many times more that never get reported. We do not need to learn them all; because once we understand a core set, we will see the themes, grasp the goals, and help teams create their own tailored ways of working that support the agile mindset.

Let's review some popular techniques often seen on Scrum teams.

Daily Stand-up meetings – These are the quick, inter-team coordination meets held daily where team members share with their colleagues:

• What they have been working on (or completed),
• What they plan to work on next,
• If any issues or blockers are hampering their progress.

Agile Concepts:

• The team owns the work – team members report to each other, not the Scrum Master or some project manager authority role
• Transparency – openly share information, good and bad, so people stay informed and can make better decisions

Sprint Demo – At the end of every sprint (usually one or two weeks long), the team demonstrates what has been built to the business and confirms what to work on next.

Agile Concepts:

• Frequent delivery – Deliver working software frequently. Working software is the primary indicator of progress.
• The team owns the work – It is the team that demos the work, not the Scrum Master or Product Owner. This demonstrates and builds ownership of the evolving solution.
• Focus on business value – Since the backlog is prioritized by business value, the team should be demonstrating the highest business value work items completed. Also, the discussions on what to work on next also focuses work by business value.
• Transparency – Openly share information, good and bad, so people stay informed and can make better decisions.

Product Backlog – The ordered list of work for the project/product. Prioritized by the Product Owner based on business value. Creates a single queue of work items to focus on.

Agile Concepts:

• Focus on business value – The product backlog is prioritized by the product owner, usually a business representative, not the Scrum Master or other team member, to ensure the project focuses on business value.
• Transparency – By putting all work items in a single, highly visible queue, everyone can see the full scope of work to be accomplished. This (hopefully) eliminates side-agreements or under-the-table agenda items being worked on. Also, since change requests are prioritized in the backlog, they bring visibility to these elements and likely completion dates.

Release Planning – The process of the product owner and development team collectively meeting to discuss, prioritize and estimate features for the next release. By engaging the do-ers of the work in the planning process, we simultaneously: 1) get better insights into technical work involved, 2) generate better buy-in for the estimates created and a stronger commitment to meet them.

Agile Concepts:

• Focus on business value – The business (through the product owner role) drives the planning process.
• Transparency – Features and stories from the product backlog are refined and estimated to create a release roadmap that illustrates target dates for key components of the product or service being developed.

Sprint Planning – This is the planning process one level below release planning. The product owner and development team collectively meet to discuss, prioritize, and estimate the next one or two weeks' worth of development.

Agile Concepts:

• Focus on business value – Work is prioritized by the product owner.
• Engage the team in decision making – The team makes local decisions about how best to undertake the work, how to self-organize, and in what order to undertake technical tasks.
• Transparency – All estimates and progress are discussed openly within the project team. Details about progress, issues, or setbacks are discussed daily at the daily stand-up meeting.

Retrospective – A workshop held at the end of each sprint/iteration to review progress, process and people aspects of the project. These regular inspect, review and adapt sessions typically result in suggestions of things to try differently in the next sprint/iteration. By conducting frequent, short-scale experiments, teams can inspect, adapt and improve rapidly throughout delivery.

Agile Concepts:

• Inspect and adapt – At regular intervals, the team reflects on becoming more effective, then tunes and adjusts its behavior accordingly.
• Engage the team in decision making - The best architectures, requirements, and designs emerge from self-organizing teams. Continuous attention to technical excellence and good design enhances agility.
• Transparency – Be open to talking about issues and ways to improve. Acknowledge there are constantly ways to get better. Recognize and thank teams for looking to improve their delivery capabilities.

Kanban/Task Boards – These are large publicly accessible displays of work done, in-process, and waiting to start. Kanban boards make the team's work visible.

Agile Concepts:

• Transparency – It shows what is being worked on, what has been completed and what is coming next. This information is not the domain of just the project manager, everyone benefits from knowing about it.
• Engage the team in decision making – By sharing the project plan visibly, team members can better alert us to potential problems and solutions.

Seeing the Agile Matrix

In the sci-fi movie "The Matrix", the hero, Neo, develops the ability to "see the code of the Matrix." This is the computer simulation he is living inside. Once he sees this, he understands how things work and can move faster and is more powerful than ever before. It is an "a-ha" moment; now things make sense, and he can see his world's structure and patterns and manipulate them.

It is the same with developing an agile mindset. Once you realize agile is based on a few core concepts, you see them repeated everywhere. These concepts include:

• Focus on delivering value
• Build incrementally
• Gather early feedback
• Inspect, adapt and learn as you go
• Let the team decide as much as possible
• Be transparent and show progress, good and bad

With these ideas in mind, practices such as estimating via planning poker make more sense. We are engaging the team in defining their estimates. We are using a visual, transparent process. It is iterative and incremental. There is inspection and the ability to adapt the estimates if outliers are found.

Everything agile teams do reflects these values. Information radiators are about being transparent and visual. Voting on decisions is about letting the team decide. We do not need to learn every agile practice because we will quickly be able to understand any of them once we recognize the agile mindset, values, and principles.

When making decisions, we can apply these agile concepts. Engage the team, be transparent, focus on value, get early feedback, etc. These are not complex concepts to grasp and are what many of us intuitively try to do anyway. That's why agile, for many people, feels like common sense.

However, it can be quite different from traditional project management's analytical world, which aims to specify everything up front before executing a detailed project plan. It is a mindset shift for some people, but one worth making if your work is complex, uncertain, and frequently changing. Here a Left to Right adoption of the agile mindset, values, and principles is the way to go.

<This article is an excerpt from PM Illustrated: A Visual Learners Guide to Project Management. If you are a visual learner who likes clear explanations, check out PM Illustrated here.>

Upcoming Presentation: “Hybrid Agile, Stepping Stone or Quicksand?”

How do you feel about hybrid agile – mixing agile approaches with non-agile approaches? Can it be useful sometimes, or is it the path to compromise and failure? (A great way to separate agile purists from pragmatists is to ask them what they think about hybrid agile.)

Please join me on April 26 to discuss hybrid agile with PMI San Diego Chapter. In this session, we will separate agile blends from non-agile hybrids. Then explore case studies of failures and success stories, examining patterns of problems and success factors. Topics include:

• Left-to-right agile adoption vs right-to-left implementation
• The Genius of the “And” vs. the Tyranny of the “Or”
• Hybrid models (switchover, sandwich, encapsulation)
• Case studies in success, failure and regression
• Red flags, anti-patterns, and warning signs to stop
• Further resources and case studies to learn from

To quote Ron Jefferies, “Agile isn’t any damn thing,” so come find out what breaks it and if we can preserve it with the combination of non-agile elements.

Registration Link

Now that my Beyond Agile book has been published, I would like to thank some people who helped shape its content and ideas. Alistair Cockburn and Joshua Kerievsky helped me appreciate the balance between people-focussed activities and effective processes.

“...Agile approaches combine a mixture and equal balance of people and process approaches to delivery. One way to picture these interwoven elements is like the twin strands of DNA. In figure 4.1, we see a blue thread of people elements such as empowerment, collaboration, and team decision-making, mixed with gold process elements such as backlogs, prioritization, and short iterations.

If you have not noticed it before, agile approaches weave people elements and process elements together through the agile mindset, values, and principles. For simplicity of understanding,  we pull these elements apart to talk about them individually, but in reality, they are inextricably linked and self-supporting, like the blue and gold elements shown in figure 4.2.

The people and process elements are present in all views of agile, no matter how you slice it. Also, they are in an equal balance. This is not a matter of coincidence or hidden code, but rather the sign of a balanced system. Let’s look further.

The Agile Manifesto has two values focused on people and two focused on process:

When we examine the 12 Agile Manifesto principles again we see six focused on people (shown in blue) and a counterbalancing six based on process (shown in gold).

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable Sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams. 
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Let’s examine the frameworks of Alistair Cockburn’s Heart of Agile and Joshua Kerievsky’s Modern Agile, first looking at the original models and then superimposing views of people and processes.

In Alistair’s Heart of Agile model, the Deliver and Improve process concepts are complemented by the Collaborate and Reflect people-focused concepts. Likewise, Joshua’s people-focused Make people awesome and Make safety a prerequisite are balanced and complemented by the ideas of Deliver value continually and Experiment and learn rapidly.

Both models are evenly balanced between people and process advice; this fact, along with their clarity and simplicity, is what makes them both powerful and compelling.

We should always be aware of these two elements in the tools and approaches we use. Additionally, looking for a healthy balance of attention within teams is a useful diagnostic. People sometimes have a personal bias or natural aptitude for the people side of things, or for the process side of things. So why not ask the team if they think the system is in balance and, if not, what they suggest to restore to balance any imbalances?..."

Thank you, Alistair and Joshua. Your insights and skills in distilling ideas have helped many people increase their understanding of collaboration and teamwork.

It has been 10 years since the PMI-ACP exam was created, and I published my PMI-ACP Exam Prep book. I recall the Steering Committee meetings where we discussed what we believed was necessary for agile practitioners and team leaders to have experience in and an understanding of.

Since then, the exam has been updated a couple of times based on Role Delineation Studies (RDS) and Job Task Analysis (JTA), which is how PMI surveys practitioners and asks what techniques are commonly used. However, the core content has mainly endured unchanged, which is testimony to its usefulness.

I remember discussing the scope and goals for the credential among the committee that comprised: Alistair Cockburn, Mike Cottmeyer, Jim Cundiff, Jesse Fewell, Mike Griffiths, Ahmed Sidkey, Michele Sliger, Dennis Stevens and PMI researchers.

In addition to an agnostic understanding of Lean, Kanban, Scrum and other agile approaches, we also agreed people should know about the basics of servant leadership, conflict management, team decision making, and coaching. So our scope included more than just Lean and agile; it had a little leadership and emotional intelligence.

At the time, someone suggested a three-tier credential consisting of something like Agile Basics, Agile Journeyman (journeyperson), Agile Consultant that mirrored Shu-Ha-Ri. PMI leadership rightly reined this in, explaining it was a good idea, but how about we just focus on getting the basic level credential created for now.

PMI was correct to focus on the universal fundamentals. As we get into more advanced topics, there is no single correct answer. So, topics like agile scaling frameworks, strategies for motivating teams, the pros and cons of different leadership approaches that get deeper into agile, leadership and emotional intelligence were never tackled but are topics that my blog readers know I care deeply about.

My new Beyond Agile book is my exploration of these topics (plus others.) I dig deeper into unlocking the power of individuals and teams. How can we encourage better engagement, focus on the project goals, and ditch non-value-add mindsets and processes? These are based on my experiences and research.

You likely won’t agree with everything I suggest, and that’s fine; not everything will work for your situation. However, I am confident you will find many valuable concepts and connections between ideas you thought about separately before.

As the book title suggests, it goes beyond agile. Sometimes the best way to tackle a problem might be with a plan-driven approach. Agile Myopia is the mistaken belief that every project situation has an agile solution.

I am more of a pragmatist. Sometimes, the best way to assess and analyze risk is with the risk management process from plan-driven project management approaches. We may then choose to implement the risk responses in an iterative, incremental way via our backlog and spikes, but that again is being pragmatic.

My previous post mentioned a disconnect between teams being agile and the highest-performance teams I was able to work with. These high-performing teams hardly discussed agile concepts or paid much attention to the agile ceremonies, although they lived the mindset emphatically. Often what set them apart was the deep industry experience and knowledge they had gained, making them trusted partners within the business groups they served.

I set out to define what sets high-performing teams apart and outline the steps to replicating them. There may be no formula but I did uncover a set of knowledge, skills and thinking tools people can use to chart their own course. It represents the What’s Next beyond the ideas in my PMI-ACP books and provides a broader landscape to explore. I hope you enjoy it.

When should we be using an agile approach for our project? The agile convert might claim “Always,” just as the predictive enthusiast could scream “Never!” For the rest of us, more objective tests and selection criteria are useful.

Agile suitability tools are nothing new. DSDM shipped with one in 1994, and the Agile Practice Guide published with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Sixth Edition has one as an appendix. However, this article is about short cuts, a single question that can provide a good indicator for suitability—a litmus test for agile approach suitability.

Common Destination, Different Directions
The whole “agile versus traditional” debate is mostly unnecessary when we step back and take a broader perspective. Everybody is trying to get to the same destination of successful outcomes and happy stakeholders. However, it is when we start discussing the “how-to” path for achieving these goals that passionate debate occurs. This is because “the path” does not exist. There is no single right approach; instead, it depends on the environment and project at hand.

We can learn techniques for running traditional, predictive projects and adaptive, agile ones. Then, based on the situation, use the appropriate approach. Sometimes a single process is sufficient; sometimes, a hybrid might be necessary. So, the next logical question that pops up is, “What are the project environmental factors we should be evaluating, and which point to predictive or adaptive approaches?”

How does work from home impact our use of agile approaches? If co-location is no longer possible, can we still be agile?

Yes, of course we can, and in many ways, now we need to be more agile than ever as we try new approaches, learn and adapt how we work. However, let's address the co-location question and look at agile practices in remote work situations.

This is not a post about rich people now able to visit their second homes after the lockdown, instead, a revisit of the concepts of decentralized work being the new way of undertaking projects.

In 1980, Alvin Toffler’s book The Third Wave introduced the idea of “The Electronic Cottage” as the modern workplace where information technology allows more people to work from home or wherever they want. Toffler was a futurist and businessman who did not get the attention he deserved. Even though Accenture identified him as one of the most influential voices in business leaders (along with Bill Gates and Peter Drucker), we do not hear much about him.

People are smart, resourceful and inventive. We are also dumb and irrational. This combination makes forecasting nearly impossible.

People build cities, express themselves through art, and push forward our understanding of the world through science and logic. At the same time, they exhibit cognitive bias and often behave in ways that defy this same science and reasoning.

The simultaneous application of logic and defiance of logic is part of what makes humanity rich and complex. It is also why predicting how the world will change after the COVID-19 pandemic contains much uncertainty. Some effects will be the sensible results of events and reactions. Others will be nonsensical reactions (like hoarding toilet paper) due to cognitive bias. These factors will intermingle and interact with new yet unknown events to create a tomorrow that is impossible to calculate.

So, while nobody knows how our future will be different, we do have some ideas to help make an educated guess.

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

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

In my last article on Incubating Innovation, we explored the culture and mindset of accountable experimentation. This article focuses on actionable tools and approaches.

Within agile frameworks, the team retrospective is the primary workshop for planning and evaluating experiments. Yet most team retrospectives I see are broken.

Teams spend too much time recording viewpoints and information—but not enough time reviewing or planning experiments. It is common to see the majority of the time spent gathering what went well, what did not go well, and appreciations. Yet where’s the focus on experiments, the learning process and trials for the next iteration?

Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

(Over at ProjectManagement.com January’s theme was “New PMs”. I wrote this article about the choices of approach we have and ways for new PMs to navigate them.)

These days, new project managers are exposed to conflicting guidance. On the one hand, there is a plethora of traditional “Plan the work, work the plan” literature. On the other, media is full of light-touch, self-organizing team advice. These sets of recommendations often appear to be at odds, so what is the new PM to do? Consultants will say, “Oh, it depends…” and start a lengthy (aka expensive) conversation. I say let’s examine the basics so we can make an informed decision ourselves.

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

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

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

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

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

Predictions like “AI will take our jobs” sound scary. However, long before our jobs as project managers are taken, AI will help us. In fact, it already is, and we don’t think about it much. While writing this article, AI in Microsoft Word and the add-in Grammarly helped protect you from the bulk of my spelling and grammar mistakes. This is how AI will help us first, by doing small things we are error-prone with, before tackling larger tasks.

Like me, do you spend time booking meetings, finding rooms, and distributing information? Do you analyze backlogs and scope outlines for potential risks, or review estimates for commonly missed activities? Artificial Intelligence (AI) can help with these tasks and many more.

Imagine having a non-judgemental expert monitoring everything you do (and do not do) at work and making helpful suggestions to you in private. This expert is constantly learning, is plugged into all the latest research and works for free. This is the not too distant future of AI assisted project management.

June was Technology month at Project Management.com, and there have been a few articles about AI taking away project management jobs. This article focusses on ways AI can help project managers which will happen as AI develops and before it can replace jobs. It deals with automating the process and science parts of project management, leaving people more time to focus on the relationships, leadership, storytelling, empathy and emotional intelligence side of projects that are harder to tackle and are (currently) best done by people.

AI has come a long way since Microsoft rolled out the annoying and not so helpful “Clippy” Office Assistant tool in 2003. It was never tuned for project managers, but it if were it might have looked something like this:

Instead, AI is becoming more sophisticated and useful. Gmail will remind you to attach a file if you mention “attach” in the text of an email that has no attachment. Most people use personal assistants like Siri and Cortana on their phones, or Alexa in their homes. Voice recognition and comprehension are steadily increasing. Google recently demonstrated their new Google Assistant calling and interacting with a hair salon to book a haircut. Clearly, these tools will soon be ready for prime time and their use will be widespread.

Kevin Kelly, futurist and founding executive editor of Wired magazine, says in his TED talk: “Everything that we have electrified, we are now going to cognify”. In other words, we will add intelligence to devices and products. Kelly went on to say, “I would suggest that the formula for the next 10,000 start-ups be very, very simple: take X - and add AI.”

To understand how AI can help project managers, let's examine its basic capabilities.

• Knowledge Based Expert System (KBES) – these work from decision trees of IF - THEN statements to provide expertise. Gmail’s attachment reminder works with similar IF body_text includes “attach” AND Attachment = False THEN issue a warning.

• Artificial Neural Network (ANN) – these systems model our real brains and consist of networks of weighted connections. They can be programmed to learn, recall, generalize and apply fuzzy logic. So, if we teach it someone 4ft high is Short and someone 6ft high is Tall it can generalize that someone 4ft 6 is “Not very tall”. Being able to make these types of generalizations are important for realistic interactions with people, such as Google Assistant making a hair appointment.

• Machine Learning – this builds on Knowledge Based Expert Systems and Artificial Neural Networks to create predictive analytics that can provide validation and advice. In the project management space, this is the technology that can help with checking for missed risks, rebaselining plans, recalculating the Cost of Delay for waiting initiatives, etc.

• Chatbots - AI powered programs designed to simulate a conversation with humans. Chatbots use artificial neural networks and machine learning to combine domain intelligence with natural language processing. This gives the impression of interacting with a (currently somewhat) knowledgeable person.

If these technologies sound far-fetched in the project management field, consider the quote “The future is already here — it's just not very evenly distributed”. Agile tool vendor Atlassian, already provide project assistants that help with budgets, estimates, and sprint management. They also have chatbots to share project information and remind team members for estimates and status updates.

Moving forward, these tools will be expanded to help check our work for common mistakes, just as Word checks for common spelling errors. Every industry has catalogs of defect origins and removal methods (here is one for software projects) AI assistants can apply this knowledge and suggest steps to help avoid or reduce these risks. It is not an exact science and as a project manager, I may choose to dismiss potential risks flagged. However, having assistants available to highlight these risks or list the top 10 estimation omissions in my field is probably better than not having them.

AI assistants can also alert project managers to slowly developing trends that might otherwise go unnoticed. The old saying that projects become late one day at a time is very true. Optimistic project managers with “Can-do” attitudes often underestimate the impact of small setbacks and or hope that teams will “catch-up” later.  This hardly ever happens, and AI assistants can be programmed to alert early and avoid hope-based-planning.

Over-Reliance?

There is a risk that with expert knowledge systems, organizations may be tempted to use inexperienced project managers. Or project managers become reliant upon these tools and not think as deeply as they may otherwise. Like any technology, a fool with a tool is still a fool. However, tapping into standard risk lists from your industry, that gets augmented with those from previous projects in your organization is a smart move.

Having calculators has likely reduced our ability to perform long division calculations manually. However, I don’t want to go back to self-calculation just because I fear an over-reliance on technology. Instead, I want to use technology where I can and free up my time and mental capacity for other work.

Higher Value Work

The PMI Talent Triangle is a good model for thinking about all the work a project manager does. It includes: 1) Technical Project Management – the project mechanics described in the PMBOK Guide and Agile frameworks, 2) Strategic and Business Management – your industry-specific work, and 3) Leadership – the people dynamics of projects.

If we squash the triangle out and lay the pieces in order of how much impact the project manager’s contribution has towards project success we get: Technical, then Strategic, and then Leadership. By this sequence, I mean that if the basics of Technical Management are met then Strategic and Business Management work is more significant. Furthermore, good Leadership has an even greater impact on overall project performance than Strategic and Business Management Work, and Technical Project Management.

This sequence is shown below:

The good news for us as project managers is that (currently) AI is best suited for the lower value end of this work spectrum. It is already capable of assisting and saving us time with Technical Project Management work. Next, it should soon be commonplace to get AI assistance with Strategic and Business Management tasks. This will involve accessing machine learning focussed on our industry domains, like ROI models, common risks, and estimation omissions.

The last area AI will move into is the Leadership domain. Machine learning requires deep data sets in a consistent form to draw reliable conclusions. The people dynamics of motivation, conflict management, and negotiation are harder to classify and rank.  Currently, most people would rather work with a real person to solve issues or discover their calling. Who knows, maybe in future people will prefer to interact with chatbots who’s decision parameters can be shown to be neutral and fair. This might be preferable to dealing with people with all their inherent bias and gaps in knowledge.

All I know for now is that I currently welcome any AI assistance I can use. It is likely to safeguard me from making basic technical project management errors or omissions. It should also be helpful soon in providing industry knowledge and best practice – like having a seasoned professional in the industry available to look over your work. However, AI tools will check in real-time before you commit that decision or share a plan.

This leaves me more time to focus on the people. The people sponsoring the project, those working on it, and those who will be impacted by it. They will have their own AI assistants too. Booking meetings, getting rooms, and sharing ideas should become frictionless leaving us to work on the more significant issues.

My recommendation is to stay abreast of AI developments and remain open to trying the tools as they emerge. Standing still in an environment that is moving forward has the effect of moving backwards -which is not good. Where I should probably be more worried is in writing articles like this. It seems like a blend of domain-specific Strategic work with some Leadership based storytelling. Likely a candidate for an AI takeover long before the project manager. (My plan is to get in on the research and get a Chatbot writing this stuff for as long as I can get away with it!)

References:

1. How AI could Revolutionize Project Management, CIO Magazine, Mary Branscome, January 12 2018
2. 3 ways AI will change project management for the better, Atlassian Blog, April 7, 2017
3. Artificial Intelligence in Project Management - Is Your Company Ready for it?, Teodesk Blog, Minja Belic, January 22 2018
4. AI will Transform Project Management. Are You Ready?, PWC White paper, Marc Lahmann, et Al, 2018
5. Artificial Intelligence in Project Management, Khaled Hamdy, March 2017

[Note: I wrote this article for ProjectManagement.com, it first appeared here – free membership required.]

I am excited to be presenting on the Enterprise Agile track at the Agile 2018 conference in San Diego, August 7. I have worked with several organizations this year that had issues with work dependencies between teams. My session called “Two-Pizza Team Heartburn Relief: Solutions to Team Dependencies” highlights the shift to global rather than local optimization.

We will investigate dependency problems through animations and simulations and then explore some candidate solutions. Each brings their own issues – if these problems were solvable they would have been already, but the suggestions do help considerably. Here is the description from the conference program:

Small teams are great - until they cause bigger problems than they solve. Small teams can communicate more effectively than large teams. They can leverage face-to-face communications more readily and share tacit knowledge without the need for so much written communication. However, for large endeavours, using many small teams present their own problems. Work dependencies between teams can cause major delays through costly hand-offs, mismatched priorities, and blocked tasks.

This workshop introduces strategies for structuring teams to reduce hand-offs and dependencies that create blocked work and delays. By investigating the (lack of) flow through multiple teams we can diagnose the cost of hand-offs and culprits of delays. We examine tools for making hand-offs and dependencies visible to highlight and bring collective attention to the problems. We then explore resolution patterns and work structures that maximize small team communications but limit negative aspects of managing multiple, inter-dependent project teams.

Learning Objectives

• Understand the time and cost penalties of team dependencies and hand-offs
• Gain tools for making dependencies, queues, and blocked work visible
• Learn how and when to balance small team benefits with more dependency issues
• Share implementation patterns and strategies to maximize team throughput
• Examine the pros and cons of larger teams, feature teams, and product vs. project development.

That probably sounds more technical than it really is. It is a workshop to show people how teams often get stuck with work items when they rely on work from other groups. It combines anecdotes and experiences from 20+ years of agile consulting along with some insights from Troy Magennis on dependency delays, and Dominica DeGrandis, author of Making Work Visible.

Through case studies and exercises, we explore the hidden impacts of well-intentioned small teams. First, we’ll explore the “mostly harmless” two and three team dependencies, and then see the impacts when five or six dependant teams try to get work done. Please come along if you are attending the conference and have issues with dependencies between teams.

I am excited to be presenting at next week’s PMI-SAC Professional Development Conference on May 2 in Calgary. I am looking forward to seeing old friends and meeting new people at this new format conference.

My session “Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?” examines the hype, realities and use of agile approaches.  Here is the presentation summary from the conference site:

“The project world seems to have gone agile mad. The PMI has stuffed agile into everything in an attempt to stay current, but is it right or even helpful? Fear of missing out has vendors claiming to be agile and executives asking managers to be more agile. However, like InstantPots and cryptocurrencies, does the reality live up to the hype?  This session investigates the agile trend and looks at a new breed of agile suitability filters that help organizations apply agile approaches only when and where they make sense.

The presentation profiles organizations that effectively use agile approaches and how to build PMOs that support agile, hybrid, and traditional project teams. We look at the limitations and applicability concerns of using agile approaches. It would be naïve and arrogant to believe that agile (or any other approach) is universally the best way to execute projects. So, what types of projects do suit the approach (spoiler alert: novel, knowledge-worker projects) and what types of projects should best avoid it?

We will explore hybrid approaches where certain portions or periods of the project can exploit agile approaches. In these hybrid scenarios, we examine how to coordinate and integrate the agile work with the more traditional, plan-driven work. Also, we will examine the cultural fit of agile approaches and investigate how corporate mindsets and values effect structures and decision making. Trying to force fit a new mindset that is at odds with the corporate culture will inevitably be met with resistance. So, we need to be smart about what we try to introduce and how we plan to do it.

Our end goal should be successful projects and happy stakeholders. The approach we take should be appropriate for the tasks at hand, there are no points for style or conformance, since every project is different. So, learn how to analyze the project variables that include organizational, standards, technical and team components then act intelligently within that framework also guided by the inputs of the contributors.”

That description was for a 2-hour slot proposal and I was assigned a 1-hour slot so I will have to cut some material, but I will cover the highlights. The presentation title and outline are deliberately a little controversial to hopefully spur some reaction and interest in the session.

Having been involved in the development of the recent PMI standards, I personally do not believe “PMI has stuffed agile into everything in an attempt to stay current”, however, I can see how this may appear so to external parties.

As agile rides the hype cycle it is important to retain a grasp on where it can add value and where it’s use should be limited. This session aims to strip away some of the hyperbole and ground people with some practical application tools. Please come say hello if you see me at the conference!