As we look to the next installment in our series, “The Principles of Disciplined Agile”, I’d like to take a closer look at the principle of “Context Counts”. This is a principle that I’ve found resonates very well with project managers, even more so as they gain experience in the field.

This all starts with the definition of a project. Each project is a unique endeavor. Each desired outcome is a unique deliverable, and each team is uniquely comprised as a result. The uniqueness is also driven by the markets, industries, types of organizations and the regulatory constraints the project is delivered within. All of this results in a unique context – no two projects are ever exactly the same.

Above and beyond uniqueness, and certainly influenced by it, is the varying degree of complexity that exists within the project domain. Complexity can be a difficult project attribute to nail down. That is somewhat due to human nature. I’ve often observed that we tend to oversimplify problems that are quite complex, whereas we also tend to overcomplicate problems that are in reality rather simple. This is because we want to apply the same problem solving processes, whether intentionally or unintentionally, to every problem.

In fact, complexity is driven by several factors, but the most important is brought by the aspects of people. The team that is assigned, bringing with them their associated skills and capabilities (both technically and teaming skills) have the power to make things more or less complex. The people side of the equation is also impacted by team size and the type of organization that the company has adopted.

Of secondary impact is the technology to be employed, the newer the technology the more complex the effort will be. Whether the newness of the technology is in the tools the team is using to deliver, or the product deliverables themselves, this will add to the complexity inherent in the project. In any case, complexity is the key context factor to consider when determining the best approach to deliver the project. This forms the basis for the rationale to have multiple delivery approaches at your disposal, selected within a decision framework along with teams that are well trained to adapt to each uniquely complex project.

How do these context factors play into the choice of project delivery approach? We find there are generally three areas where context should be considered; in the risks the organization and stakeholders are willing to take, in the products or services the organization provides, and in the organizational composition that is in place to deliver those products and services.

Context counts in the risks the organization and stakeholders are willing to take. In the world of project management, risks are simply uncertainties that are collected, tracked and investigated to determine the effect on the project and/or product deliverables. We look at risks as potential opportunities as well as threats and can be found at every level of the project. Like the game “Jenga”, the question that isn’t answered is whether the stack will hold together if a piece is removed.

Because projects are unique, uncertainty abounds. To put this into perspective, I often use the illustration of risk as if we’re driving down a two-lane highway. As we look at oncoming traffic, we see a Fiat, a semi-truck and a Mustang in that order coming towards us. Each one of these vehicles represent a different level of probability that they will cross the center-line of the highway and create a problem that needs to be solved. If we follow the principles of defensive driving, for example, we might conclude the Mustang represents the highest probability and impact combined value since it would not necessarily see the Fiat ahead of the semi-truck as it attempts to pass. Eventually, though, the three vehicles are in the rear-view mirror and are no longer considered, but there are now a new set of vehicles we see oncoming. In this way, risk is ever evolving on our projects, uncertainties are either resolved or become irrelevant, and new uncertainties arise.

Where this plays into context counts is that the key stakeholders on your project may choose the level to which they want to lessen the risks on your project deliverables. Since risks are uncertainties, on my project teams I typically communicate this as questions that require answers at some point, then to lessen the risk we need to become more certain. In other words, find answers to our questions. How fast do they want to travel? Do they want to make sure nothing gets in the way? Or, are they comfortable with finding answers for those uncertainties as they progress? As we like to say at Projects  by Design, when it comes to Agile we “Always know more tomorrow than we do today”.

Taking all risk into account, then, highly influences the degree to which we want to complete upfront planning in the project before we start delivering any of the product. For example, if the rationale of the stakeholders is the answer to those questions is that they want to reduce the uncertainty before they make a significant commitment to resources, the project will be asked to complete a heavy load of upfront planning to do just that. Traditional project delivery approaches are based on this type of context, in fact. The requirements are thoroughly understood before starting any work, which results in a predictive quality to the project. The Project Manager is asked to predict with a high degree of certainty what the project will deliver, when it will deliver and how much it will cost.

All other approaches modify predictability to some degree. Iterative and incremental approaches allow for leaving less understood portions of the project scope for later estimating, while using the delivery of more certain portions of scope to help resolve those uncertainties. On the far end of the spectrum is the adaptive approaches, where Agile falls, that only are predictive about what the team will deliver within a fairly short time frame, usually a two or three week delivery cycle.

It’s important, though, to remember that the approach that is taken due to level of uncertainty you’re willing to live with before committing resources doesn’t necessarily change the complexity of the project. More detailed upfront planning may reveal complexity that wasn’t visible, and deferring planning doesn’t simplify the approach. This is a common misconception about Agile, it doesn’t simplify what you are delivering or the environment in which you’re delivering, it just lets you resolve uncertainty in a different manner.

The value in Disciplined Agile is that the decision framework “bakes in” the level of risk tolerance in the variables used to select the best course of action. Risk tolerance is implicit in the decision points, but it goes one step further. In the framework we ask ourselves questions regarding dependencies, stability of the teams and many other factors that, if left ad hoc, will retain, or even introduce uncertainty into our project delivery. Following the framework will help, then, expose and resolve risks as a natural outcome of the decision making based on the context – which really counts!

Context counts in the products or services the organization provides. Agile emerged from the software development community. As that industry emerged from the onset of large scale application development during the 1980s and 1990s, the evolution of technology provided more options to the customer than was previously available. During those early decades there was a presumption, largely based on the significant investment of resources to build the desired applications from scratch, that there needed to be a very clear set of requirements from the user community and then the associated predictive planning that helped the decision makers to give either a thumbs up or thumbs down on the commitment to resources.

What eventually happened in that model is that every application was custom built for the purpose of those decision makers. Often that meant the users had to accept what was provided, and then support organizations had to figure out how best to make the product work in the long term.

Then, business system integration emerged as a key enabler of creating and realizing value. Organizations scaled in complexity, but the systems were not able to scale at the rate needed to keep up with business demand. Speed to delivery became a market differentiator as a result. Business leaders demanded systems that worked together seamlessly, and they needed it yesterday. To compound the problem, users began to resist the way the applications were built, most often because they, too, were under pressure to gain efficiencies in their business processes. The long and arduous predictive delivery life cycle was tenable no longer.

As the Agile framers first met to lay out the Agile manifesto, they also adapted some practices that had gotten traction in the software delivery world, such as Lean, Rapid Application Delivery (RAD) and Extreme Programming (XP). But it also took on the flavor a resistance to the PMBOK® based project management practices. Many saw this as the PMI® way of doing things was counter to efficient and effective software delivery, notwithstanding the PMBOK® going as far back as 2002 stated that there was no one standard way of delivering projects.

However, Agile, rightfully so, began to demonstrate there is value in the methods and adopting organizations were able to realize speed to market, team collaboration, more tightly integrated customer feedback and regular process improvement benefits that Agile provides. So, the thought was if it works for software development, it can work with anything!

There’s a problem with that way of thinking. There are still some types of product that require a firm set of requirements before build begins. And for which key stakeholders are not willing to commit the resources until they are fairly certain about what they are going to get, when they are going to get it and how much it is going to cost. Consider building a ten story building, given that in Agile we want to let requirements evolve as we deliver, would it make it make sense to have a new requirement that affects the foundation load bearing specifications after the footings are poured? Of course not, the resulting change would require demolition of the previous work, thus adding cost and time.

That’s not to say that there aren’t some Lean practices that can be applied to construction and engineering work. There are several that can be found in the Disciplined Agile framework that have proven to be helpful in those types of projects and are being practiced today. And especially in software delivery, in which we find the roots of Agile, the context based choices abound in the Disciplined Agile framework for projects to employ in all situations, from simple to very complex.

Context counts in the organizational composition. When I retired from the military, there were two difficult transitions in my mindset that I had to make. The first was the lack of clear understanding of who held the power in the organization. In the military it’s quite easy to see, everyone has their rank displayed on their uniform, leaving no doubt on the level of power. The second was the concept that people didn’t always do what was expected. That happens in the military, of course, but certainly not to the degree we see it in a private organization. From both of these considerations I had to learn on the job how to influence without authority in order for the project team to effectively collaborate and deliver quality products and services.

The two organizational compositions that I found myself in were on opposite ends of the spectrum as it relates to hierarchy. The military, of course, is quite hierarchical – communication flows up and down the organization, then is integrated at the decision making level, not at the team level. In the software delivery organization I found myself in as a newly minted Project Manager worked best when communication was integrated at the team level. It was management that was often “the last to hear” about a problem the team was facing.

In Agile the integration of communication at the lowest level possible is reflected in the paired values and principles. Quite specifically in two, individuals and interactions over processes and tools and customer collaboration over contract negotiation. This is why Agile can be highly efficient when deliverables dependencies can be decoupled in order to deliver within the constraints of a two or three week sprint. The team can generate a focus on the deliverables unmatched in any other methodology, as the ease of communication needed to efficiently complete the work is infused in every practice that is generally considered standard for use.

If you have a hierarchical organization, it is likely due to the need to ensure management is more tightly integrated than the teams. This often occurs in organizations that are more highly regulated, as it is management that must ensure compliance to those requirements. Decision making, then, becomes a federated model as opposed to a distributed model.

You may think, then, since my organization is hierarchical is Agile the right way for us to deliver? In Disciplined Agile the answer is yes! That is because the communication needs of the organization are also considered as the team works through the framework choosing their way of working (WoW). In this way, Disciplined Agile allows for additional flexibility and scaling that is not available in the standardized Agile methods (or even in Scaled Agile (SAFe) for that matter).

The principle “Context Counts” is integral with the Disciplined Agile framework and provides for a more realistic and adaptive approach to project delivery that accounts for the uniqueness and differing levels of complexity in every project delivery situation. In that way it’s a natural evolution in the Agile journey that more fully integrates the work and communications at every level of the organization, for all products and services and for any level of risk tolerance.