People Problems: Dealing with Dark Triad Traits

Dark Triad Personality TraitsMost of us will experience challenging and downright toxic people at some point in our careers. If you ever have, then you can probably see, in retrospect, how much those individuals differed from ordinary people. Yet, at the time, their impacts may have seemed so upsetting and jarring that it is quite common to question whether we had it wrong or contributed in some way toward the situation.

So, having some strategies for dealing with these people can save your sanity and provide pathways through the issues while also protecting others.

Fortunately, truly toxic people are few and far between. Most people we deal with are generally helpful or at least neutral. Occasionally, we encounter people with challenging personalities: people who unknowingly or deliberately bully, undermine, manipulate, or sabotage work, relationships, and people's self-esteem. Being unaware of these personality types can derail projects and cause high levels of personal distress to ourselves and other team members.

While terms like vindictive, argumentative, and manipulative might begin to describe these people, a more scientific understanding is helpful. The term Dark Triad is used in psychology to describe three negative and harmful personality traits. Some people have one or two of the traits, while others have all three.

 

Dark-Triad Traits

The dark-triad traits are Narcissism, Machiavellianism, and Psychopathy.

 

Narcissism

 

Narcissism

Narcissism is vanity, self-love, and having an overly inflated view of yourself. It is manifested through characteristics such as perceived superiority, entitlement, dominance, and self-admiration. Narcissists are egotistic, often lacking in empathy, overly sensitive to criticism, and have inflated views of themselves. Unfortunately, that self-love and inflated ego mean they generally dress well, interview well, and are happy to talk about their accomplishments, and so get hired into positions of power and influence.

 

MachiavellianismMachiavellianism

Machiavellianism is manipulation to get what is wanted. It includes a disregard for morals and the ready use of deception. It is driven by self-interest and is marked by traits such as being self-serving, immoral, deceitful, and cunning. Machiavellian people are often emotionally detached, cynical, and lack principles. They can be domineering and, because they are so sneaky, often do well in office politics, rising to positions of power and influence.

 

PsychopathyPsychopathy

Psychopathy is having little or no empathy for others, combined with high levels of thrill-seeking, impulsive behavior. Psychopaths exhibit aggressive, antisocial behavior without guilt. They are remorseless but can appear extraverted and superficially charming. Unfortunately, this can lead to—you guessed it— promotions and positions of power and influence.

 

You probably recognize these personality traits in people you work with, even if you do not apply the same labels. Like all personality traits, they exist on a spectrum. In mild forms or infrequent bursts, they do much less harm than severe or prolonged exposure.

 

How to Handle These People?

Knowing about these traits is extremely important because it allows us to adjust the "volume control" in terms of how these people impact us. Without understanding these traits, it is easy to be swayed and confused, and even question our contributions toward the conflict and problems these people create. Once we know how to recognize these traits, we can adjust our behavior around and involvement with these people.

A safe default strategy is to disengage and avoid people with dark-triad traits. However, we sometimes manage people with these characteristics, work alongside them, or report to them. In these cases, avoiding them is impossible, so here are some strategies for minimizing their impact.

 

First, Check if You are the Problem

First, we need to make sure we are not the problem (i.e., that we do not have dark-triad personality traits ourselves). Dr. Peter Jonason and Gregory Webster developed the Dirty Dozen rating scale to roughly assess dark-triad traits. It asks people to rate themselves on a scale from disagreeing to agreeing with these statements:

  1. I tend to manipulate others to get my way.
  2. I have used deceit or lied to get my way.
  3. I have used flattery to get my way.
  4. I tend to exploit others toward my own end.
  5. I tend to lack remorse.
  6. I tend to not be too concerned with morality or the morality of my actions.
  7. I tend to be callous or insensitive.
  8. I tend to be cynical.
  9. I tend to want others to admire me.
  10. I tend to want others to pay attention to me.
  11. I tend to seek prestige or status.
  12. I tend to expect special favors from others.

The higher the score, the higher the concern and the greater the need for some empathy training. Most people continue developing their EI, including empathy, as they age.

I know early in my project-management career, I was liable to employ Machiavellian approaches to increase the success rate of my projects. I did not do anything too sinister, but I would book meeting rooms far in advance, in case we needed them, and claim favorable go-live dates when the best support staff were available. Now, I am much more willing to give up/trade rooms/dates for the organization's greater good or help people out when possible. It was not a monster-to-saint transformation but a more considerate mellowing with age. But let us talk about the real problem cases.

 

Dealing with Anger, Aggression, and Bullying

These are usually linked to psychopathic traits. If you see people frequently getting angry, shouting, or acting aggressively, or their anger spilling over into bullying, you must act quickly but carefully. Also, be aware that some people suppress their anger and instead brood, sulk, or ignore people. These are passive-aggressive behaviors that also need dealing with.

First, stay safe: do not put yourself in a situation with physical conflict. It is always better to walk away and engage HR. However, assuming the anger levels are lower, such issues must be dealt with. Resist the temptation to match the person's raised voice; instead, listen dispassionately and try to diagnose the cause of their issues. Techniques like questioning, active listening, and appreciative inquiry might help reveal why they behave as they are. If not, it may be time to recommend counseling, either directly to the person, if they acknowledge the issue, or to HR, if they will not.

When bullying is involved, be it verbal abuse, threatening behavior, or just unnecessary criticism, it is crucial to support the victim in addition to addressing the perpetrator. Leaders should listen for concerns both formally and informally. We are closer to team members than the senior level and can better spot shifts and pattern changes in behavior.

When someone does something you feel is disrespectful, have a conversation with them about it (if you feel it is safe to do so). We cannot assume that someone is a bully if we have not told them their behavior appeared disrespectful because we have not allowed them to understand our view and the opportunity to change.

We must also walk the talk, treating all stakeholders respectfully and encouraging respectful interactions through all communication channels. We often set the tone for workplace behavior, and people watch us for cues.

We should arrange, support, and attend training, then provide ongoing training on respectful workplace interactions. Having people acknowledge workplace policies during orientation is not enough. Everyone needs to know specific acceptable and unacceptable behaviors and be trained to handle aggression and bullying when it occurs.

 

Tackling Manipulation and Double-Dealing

These are Machiavellian traits. Manipulative people are skilled at hiding their behavior. They often present one face when it serves them well and then another, altogether different persona when that serves them better.

Look for people who will not take no for an answer, always have reasons and excuses for their hurtful behavior, or switch personas to suit their circumstances. Due to their chameleon-like nature, we need to be specific about pointing out what behaviors we have noticed and how they negatively impact the team.

Talk to them privately first. If you see manipulative behaviour in a meeting, hallway, or desk conversation, try calling out the manipulator in private first. It allows them to explain (but be prepared to see a different persona) and change their ways.

If that does not work, call out the behavior publicly to show that it will not be tolerated. This reduces the opportunity for the manipulator to lie or play dumb about the situation. It also shows everyone what is going on and builds allies for additional intervention and support. Follow up with them in private again, clearly explaining how their behavior must change, and consider implementing conduct agreements or performance agreements to hold them accountable.

Manipulators are often driven by insecurity. They are trying to build power through knowledge and connections. They often start out acting friendly with people to learn about them and gain personal information they can potentially use later for their own purposes.

An effective strategy for disarming them of power and influence is to form closer relationships with other people in their network. If the manipulator is a network architect, have lunch with some of the other network architects and the manipulator's boss. Once they see their source of power dwindling, they feel threatened and switch from manipulating others to defending their own career which they believe is linked to their connections and knowledge.

Ultimately, we want offenders to see the greater good of the team members and the organization they work in. Information does not become less valuable as it is shared. Helping others is a more powerful strategy for self-promotion than undermining them—it just takes longer to germinate.

 

Handling Entitlement and a "How Does That Help Me?" Mentality

These are signs of narcissism. There is less to worry about here. Excessive use of I and me language, as opposed to us and we language, is a telltale sign that we are dealing with a narcissist who can upset team harmony and performance.

With big egos often comes the denial of fault and an expectation of not being challenged, so it is essential to be direct and specific about how their actions impact team performance. Confront the perpetrators and explain the impact of their behavior. Come prepared with feedback and recent examples or evidence of their selfish actions. Suggest how to be more inclusive and supporting and better serve the team.

Follow up with team members to see if they are keeping these characteristics in check. They will unlikely transform into selfless servant leaders, so toning their behavior down to tolerable levels is often the best we can hope for.

 

Summary

Unfortunately, manipulative, nasty people are part of life. Being aware of the dark-triad traits can help us spot them a little earlier, somewhat negate their impacts, and provide us with some strategies for dealing with them.

The traits include the following:

  • Narcissism is characterized by self-love, superiority, dominance, and an inflated view of oneself.
  • Machiavellianism is characterized by a disregard for morals, the use of deception, and cynicism and cunning.
  • Psychopathy is characterized by thrill-seeking, impulsive behavior, aggression, and a lack of empathy and remorse or guilt.

 

Review the Dirty Dozen categories to see if 'we are surrounded by gullible idiots' (i.e., you are the problem) and, assuming you are not the problem, ask yourself if you see those characteristics exhibited by others. Bullying needs to be dealt with, and HR should often get involved. Double-dealing often stems from insecurity, which can be used to rein people in and neutralize their impact.

To be forewarned is to be forearmed. In other words, knowing a little about toxic people can help us avoid them or reduce their impact.

[This post is an extract from my book Beyond Agile– a hybrid model for blending agile with additional emotional intelligence and leadership skills. You can read much more about the Power Skills to build and troubleshoot high-performing teams in the rest of the book Beyond Agile 150]


Definition of Broken (DoB): A Tool for Improving Communications and Outcomes

Definition of BrokenCommunicating 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.

 

OriginsOrigins

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

Tolerances

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.

 

ExamplesA Couple of Examples

On a project to implement a 3rd 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 30th

(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 30th, 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.

 

Risk ManagementHow 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 ImplementHow 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 15th
  • The pumping station is not operational at full capacity by year-end
  • Telemetry software not completed and accepted by Feb. 28th

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 1st
  • Page load speeds over 3 seconds
  • Critical bug cycle time > 2 days
  • Team eNPS below 30”

 

Parting thoughtsParting 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. 

 

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


Agile Adoption – Left to Right is the Way to Go

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.

Crossing the Chasm
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.

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.

How to Adopt Agile

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.

How Not to Adopt Agile

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.

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

Cargo Cult

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.

Maps

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 upDaily 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 DemoSprint 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 BacklogProduct 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 PlanningRelease 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 PlanningSprint 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.

 

RetrospectiveRetrospective – 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 boardKanban/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.

Agile Matrix

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.


Book 150<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.>



Hybrid Agile Discussion

Hybrid Agile banner

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.

PMI San Diego Chapter

Registration Link


The Perfect Storm for The Project Economy

Perfect StormThe winds of change were strong before the COVID-19 pandemic. Driven by three macroeconomic trends, the need for projects and project managers was increasing. These three trends are:

1) Accelerating rates of technology adoption

2) The switch to alternative energy sources to maintain GDP and meet emissions targets

3) Infrastructure projects for population growth.

These movements occurring together were spawning an explosion of projects to turn ideas into reality. This increase in project demand was christened The Project Economy by PMI in 2019.

To be fair, these trends and strategies for handling them had already existed for more than a decade. Globalization and business transformation have been discussed extensively. Eric Ries documented his lean startup methodology in 2008 as a way for organizations to adapt and experiment with new ideas and perform market tests. It provided a framework for rapid adaptation and customer-centric design that is baked into many of today’s strategies.

Continue reading "The Perfect Storm for The Project Economy" »


Returning to the (Electronic) Cottage

Electronic CottageThis 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.

Continue reading "Returning to the (Electronic) Cottage" »


Innovation: Running Experiments and Learning

Experiment DesignIn 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?

Continue reading "Innovation: Running Experiments and Learning" »


Focusing on Results, Not Agile Approaches

Focus on Business Value


Quarter Century

25 Years Agile2019 marks the 25 year anniversary of Scrum and DSDM. I was involved in the creation of DSDM in 1994 and was an early adopter of Scrum and FDD shortly afterward. Now, having been at this for a quarter of a century I am reflecting on where my journey has taken me compared to others.

I am agnostic about agile. I value the mindset and goals more than approaches that preach a single path. This has had mixed blessings for me. I remain agnostic and impartial, but I have not jumped on any of the approach bandwagons.

Continue reading "Focusing on Results, Not Agile Approaches" »


AI Assistants for Project Managers

Robot hand
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:

ClippyInstead, 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:

AI Focus

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

 


Agile 2018 Conference – Unraveling Team Dependencies

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


Mining Bitcoins with Your InstantPot: Has Agile Popularity Gone Too Far?

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

PMI-SAC PDC Banner


Where Did All the Project Managers Go?

PuzzleSoftware is eating the world” claimed venture capitalist, Marc Andreessen in his 2011, New York Times article. Seven years on, the trend continues, and project managers are also on the menu. The next generation of project managers face new challenges but also new opportunities as organizations undergo a major transformation.

Software is becoming omnipresent, it is embedded and integral to all industries. Not just technology companies (like Google, Apple) but every sector is being disrupted by software including retail (Amazon), banking (PayPal, cryptocurrencies), transportation (Tesla, Uber), and travel (Airbnb).

As a project manager you may say “Great, just think of all those IT projects that will need project managers!” Well, that’s where things get interesting. First, today’s software teams don’t respond well to being “managed”, that’s old-school command-and-control thinking along with Gantt charts and calling people “resources”. Instead, they are led, empowered and supported by servant leaders. Next, the idea of a “project” with a defined endpoint is dissolving too.

As organizations realize their software systems provide the competitive advantage then stopping development equates to an end to innovation or competing. When organizations become more software-driven their systems are never “done”. As a result, organizations are switching from projects (that have a fixed end) to products - that continue to evolve. This movement popularized by the #NoProjects and Continuous Digital titles is growing exponentially.

 

 The Project Manager in a No Projects, No Managers Future

This double whammy of no more projects and no more managers likely creates heartburn for people with the job title “Project Manager”.  While this trend is clearly the future of work, I believe there will always be a role for smart, cooperative people that can help with collaboration and development. 

 A quote that comes to mind is “The more things change, the more they stay the same.” by Jean-Baptiste Alphonse Karr. The next generation of project managers will have new titles like “Product Leads”, “Development Team Coordinators” and “Digital Transformation Leaders”. They will help organizations build development capabilities around long-term products.

 This new generation will still communicate with stakeholders about status and risks. They will still facilitate consensus gathering amongst experts. They will still try to diffuse conflict and find common ground during arguments. The goals (satisfied stakeholders and value delivery) will remain the same but the tools, titles and processes employed will be vastly different.

 

New Tools and Approaches

Heavy upfront planning efforts and the use of tools like critical path network diagrams and PERT charts are not so useful when the input data is very uncertain. Tools like work breakdown structures offer great insights into sub-system assemblies but they are slower and more difficult to reprioritize than modern backlogs and release roadmaps.

As rates of change increase so too does early lifecycle uncertainty and the competitive need to start work quickly. The days of carefully analyzing work products upfront are dwindling. Instead, organizations build prototypes based on what they know right now and then iterate towards the final product. In the intangible world of software, the cost of experimentation is less than that of detailed analysis.

Also, using a software product provides better feedback on its suitability and possible expansion than reviewing a document or diagram about it. IWKIWISI (I Will Know It When I See It) becomes the new mantra, replacing the “Plan the work, and work the plan” ideas of old.

As organizations adopt a continuous delivery model that is focussed on products not projects then funding models change also. Instead of yearly budget cycles to fund entire projects, smaller tranches of funds are released to create a Minimum Viable Product (MVP). Then, providing the product continues to return value, more funding is made available. A venture capital funding model lets product leaders focus on delivering a stream of high-value features that support continued investment.

Projects classically track metrics like on time/budget and Return On Investment (ROI). Products track customer satisfaction, market share, profit to funding ratios. They are similar concepts but a new vocabulary to learn.

 

Role Changes

Agile software development teams organize their own work, solve most of their own problems, and are empowered to experiment with new work strategies and approaches. They do not need (or want) to have work assigned to them, nor asked to report status. Instead, they make their work visible via kanban boards and new features.

They do however need people to remove impediments and chase up external dependencies. They also need investment in training, shielding from interruptions, plus regular encouragement and words of thanks to stay motivated. In short, all the servant leadership practices that good project managers did anyway still apply.

Project managers cannot be the center of work planning or task distribution. There is too much complexity to be anything but a bottleneck. Instead, we must trust development team members and product owners from the business as subject matter experts in their own domains.

Where these teams often need help is keeping the larger perspective on where it is we are trying to get to. When you are heads-down on solving a technical issue, it is easy to lose sight of the end goal. Having someone communicate the product vision reveals a beckoning summit towards which others can chart their own course.

In this way servant leadership and visionary leadership that predate modern project management are still valuable and needed. Yet the scientific project management that grew out of the industrialization of process is largely left behind.

 

The Future

In many industries, the classic role of projects and project managers will continue. I don’t see construction moving away from big upfront design and the reliance on project managers any time. In the software world though I think we are heading for substantial changes. Sure, some companies will continue as they always have with software project and project managers. However, most organizations will transition to long-term products with leaders and coordinators.

It is an exciting time for life-long learners willing to acquire new tools and approaches. There is no shortage of work for people who can collaborate with others and solve problems. The critical role of software will increase as organizations undertake digital transformation and adopt continuous digital strategies based on products vs projects. So, while the role “project manager” might be heading into the same category as “switchboard operators”, “human alarm clocks”, and “bowling alley pinsetters” the work and opportunities in this exciting field continue to grow.

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


Government Lessons in People Over Process

CubicleMy first opportunity to create and run a large agile team did not start well. Having had good successes with small to medium sized agile teams I was keen to unleash the benefits on a bigger scale. I was working for IBM at the time and was able to persuade my account manager to pitch the approach on one of our government projects. A clean-sheet development opportunity with a smart team and engaged business group – what could go wrong? As it turns out, plenty due to my ill-advised approach.

It was the early 90’s and we were trialling techniques that would later become the agile approach DSDM (Dynamic Systems Development Method). Taking ideas like James Martin’s RAD (Rapid Application Development) and active user involvement from Enid Mumford’s Participative Design Approach, we had already dramatically reduced development time and improved acceptance rates on several projects. I was convinced collocated teams with short iterations of build/feedback cycles were the future. We were all set for a big client success and who better than the British Government for good publicity! My enthusiasm was about to be tested.

I was given a full rein of the project, or as I would later realize, just enough rope to hang myself with. Having struggled to get dedicated business input on previous projects I commandeered a large boardroom to collocate the development team and business subject matter experts (SMEs). It was awesome, everyone was together in one room and we had direct access to the business representatives for requirements elicitation, clarification, and demo feedback. We were working hard and getting lots of features built but the business representatives hated it.

At first, I thought they hated me. I think that is a common mistake, we internalize changes in behaviour as attacks or criticisms of ourselves. What have I done? What did I say to upset them? - all of them! I recall wanting to write on my internal project status report to the IBM PMO that “the business is revolting”. However, that is what occurred, starting as cordial and helpful, the business SMEs became less helpful, then uncooperative, and finally hostile. I had a revolt on my hands that I did not understand.

This was my first introduction to organizational change. Luckily for me, I had access to many people in IBM smarter and more experienced than I was. I was given a book called “How to Manage Change Effectively: Approaches, Methods, and Case Examples” by Donald Kirkpatrick that changed my career. In it Kirkpatrick outlines circumstances where people will resist change. These include:

  1. When people sense loss in: security, pride and satisfaction, freedom, responsibility, authority, good working conditions, and/or status
  2. It creates more problems than it is worth
  3. Extra efforts are not being rewarded
  4. Lack of respect for those initiating the change
  5. The change initiative and its implications are misunderstood
  6. Belief that the change does not make sense for the organization
  7. Change is misdirected, current state or alternatives are better
  8. A low tolerance for change in our lives
  9. When change violates a principle or commitment that the organization must stand by
  10. Exclusion from the change initiative
  11. Changes viewed as criticism of how things were done in the past
  12. The change effort occurs at a bad time, other issues or problems are also being handled

Something I was not aware of at the time is how the career development process works within the government. The most junior new hires work in open-plan cubical offices. Then as you get a promotion you get moved to bigger cubicles with higher walls that are more like mini-offices. Next, you get promoted to a real office, then an office with a window, and eventually a corner office. In short, your workspace defines your status, responsibility and authority.

By bringing these business representatives into a shared boardroom to work on the project I had unwittingly generated change resistance scenarios 1-3 and probably triggered many others also. Making them sit and work together like the most junior recruits had caused a loss of good working conditions, status, freedom, pride, satisfaction, and perceived authority. A bad idea when hoping to develop a productive working relationship with someone.

Luckily for me the Kirkpatrick book also lists circumstances when people do accept change, which unsurprisingly are the opposite conditions and include:

  1. When change is seen as a personal gain: in security, money, authority, status or prestige, responsibility, working conditions, or achievement
  2. Provides a new challenge and reduces boredom
  3. Opportunities to influence the change initiative
  4. Timing: the time is right for organizational change
  5. Source of the change initiative is liked and respected
  6. The approach of the change and how it is implemented appeals to us

So, equipped with these ideas we changed our approach. Instead of the business SMEs being collocated with us they returned to their fancy corner offices, long lunch breaks, and afternoons spent reading the newspaper - none of which they could do when they all sat together. Instead, we reserved their mornings for questions, review sessions, and demonstrations. This was better received because their morning calendars were blocked with important project meetings, but we rarely called on all of them at once unless it was for a business demo.

Now they had their offices back, a little more free time, and were engaged in a more respectful way. The team were sceptical at first. However, it really is much better to have one hour of someone who is cheerful, engaged, and helpful than eight hours of someone who is bitter, obstinate and causing issues. The project went much smoother after these changes and it taught me an important lesson in never trying to introduce a process or practice without considering the people elements first.

We completed the project early, largely due to the input and hard work during acceptance testing of the business SMEs, and IBM got their successful case study. I learned to temper my enthusiasm and consider other stakeholders who will undoubtedly have a different view of the project than myself. Individuals and interaction are indeed more important than processes and tools, even if they are your own pet agile processes and tools.

[I first wrote this article for the Government themed November issue of ProjectManagement.com, available to subscribers Here]


The Importance of Focus

Edison BulbI have an old-fashioned Edison bulb desk lamp. It’s to remind me to focus (and because I like steampunk, industrial design). A 40-watt incandescent bulb will barely light a room, but a 40-watt laser can cut through aluminium, leather, and wood. It is the same amount of light energy, just focussed instead of being diffused.

The same principle applies to our attention, work and teams. Diffused and scattered there is not much impact. Focussed and concentrated that energy is very impactful. Removing distractions and focussing on a single deliverable at a time allows us to complete our work faster with fewer defects.

Aligning a team to a common vision and purpose directs their energy towards it. No longer diffused to fulfil a dozen competing demands, effort is channelled to the shared goal. Distractions come in many forms. Fancy tools, cool architecture, requests from different groups. If we do not pay attention to focus, our laser beam team becomes an Edison bulb, it is busy and glowing, but not very effective.

So, be cautious of distractions. Monitor time and energy directed to the project goal compared to energy directed to peripheral activities. Work life is like a greased pole with a 40-watt Edison bulb at the bottom and a 40-watt laser at the top. We must always be striving upwards to focus because as we relax we slide down towards distraction.

(Also visible in the picture is my “Do The Work” Post-it. another reminder to focus and a pointer to work on the same topic by Seth Godin and Stephen Pressfield. I guess I could get a 40-watt laser too, but that would scorch the cat rather than amuse it. Plus yes, it is snowing here and yes, my windows are old)


They are “Lessons to be Learned”, not “Lessons Learned”

The suggestions, observations and ideas we capture at retrospectives are not Lessons Learned. That would imply we have already learned from them and will not make that mistake again. Instead, they are Lessons-to-be-Learned which is subtly different but stresses the most important part, which is we now need to learn something.

Learning involves several steps. David Kolb, an educational theorist, describes a 4-step learning process:

  1. Concrete Experiences (What we already know)
  2. Observation and Reflection (What our retrospectives help us identify)
  3. Abstract Conceptualization (Thinking about the problems and designing potential solutions)
  4. Active Experimentation (Trying something new)

These stages act as part of an experimental learning cycle. The last step, Active Experimentation, creates new concrete experiences and builds on what we already know. Experimental Learning Cycle

It is easy to confuse the retrospective actions of Observation and Reflection (Stage 2) as gathering lessons learned. However, this is not the case, instead it is just one step in the process. We then need to determine a solution (Stage 3) and run experiments to learn from them (Stage 4). Only then might we actually learn something.

To remind us that simply gathering ideas and suggestions for improvements is not the same as learning, I suggest we stop using the term “Lessons Learned” and instead useLessons to be learned”.