Agile approaches "Crossed the Chasm" a decade ago. The organizations we see adopting it today are in the "Late Majority" and "Laggard" categories of Geoffrey Moore's Technology Adoption Life Cycle.

As companies adopt agile because they have to / it's now expected / the industry norm / required to stay competitive / <insert your own reason>, we see more push-back and failures than ever.

Doing something because you have to, rather than because you want to, leads to shortcuts and the wrong mindset. The image below, from Ahmed Sidky, shows agile as a mindset.

In the image above, agile is a mindset described by four values, defined by twelve principles and manifested through an unlimited number of practices.

The correct way to learn agile is to start on the left of this image and learn about the four agile values in the mindset. Then learn about the twelve principles that define agile. Once you understand those, you will see all the agile practices are just implementing agile principles and values in various scenarios to solve different problems. This is the correct, Left-to-Right agile adoption.

Unfortunately, many organizations reluctantly adopting agile are impatient. Mindsets and values sound like unnecessary fluff. "We are serious engineers and don't have time for that kumbaya nonsense. Our people are smart, just show us the practices, and we will figure out the rest." So they start on the right-hand side, and adopt a set of agile practices, not appreciating the values and principles necessary for them to work.

Some practices work; others do not. They struggle to get whole-hearted buy-in and see only patchy pockets of success. Some teams continue trying agile; others revert back to how they were. They become an "Agile? Yeah, we tried that, but it did not work well here" shop. They experienced the right-to-left copying of practices without understanding the mindset, values or principles.

Incorrect Right-to-Left adoptions of agile (or anything) fail because they copy behavior without understanding the supporting structures. The practices we see agile teams undertake are just the visible components of a much larger ecosystem. This is known as the Agile Iceberg.

Supporting the visible practices above the water line is a larger, more significant commitment to the mindset, values and principles below the water line. Without investment in the below-the-waterline components, any attempts to copy and duplicate agile practices will sink and be dropped from practice.

Cargo Cults

Another analogy used to depict right-to-left attempts to cut and paste agile is the Cargo-cult. "Cargo cults" is the term used to explain the phenomenon of blindly replicating outward behavior, hoping that it will yield positive results. It originates from a few scattered instances of Pacific Island tribes recreating replicas of the wartime aircraft runways, control towers, and radios out of wood on remote islands, believing that they would bring back the cargo planes that brought Western goods during the war.

The islanders did not know how control towers or radios worked; they just copied what they had seen, hoping it would bring the benefits they had also seen. Implementing sprints, demos, and daily stand-up meetings without valuing individuals and interactions over processes and tools is just as ineffective as an all-wood radio. All it achieves is to frustrate people and give agile a bad name.

The Solution

Like anything worth achieving, the solution requires some thought and hard work. We need to work one-on-one with people and provide maps, not pamphlets, of how agile works so people can make their own informed decisions at the junctions on the pathway to value delivery.

This may sound like a lot of work, but it saves time and reduces workload in the long run.

Making Sense of Agile

There are thousands of agile practices documented in books, blogs and presented at agile conferences every year and likely many times more that never get reported. We do not need to learn them all; because once we understand a core set, we will see the themes, grasp the goals, and help teams create their own tailored ways of working that support the agile mindset.

Let's review some popular techniques often seen on Scrum teams.

Daily Stand-up meetings – These are the quick, inter-team coordination meets held daily where team members share with their colleagues:

• What they have been working on (or completed),
• What they plan to work on next,
• If any issues or blockers are hampering their progress.

Agile Concepts:

• The team owns the work – team members report to each other, not the Scrum Master or some project manager authority role
• Transparency – openly share information, good and bad, so people stay informed and can make better decisions

Sprint Demo – At the end of every sprint (usually one or two weeks long), the team demonstrates what has been built to the business and confirms what to work on next.

Agile Concepts:

• Frequent delivery – Deliver working software frequently. Working software is the primary indicator of progress.
• The team owns the work – It is the team that demos the work, not the Scrum Master or Product Owner. This demonstrates and builds ownership of the evolving solution.
• Focus on business value – Since the backlog is prioritized by business value, the team should be demonstrating the highest business value work items completed. Also, the discussions on what to work on next also focuses work by business value.
• Transparency – Openly share information, good and bad, so people stay informed and can make better decisions.

Product Backlog – The ordered list of work for the project/product. Prioritized by the Product Owner based on business value. Creates a single queue of work items to focus on.

Agile Concepts:

• Focus on business value – The product backlog is prioritized by the product owner, usually a business representative, not the Scrum Master or other team member, to ensure the project focuses on business value.
• Transparency – By putting all work items in a single, highly visible queue, everyone can see the full scope of work to be accomplished. This (hopefully) eliminates side-agreements or under-the-table agenda items being worked on. Also, since change requests are prioritized in the backlog, they bring visibility to these elements and likely completion dates.

Release Planning – The process of the product owner and development team collectively meeting to discuss, prioritize and estimate features for the next release. By engaging the do-ers of the work in the planning process, we simultaneously: 1) get better insights into technical work involved, 2) generate better buy-in for the estimates created and a stronger commitment to meet them.

Agile Concepts:

• Focus on business value – The business (through the product owner role) drives the planning process.
• Transparency – Features and stories from the product backlog are refined and estimated to create a release roadmap that illustrates target dates for key components of the product or service being developed.

Sprint Planning – This is the planning process one level below release planning. The product owner and development team collectively meet to discuss, prioritize, and estimate the next one or two weeks' worth of development.

Agile Concepts:

• Focus on business value – Work is prioritized by the product owner.
• Engage the team in decision making – The team makes local decisions about how best to undertake the work, how to self-organize, and in what order to undertake technical tasks.
• Transparency – All estimates and progress are discussed openly within the project team. Details about progress, issues, or setbacks are discussed daily at the daily stand-up meeting.

Retrospective – A workshop held at the end of each sprint/iteration to review progress, process and people aspects of the project. These regular inspect, review and adapt sessions typically result in suggestions of things to try differently in the next sprint/iteration. By conducting frequent, short-scale experiments, teams can inspect, adapt and improve rapidly throughout delivery.

Agile Concepts:

• Inspect and adapt – At regular intervals, the team reflects on becoming more effective, then tunes and adjusts its behavior accordingly.
• Engage the team in decision making - The best architectures, requirements, and designs emerge from self-organizing teams. Continuous attention to technical excellence and good design enhances agility.
• Transparency – Be open to talking about issues and ways to improve. Acknowledge there are constantly ways to get better. Recognize and thank teams for looking to improve their delivery capabilities.

Kanban/Task Boards – These are large publicly accessible displays of work done, in-process, and waiting to start. Kanban boards make the team's work visible.

Agile Concepts:

• Transparency – It shows what is being worked on, what has been completed and what is coming next. This information is not the domain of just the project manager, everyone benefits from knowing about it.
• Engage the team in decision making – By sharing the project plan visibly, team members can better alert us to potential problems and solutions.

Seeing the Agile Matrix

In the sci-fi movie "The Matrix", the hero, Neo, develops the ability to "see the code of the Matrix." This is the computer simulation he is living inside. Once he sees this, he understands how things work and can move faster and is more powerful than ever before. It is an "a-ha" moment; now things make sense, and he can see his world's structure and patterns and manipulate them.

It is the same with developing an agile mindset. Once you realize agile is based on a few core concepts, you see them repeated everywhere. These concepts include:

• Focus on delivering value
• Build incrementally
• Gather early feedback
• Inspect, adapt and learn as you go
• Let the team decide as much as possible
• Be transparent and show progress, good and bad

With these ideas in mind, practices such as estimating via planning poker make more sense. We are engaging the team in defining their estimates. We are using a visual, transparent process. It is iterative and incremental. There is inspection and the ability to adapt the estimates if outliers are found.

Everything agile teams do reflects these values. Information radiators are about being transparent and visual. Voting on decisions is about letting the team decide. We do not need to learn every agile practice because we will quickly be able to understand any of them once we recognize the agile mindset, values, and principles.

When making decisions, we can apply these agile concepts. Engage the team, be transparent, focus on value, get early feedback, etc. These are not complex concepts to grasp and are what many of us intuitively try to do anyway. That's why agile, for many people, feels like common sense.

However, it can be quite different from traditional project management's analytical world, which aims to specify everything up front before executing a detailed project plan. It is a mindset shift for some people, but one worth making if your work is complex, uncertain, and frequently changing. Here a Left to Right adoption of the agile mindset, values, and principles is the way to go.

<This article is an excerpt from PM Illustrated: A Visual Learners Guide to Project Management. If you are a visual learner who likes clear explanations, check out PM Illustrated here.>