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?”
Litmus Test Shortcuts
Usually, I would recommend examining the nature of the work, but I recently learned of some interesting shortcuts. They are not infallible but provide a useful starting point.
A famous example of a litmus test shortcut is the “No brown M&Ms” rider that Van Halen added to its tour contracts in the 1980s. Buried in the list of backstage setup requests was “a bowl of M&Ms with all the brown M&Ms removed.” While it sounds like an example of rock star prima-donna behavior, it provided a quick visual clue as to how well the band’s complicated contract had been read.
If the backstage catering table did not contain a bowl of M&Ms, or if it did and there were brown ones present, likely other items in the contract could have also have been missed. The band used some of the largest lighting systems in the industry that required new standards of power supplies to run them. If the promotor had missed the M&Ms requirement, likely the whole setup needed to be thoroughly reviewed before testing.
Adaptive approaches, such as agile, are suitable for projects that involve significant portions of knowledge work. Knowledge work is a term coined by Peter Drucker to describe subject matter experts that collaborate to solve problems and build new products and services.
When we examine the evolution of work, we see how many people are now engaged in knowledge work. (When I teach agile approaches to organizations and university students, I have been using versions of the following three slides to explain the difference between knowledge work and industrial work for the last 20 years.)
This first slide provides an image to help describe the transition workers made from being dispersed across the land in the agricultural era, into cities to work in factories in the industrial era. Next came the knowledge era and the rise of the knowledge worker (as popularized by Peter Drucker), which can be done from anywhere.
The second slide above shows how knowledge work differs from industrial work. It is often invisible, changing and less structured. The nature of this work makes it problematic for upfront analysis and planning since many details continue to emerge throughout execution.
This third slide shows how knowledge work recommendations align with agile practices. Many of the goals from human interaction management (the execution of knowledge work) can be mapped to common agile activities. It helps cement the link that if we find ourselves managing a project that contains a high proportion of knowledge work, then we should expect high rates of change, no defined way forward and a need for adaptation and exploration.
Determining if a project fits a predictive (traditional) approach or a more adaptive (agile) one can take many forms. We can simply assess the work against the second slide of industrial worker or knowledge worker characteristics. If the work falls more in the right-hand column, an agile approach would likely be a good fit. Some projects will straddle both work types and would benefit from a hybrid approach.
When working for an oil and gas client, we had projects building new pipelines and projects writing the software to control the flow of hydrocarbon products through the pipelines. These were easy to classify; if your job was welding pipe, work is visible, specialized and stable. Conversely, the software development teams dealt with invisible, changeable work with lots of decisions to be made. The first type of work suited a predictive approach, the second an agile approach.
Of course, things get more complicated the deeper you look. Designing a new pipeline is knowledge work, and training 100 users in the use of a software system will benefit from detailed planning—so likely both project types are hybrid when viewed at a high level. Assessment tools are, at best, starting points for a more detailed discussion, but useful nonetheless.
The original 1994 DSDM suitability filter asked about many factors, including sponsor support for an iterative approach, the ability of the organization to accommodate frequent releases, and team access to the customer and team stability (among other considerations). Over the years, the characteristics used to determine the suitability of using adaptive approaches have evolved somewhat.
The 2017 Agile Practice Guide contains similar review criteria and others too, including the criticality of the solution or service being built, team size, and the likelihood of changes during the project execution. While these factors are all important, there may be other, more straightforward questions that can act as a quick litmus test.
People Who Use Computers
On a recent webinar about emotional intelligence, I heard knowledge work described as work done by people who work on computers most of their day. At first, I thought it was one of the laziest descriptions of knowledge work I had heard. However, the focus of the webinar was emotional intelligence, not knowledge work or agile, and it was a great shortcut.
Since knowledge workers are subject matter experts that collaborate, share information and solve novel problems, it makes sense that they would use computers these days to facilitate that work. They are dealing with bits (not atoms) and ideas (not concrete or steel). The designs, decisions and collaborations knowledge workers use daily are mostly digital and so can be shared via computer.
[The fact that I had been using an image of someone sitting at a computer to depict knowledge work for the last 20 years (slide 1) but had not made the connection that using a computer for daily work was a test for agile suitability was frankly a little embarrassing. So here is my grand contribution…]
Work-From-Home During COVID as a New Litmus Test for Agile
If a team has been able to work from home during the pandemic, it is probably engaged in knowledge work and could use agile approaches. (Obviously, this WFH litmus test is really just the computer work test rebadged. However, it is current and a potential conversation starter for discussions around adaptive work.)
If you work from home but still follow predictive approaches, I would like to learn why. Is the ability to WFH a viable litmus test? It is nowhere near as cool as “no brown M&Ms,” and I am sure some roles are performed on a computer that best fits a defined, repeatable process without frequent collaboration for direction setting…but I cannot think of them. Please let me know in the comments.