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!