Wednesday, May 1, 2019

Agility Map


Why an Agility Map

Since the creation of the Agile Manifesto in 2001, a large knowledge base on all aspects of Agile has been created. Books, trainings, blog posts, research papers, and many other types of materials are being created by the global Agile community everyday. However, even with this large amount of knowledge at our fingertips, Agile practitioners are often faced with push-back and other challenges.

One of the biggest challenges is helping individuals, especially the leaders of an organization, understand what Agile means to them in the context of their reality. Even though the Agile Manifesto and the 12 principles have been published for 18 years, my experience clearly shows that the word Agile means different things to different people. I also believe people's understanding of Agile deepens as their experience in Agile increases overtime. Because of this fluid nature in the understanding of Agile, the purpose of the question 'What does Agile mean to you?" is no longer about whether the answer to the question is right or wrong. It is about understanding where people are on their own Agile journeys.

To achieve this level of understanding, it is important to have a frame of reference. I pictured a tool that people can use to locate where they are on their Agile journeys and where they need to be next, either as an individual or as an organization. This tool should also show where every decision lands, so that it is clear to the decision makers whether the next decision brings their organization closer to their agility goals or further away from them. So I went ahead and created a tool called Agility Map. It is inspired by the four Agile Quadrants that were introduced to me a few years ago by Lyssa Adkins, Michael Spayd, and Michael Hamman. The Integral Agile Transformation Framework created by Michael Spayd is also very influential in my thinking.1

About the Agility Map



This Agility Map is not intended to be a theory or framework that contains all aspects of Agile. It is simply a tool that provides a frame of reference to Agile practitioners as they navigate through the complexity of Agile transformation efforts. It is not perfect. I hope it will evolve over time with the help of fellow Agile practitioners who want to use it and improve it.



The main structure of the Agility Map is a variation of the Integral Model created by Ken Wilber.2 The left hand side points to the internal-facing aspects of an organization, i.e. internal processes and tools, organizational structures, and culture. The right hand side points to the external-facing aspects, i.e. products and services, customer interactions, business strategies. The upper half of the map points to the aspects that a team or a collection of teams can accomplish. This is where the Agility Map deviates from the  Integral Model slightly. In the context of Agile, I believe the smallest unit is a team. The lower half of the map points to the aspects that impact a whole organization.

The colored circles can be considered as another dimension of the Agility Map. The colors represent the organizational development stages. I adopted a subset of the colors that Fredric Laloux described in his book Reinventing Organizations.3 Amber represents processes and decisions that are based on the top-down command and control management style. In organizations that operate primarily in Amber, conformity is more important that the results. Orange represents processes and decisions that are results and ego driven. In Orange organizations, employees are given some level of flexibility on how to achieve the desired results. Green represents a mindset that is based on empowerment, participation, and collective wisdom. Most Agile thinking and practices are rooted in this stage. Teal represents an emerging organizational paradigm known for its self-organizing and de-centralizing nature.

It is important to point out that some stages are not inherently better than the others. It all depends on the social and economic environment an organization is in.

The 4 quadrants:

Agile Mechanics
This quadrant is the home of all the internal processes, practices, tools, frameworks, and technology stacks. Most of the Waterfall processes gather in the Orange space in this quadrant. Agile practices primarily reside in the Green space. Examples include Agile methodologies such as Scrum and Kanban; scaling frameworks such as SAFe and LeSS; engineering practices such as Test Driven Development, Pair Programming, and decentralized software architecture; DevOps tools and practices such as Jenkins, Infrastructure as Code, Continuous Integration, and Test Automation; Agile work management and communication tools such as Jira, Confluence, and Slack. Basically, this quadrant covers what is often referred to as "Doing Agile".

Product Agility
Product Agility is an organization's ability to delight its customers and generate revenue in a fast changing environment. This is achieved by delivering the right products and services at the right time. This quadrant is the home of all the mindsets, practices, and measurements that enable teams to achieve different levels of Product Agility. Big Bang IT system releases and massive data migrations can be found in the Orange space in this quadrant. Project based practices such as the warranty period after a release are also in the Orange space. Examples of items in the Green space include Value Proposition Canvas, A/B testing, and the true MVP approach to product development.

Organization Agility
Organization Agility is the ability to organize and reorganize the employees in an organization based on shifting business needs and market conditions. Companies with high Organization Agility are able to reorg with minimum negative impact on customer experience, team morale, and overall productivity. Different types of organizational structures occupy different colored spaces in this quadrant. For example, a multi-level hierarchical organizational structure where the rule of following the chain of command is strictly enforced occupies the Amber space; a flat organizational structure with open door policies is in the Green space; if you walked into a company and found it is difficult to find who the leaders are because everybody acts like a leader and a doer at the same time, the organizational structure of this company is probably in the Teal space.

Business Agility
Ken Schwaber, co-creator of Scrum, stated, "Agility is an organization's ability to harness change for its competitive advantage". I believe the agility Ken talks about here is the overall Business Agility of an organization. The items in this quadrant provide purpose to items in the other three quadrants.

This quadrant contains business strategies and business objectives such as positioning in an emerging market, horizontal or vertical growth strategies, and market share targets. If a company is financially sound, and the business strategy for the next 3 years is steadily increasing the market share of existing product offerings, this company is primarily in the Orange space. If a company sets out to have 30% of its revenue coming from new products, its business strategies are more likely to be in the Green space.

The level of Business Agility an organization can achieve depends on the matching conditions in Agile Mechanics, Organization Agility, and Product Agility. If an organization is primarily Orange in the other three quadrants, its chances of achieving Green level Business Agility are low. The Orange items in the other quadrants will keep the Business Agility on the Orange level. Conversely, when an organization has a real need to achieve a higher level of Business Agility, this need pulls its Agile Mechanics, Product Agility and Organization Agility to advance to the next level.

Two Principles

Principle #1: Sustainable agility is achieved by balanced advancements in all four quadrants.

Items in all four quadrants are interdependent. Items on the right hand side of the map, the external-facing aspects, need to be supported by the internal-facing items on the left. Otherwise, they will be castles in the air. Conversely, each internal-facing item on the left needs to find its purpose in the external-facing items on the right. If an improvement item on the left does not have a corresponding item on the right, we should question the value this item delivers before spending time and energy on it. Items in the Organization Agility quadrant provide the foundations for effective Agile practices. Without a sound Agile organizational foundation, Agile practices are top-heavy. This approach is neither effective nor sustainable. Ultimately, all items should point to the Business Agility quadrant, either directly or indirectly.

When I used the Agility Map to exam my previous Agile transformation efforts, it is clear that most of the items are clustered in the Agile Mechanics quadrant. This is an important visual indicator that the Agile Mechanics items are not balanced with items in the other quadrants. I believe this imbalance is the root cause of the challenges we face in many Agile transformation efforts.

Principle #2: Items in the same colored circle synergize well.

One key benefit of using the Agility Map is the ability to visualize the correlations of items in different quadrants by the colored circles they are in. Items in the same colored circle across the four quadrants synergize well together. Items in different color circles may not synergize or may even be incompatible. For example, DevOps practices synergize well with Frequent Releases. Both are in the Green spaces in their own quadrant. DevOps practices do not provide the same level of benefits to Big Bang Releases, which is in the Orange space.

How to Use the Agility Map

Here are some ways Agile practitioners can incorporate the Agility Map in their work.
  • Leverage the Agility Map to help design the State of Agile Assessments.
  • Generate insight by placing agility findings on the map and applying the two principles.
  • Help an organization understand its current state of Agile and identify the next set of goals by visualizing the facts on the Agility Map.
  • Track the Agile journey of an organization: where it was; where it is now; where it needs to be next.

This Agility Map can be used in different organizational context. It can be used at the enterprise level, or in a business unit, or in a department.

The size of each item placed on the Agility Map should reflect its relative sizing, including the effort, risk, or impact of that item.


Here is an example of mapping the 12 Agile principles. The size of each item can vary based on an organization's readiness to act on them.




Here is another simplified example that illustrates how the Agility Map can be used by an Agile coach:


An Agile coach assessed the current state of Agile in an organization. She placed the findings on the Agility Map. She then analyzed the map by applying the two Agility Map principles. Some insight emerges from the data: the Agile practices that are being implemented don't have a Product Agility goal; the component based team structure doesn't synergize well with the Agile practices; it is not clear which Business Agility goals are more important.


Equipped with this insight, the Agile coach collaborated with the people she coaches on identifying where they want to be and how to get there. They started in the Business Agility quadrant and decided that achieving 21% market share is the primary goal. This Business Agility goal needs to be supported by faster product releases. Based on this common understanding, a new goal is identified in the Product Agility quadrant - monthly release cycles. To achieve this Product Agility goal, a few items are identified in the left quadrants. The clearly defined goals on the right hand side provide the purpose and the real measurements of the team's efforts to improve Agile mechanics and organizational agility. That means implementing automated functional testing is not the goal, but a means to get to an end, which is monthly release cycles. So no matter how many automated test scripts are created, the team's job is not done until they achieve monthly release cycles. At the same time, the hypotheses that monthly release cycles will contribute to increasing the market share is being tested.


In this example, the arrows with dotted lines point to the purpose of the improvement items; the arrows with solid lines represent the progression of improvements.



In the spirit of Minimum Viable Product, I'd call this Agility Map version 1.0. I hope it will be improved over time with your help. So your comments, criticisms, and suggestions are not only welcomed but much appreciated.

References:

  1. Integral Agile Transformation Framework - Michael Spayd http://www.trans4mation.coach/trans4mation-approach/
  2. Integral Model - Ken Wilber https://integrallife.com/four-quadrants/
  3. Reinventing Organizations - Fredric Laloux http://www.reinventingorganizations.com/





Friday, November 20, 2015

The Role of the PMO in an Agile Organization


I was recently approached by a PMO director seeking advice on how to make large initiatives more Agile. Apparently, the PMO was trying to improve its effectiveness by adding some Agile elements into the existing process. This seems to be a very logical way to improve project or program management process. The problem is that this approach never really works, because of the fundamental differences between traditional project management and Agile. As Agile Coaches, instead of jumping into the solutions on how to make the improvements, we need to first help the PMO find the answer to the real question, ‘What is the role of a PMO in an Agile organization?’ 

Traditionally, the PMO as an organizational body plays an essential role at the project, program, and portfolio level. The PMO is the hub of communications from top down, bottom up, and across the development teams. It owns the process standardization, tracks project costs and drives project schedules. However, in an Agile environment, there doesn't seem to be a clear definition of what the role of a PMO is. 

I believe the PMO is uniquely positioned to becoming an great Agile coaching center, especially in coaching the organizational leaders. It is a goal that worth striving toward. And here is why. 

The Need on Enterprise Level Agile Coaching 
One pattern in Agile adoption is that it usually works well and shows great results as long as it is isolated from the rest of the company. Usually a few teams working a product that has no or little interdependence to the rest of the enterprise system or product portfolio. Problems arise when the leaders see the results and give the marching order to apply the same practice to the rest of the company. In my opinion, the root cause of Agile scaling failures is the Corporate Immune System. (John Mariotti has a very good article on this topic.) When a large scale Agile transformation takes place in an organization that is not ready, the organization’s immune system fights back. In order to make meaningful progress in the Agile transformation at a large scale, the leaders need to be genuinely supportive of the transformation, especially in difficult times. And that requires more than open minds. It requires the leaders to overcome the fear of letting go things that made them successful in the first place. The truth is, when push comes to shove, people tend to revert back to the old behaviors, including the leaders. To overcome that, a good dose of enterprise level Agile coaching is not just required, but essential. 

The PMO’s Advantage in Enterprise Level Coaching 

  1. The PMO typically interacts with the leadership teams on a regular basis, including business branches, IT, Finance, HR, etc. The PMO has established the communication channels that a typical Agile team doesn’t have.
  2. Holding an unbiased and objective position is a must for successful PMO’s. And that is a tremendously effective position for Enterprise Agile Coaching. 
These two advantages put the PMO at a really good position when it comes to Enterprise Agile Coaching.

Tuesday, May 19, 2015

Starting A Blog

The purpose of this blog is to collect and share my thoughts related to Agile. Thoughts that come up when I'm working with agile teams, reading books, or just random thoughts about life itself.