Inspection and adaptation are two of the pillars of the Scrum framework but all agile methods recognize the wisdom of Deming's Plan-Do-Study-Act cycle.
While the Manifesto does not explicitly reference the scientific method, it is implied in the value statement "Responding to change over following a plan" and in its final principle "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Agile teams embrace experimentation in many ways.
Some of these relate to the product. Minimum Viable Products and Minimum Business Increments can be designed and run to test hypotheses about what we feel is valuable to customers at a macro level. Split testing and similar short feedback techniques might validate whether specific features should be pursued or not.
Some relate to the team's delivery process.
Both the Rational Unified Process and Disciplined Agile Delivery highlight the importance of proving solution architecture early and one effective means of doing this is through the design, construction and execution of experiments focused on quality attributes such as performance or flexibility.
Working agreements such as Definitions of Ready or Definitions of Done can be thought of as experiments to validate whether teams are able to efficiently complete work items and whether teams understand what complete means.
Ceremonies such as retrospectives help a team to identify delivery improvement ideas. Rather than assuming these ideas will help and implementing them on a broad scale, teams will run experiments to see whether these ideas actually show promise. For example, improving product quality through pair programming might seem like a good idea so a team might elect to try pairing on a subset of their upcoming work items and comparing the outcomes to those completed using their previous methods.
Spikes are another form of agile experimentation. Rather than losing significant effort in comprehensive analysis of a specific uncertainty, a short time boxed deep dive focused on learning which options might be feasible is often a better alternative.
So how could adopting this commitment to experimentation help those teams using a predictive life cycle?
Assumptions which have not been validated are a common source of project risks. While a team could wait for an assumption to be passively proven, wouldn't it be more effective to frame a critical assumption as a hypothesis and then design and run an experiment to get data to make the team feel more confident about that assumption?
Incorporating ongoing experimentation into the risk management life cycle might provide a more effective method of de-risking all types of projects.
In his latest book, Talking to Strangers, Malcolm Gladwell writes about the problems which can result when we expect that there is alignment between how people act and how they really feel internally. Gladwell call this the transparency problem and provides multiple examples to illustrate the challenges we face when we assume that what we see is what we get.
He presents the assumptions which Neville Chamberlain made in the years leading up to World War II based on the meetings he had with Adolf Hitler. Chamberlain assumed that Hitler was being genuine when he indicated that he had no interest in starting a major conflict in Europe and yet his near term actions clearly showed that this was not the case. He talks about the difficulties which judges face when having to decide whether or not to grant bail based on not only case information available to them but how an accused behaves when they are in front of the judge. And he writes about the Amanda Knox case where Italian authorities assumed that she was guilty of murdering her roommate primarily because of her behavior when she was questioned after the incident.
Gladwell sorts people into those whose external behavior matches what is happening inside of them and those who don't. We are quite good at identifying matched people. In fact, Gladwell indicates that our ability to detect when a matched person is lying is almost as good as that of law enforcement experts. What's chilling is that when dealing with mismatched people these experts are no better than we are.
It is not that assuming transparency is a bad thing to do. As Gladwell states, Charles Darwin felt that transparent behavior was critical to creating trust between strangers which enabled our species to survive.
But what's the relevance of this to project delivery?
When interacting with those who we've never worked with before, most of us default to expecting transparency. When someone appears to be acting in a negative manner, this assumption might result in us becoming offended. Alternately, we might be getting warm, friendly vibes from a team member which causes us to assume that they are on our side only to be shocked when their subsequent actions prove they were not supporting us at all. In the latter situation, the individual may be purposefully deceiving us by providing false "tells" (to use the poker term) but in the former, it might simply be a case of someone who is mismatched.
This is illustrated in the movie Joker. Joaquin Phoenix's titular character is prone to burst out laughing hysterically at inopportune moments as a result of childhood head trauma. Strangers exposed to this behavior assume transparency and respond negatively. To attempt to compensate, he has cards which he hands to offended strangers providing the justification for his inappropriate laughter.
But once we get to know that these team members are mismatched, we begin to understand them for who they truly are, and the likelihood of misinterpreting their behavior is vastly reduced. When we are part of long-lived, stable teams, we are able to appreciate the diversity of those who work with us and are able to leverage these differences as strengths and not as sources of conflict.
My formative years were the 1980's which were the heyday for slasher film series such as Friday the 13th and A Nightmare on Elm Street. With Halloween rapidly approaching I felt it might be timely to draw three parallels between the villains of horror movies and dealing with project problems.
Never say "It won't happen to me!"
A common method of identifying which characters in a horror film are likely to be eliminated early is to look for the most arrogant or overly optimistic ones. One of the more humorous examples of this is Samuel L. Jackson's character in Deep Blue Sea who gets eaten by a shark right after he has made a wonderful, passionate speech expressing his certainty in being able to lead the survivors to safety.
Project managers and their team members should feel bullish that they can successfully deliver a project, but this confidence should come as a result of effective risk management rather than blind optimism.
Don't assume it's dead
In nearly every horror movie, just when the hero or heroine believes they have successfully eliminated the monster, it finds a way to come back to life. The first Halloween movie had one of the most unexpected comeback scenes. Whereas you knew that the villains in other slasher flicks (e.g. Freddy Krueger, Jason Vorhees) were supernatural entities and hence normal human limitations wouldn't apply, in the original Halloween movie Michael Myers appeared to be a run-of-the-mill psychopathic human being. It was only at the very end of the film after Dr. Loomis has shot Michael a few times at point blank range and he's fallen from the second story of a house and managed to get away that you finally realize he's going to come back.
While it can be very satisfying to resolve a tricky project issue, we need to remain vigilant to the possibility that it could recur. If it had been previous identified as a risk, we now have quantitative data regarding its impact which we could use to be better prepared in the future.
Never say "I will be right back!"
If there is one thing a character should never do in a slasher flick, it is to head off on their own. Just as carnivores in the wild prefer to hunt prey who have got separated from their herd, movie villains delight in dispatching foolhardy wanderers. While it can be tempting to try to tackle a problem on our own so that we are feted as heroes, for resolving really challenging ones, there is strength in numbers.
One, two, project issues haunt you
Three, four, you can't ignore
Five, Six, there's no quick fix
Seven, Eight, don't hesitate
Nine, Ten, they will come again!
A frequently asked question in the main ProjectManagement.com community discussion group is about the perceived impacts of machine learning on project delivery.
Some contributors worry that sufficient advances in AI will render the role of a project manager obsolete whereas others remain bullish about the prospects for the profession.
A recent Harvard Business Review article by Stephen M. Kosslyn titled "Are You Developing Skills That Won’t Be Automated?" would support a positive outlook on this topic. In the article, the author asserts that roles in which emotion and context play a strong influence will still need to be performed by human beings. We have enough challenges with human leaders struggling to inspire team members or effectively align stakeholders to expect that machines will have an easier time doing so.
I'm expecting that enhancements in current machine learning technology will free us from rote administrative activities which even the most senior project manager finds themselves having to perform from time to time. While such advances might reduce a full-time requirement for project administrators on large, complex projects, it might enable such roles to support a larger number of projects at the same time.
What might projec managers do with all of this extra time?
Being assigned to more projects concurrently is not the answer! If we believe that project management is a strategic role then we should be encouraging greater focus, not less.
Freed up capacity could be better utilized on frequently neglected practice areas such as stakeholder engagement, risk management and knowledge creation. Envision the potential benefits to your projects if you had even 10% more time to devote to such practices.
We could also invest more in our own personal development or giving back to the profession or the community.
Is it possible that at some point in the future, AI will have the ability to independently manage a project staffed with humans?
This seems realistic if we agree with Gene Roddenberry's vision of intelligent sentient machines such as Commander Data, but I'm equally optimistic that the next one or two generations of project managers will have little to fear so long as they continue to invest in developing their soft skills.
Since I first started to learn about project management, risk management has always fascinated me.
That characteristic of uniqueness which separates operations from project work introduces uncertainties which, in turn, generate risks. Most mega-project case studies give credit to an effective risk management approach as a key contributor towards their success. But in spite of this, risk management continues to be one of the weakest practiced knowledge areas in the PMBOK.
If eternal optimism is the prevailing mindset within a company, it can be difficult for risk owners to envision things not going according to plan. What has always intrigued me is how the same leadership teams which can be moderately effective at implementing operations or business risk capabilities will be so much weaker when it comes to project risk management. A risk averse culture will take a long time to change for an overall organization, but a project manager should be able to influence it within the ecosystem of their projects.
Unhealthy levels of multitasking by project teams and stakeholders result in those practices perceived as unnecessary being jettisoned or being given lip service only. If a team barely has time to deliver the scope of their project, how can they or equally busy risk owners be expected to expend any real efforts on considering or responding to potentialities which may never be realized? And, if we combine this limited availability with "one size fits all" approaches to project risk management, it is no wonder that many teams will do the absolute bare minimum required to meet onerous governance requirements.
If team members and other stakeholders don't know what effective project risk management looks like, how can they be expected to improve? If there are no coaches to help teams improve their capabilities, improvements in risk management will rarely happen organically. Competent risk management requires exceptional interpersonal skills in addition to some basic technical skills, so hands-on practice with feedback from seasoned practitioners is needed to improve.
Finally, there might not be a realization of the positive correlation between effective risk management and successful project outcomes. In the absence of supporting internal empirical data or strong pressure from the outside to create a valid sense of urgency, senior leaders and project teams will be unwilling to sustainably invest in the required behavior and practice changes.
Providing practitioners with risk management training or evolving project delivery standards might help in some small way, but real improvements will only come when these root causes are addressed.