Suppose, for example, you reach a point in your agile implementation where teams are delivering and executing in a much more productive and efficient way. That begs the question, are they delivering the right things? Now that teams can deliver faster with better quality, how does an organization leverage these newly acquired super-skills? 

The answer is clear: the business and product strategies have to change, too. If teams can deliver faster and more iteratively then we need a product or business strategy that can take advantage of these capabilities. It’s not enough to continuously improve how we deliver. It’s not enough to just keep scaling agile to encompass more and more teams. What we must do is improve our ability to figure out what to deliver next. We need to incorporate feedback, learning, experimentation, and rapid delivery into our business and product strategies—without these all we’ve figured out is a faster, better way to deliver the same old results.

What many organizations have discovered in their adoption of agile is that their organizations are rich in policies and controls that were installed to support a process they no longer use. In order to achieve their organizational agility goals, these organizational policies and processes need to be adapted to match the new agile execution, delivery, and strategy models. For example: If existing release management policies require a 3-month conveyor belt to deploy a completed product but the team can deliver completed product monthly (or even weekly), those release management processes and policies must change in order to take advantage of team’s abilities.

To truly pursue organizational agility, we must tackle and transform emerging constraints— things like signoffs, stage gates, metrics, performance plans, risk management, etc. This goes far beyond team-level problems (or even enterprise agile) to the systemic constraints that stand in the way of true agility.

In his 2009 Blog Post (http://bigv.is/xBNZEe) George Schlitz talks about the need to change these rules.  He states:

“Organizations make rules to operate in the presence of limitations…the rules that were made to operate in the presence of the old limitations must be eliminated or changed, and new rules created to deal with new limitations.”

As organizations improve how they operate they must change their organizational policies to deal with new constraints – not treat the existing policies as constraints themselves.

2012 will be the year that organizations start to turn the corner in their agile adoptions. They will recognize that team- or project-level adoption of Scrum, XP, Kanban, Lean (or some combination of agile processes) is only the first step towards achieving organizational goals. They will realize that organizational policies, process, and often, structures, need to change as well. Some will find the challenge too daunting—But those who figure out how to evolve their organizations; those that make it a priority to effect organizational change in order to meet ever-changing markets; and those that realize a sense of urgency and respond to it will find themselves on the path to true organizational agility.

Works Cited:

1. Schlitz, George. “Agile Removes Limitations…You Must Now Change The Rules.” Web log post. BigVisible Blog. BigVisible Solutions Inc., 10 Nov. 2009. Web. <http://www.bigvisible.com/2009/11/change-the-rules>.

This way of thinking and approach to change may drastically limit the success of your journey to becoming an agile organization.

Some indications that your organization treats change as a temporary state to be controlled, and may need help moving to a more appropriate theory of change for today’s complex environment:

• Establishing a standards board to cull “best practices” from a cherry-picked pilot team and/or from research to then “roll out” a new ["standard" agile] process to other teams (“surely only the pilot team was able to do something effective without a standard!”)
• Preventing teams from improving until someone has determined the “best practices” that they can then implement (e.g. “you can’t introduce that practice until the centralized group has determined the best process™ and best tool™ for everyone to use!”)
• Taking experiences of success from implementing a practice or improvement in one context (organization, project, situation) and dictating their use as standards in others contexts (“<practice x> worked with <SuperPilotTeam>, other teams must use <practice x> too!”)
• Measures of transition success based on “adoption percentages”

A Reality Check for Most Organizations Considering (or in the middle of ) Transitions to Agile, Lean, etc.

If you can relate to this, the ship that is your agile initiative may be sinking.  Over time, the initial excitement generated by the introduction of agile principles may be crushed by your management and organization as they ignore the learning process your teams have gone through, and carve out standards to be applied to everyone.

Basically, you may have the appearance of agile, minus the agile part – the practices without the principle; the motions without the capability.

This is one of several causes of the phenomenon known as CrAgile (“Crappy Agile,” a.k.a. “Scrummerfall,” “Scrum-But,” etc.) – wherein an initial exciting introduction of new ways gradually reverts to old ways.

The Learning Journey

Standards, when used as described above, don’t result in success of complex endeavors like product development efforts.  They result in begrudging compliance and, if you are lucky, successful following of steps as opposed to achievement of outcomes.  From years of coaching, consulting, and being a member of many successful and unsuccessful product development and change efforts, I have realized a few things about learning new ways, such as:

• Each person and team proceeds on its own “learning journey” when trying new things (see diagram). The real learning is in understanding what things work (and don’t) in different situations, reflecting on these experiences to understand why they did or didn’t work, modifying and improving them to work, and continuing to expand their awareness to continuously determine better ways.
• Standards and best practices, used wrongly, are an attempt to short cut this learning process.  Ironically, the short cut only cuts out the “learning” part, and results in blind adherence to practice, and rarely greater capability.

This diagram shows the learning journey of a team.  Over time, the team tries new practices and techniques.  They learn how things work, and how to customize practices and interactions in ways that work for them – in their environment, for their challenges.  The practices alone were not the reason for growing in capability, but rather trying the practices and learning about when and how to apply them.  The common management mistake is to assume that taking the practices that a high-performing team is using, and copying them to other teams, will result in the same improvement.

The Only “Best” Practice – Continuous Learning and Improvement

“There are no best practices, only better practices”

I don’t know where I first heard/read this quote, or who it came from (let me know and I’ll update this page- my searches yield many writings). What I do know is that the pursuit of “best practice” has a number of subtle problems:

1. It implies that once these practices are found, improvement is done. This is consistent with the “unfreeze-change-refreeze” model of change associated with Kurt Lewin in the early 1900′s. This older model of change is often criticized for being too inflexible to deal with the overwhelming amount of change and disruption we face today.
2. It mistakenly assumes that effectiveness of practices is context-independent (i.e. what works well in/for one situation, person, team, group, environment will work as well in other situations, persons, teams, groups, environments). Consider how much can be different about situations, people, teams, groups, and environments and it becomes easy to imagine how a “best” practice in one place may not even be a useful practice in another.
3. It assumes that change is not constant.  More and more articles, books, and experience show that change is constant, and that organizations that will survive in the future must develop the capacity for continuous adaptation.

A Better Use of Standards and Best Practices

Reconsider how best practices are used in your organization.  Learn from lean thinking a different approach to improvement and standards.  

1. Change your focus on standards from that of arriving at “best practice” to constantly finding “better practice”.
2. Shift the purpose of centralized groups from centers of governance to centers of enablement – helping to encourage teams to visit each other to learn about successful approaches
3. Encourage the building of communities of practice wherein people from different teams and group can share experiences and learning.

Lean “Yokotenkai”

In the lean world, the concept of yoko tenkai (which I’ve read is poorly translated as something like “beside/to the side, expansion” – shortened to “yokoten”) is a process of sharing best practices from one part of the organization to others, and (as importantly) improving or expanding them constantly to meet the needs of the new context. There are two aspects of yokoten- both are necessary, and neither is sufficient on its own.

1. The first is the “copying” of best practice to the side. This involves learning about discovered “best practices” from other parts of the organization.  A subtle (but critical) nuance is that these practices are not designed and dictated by some governing body- instead, the process of “copying” involves people sharing learning and observing practices in other groups as they are being used, in context.  It is a sideways proliferation of learned practices across the organization, fueled by observation of these practices where they are working.
2. The second part is “expansion.” Practices are not to be blindly and arbitrarily applied to other parts of the organization.  Instead, the practices are modified and improved to suit the needs of each group and context.  The result is continuous improvement, fueling more sharing.  This results in continuous “better” practices.

When people from one team observe practices in use in another team, they are taking these practices, bringing them to their team, and will more likely customize these to work best on their team and “make it theirs,” with the goal of improvement.  Alternatively, when an authority tells a team to implement a practice, will do what they are told, with the goal of following the practice.

What can you do?

Here are some ways you can get started, today:

• Discuss the role of standards in your organization.  Discuss yokoten and what it means to your group.  Research the Toyota Production System and other lean implementations.
• If you are on a team, try to embody yokoten yourself!
  • reach out to other teams to learn how they’ve been successful
  • bring back learnings to your team and improve/modify them to suit your context
  • share any improvements you make with those who helped you
• If your organization is embarking on a large transformation in pursuit of organizational agility, and seems to be run in a manner similar to that discussed in the beginning of this article, seek expert guidance.

The following things may take a long time to instill in your organization – as they may need cultural change to be truly accepted:

Start shifting the role of centralized groups from designers and declarers of standards to enablers of yokoten

• Ensure teams get the help they need to be successful
• Be aware of learnings in various teams
• Encourage teams to visit other teams that have been successful, and bring back learnings to their teams to improve

Indeed, the challenges that agile organizations have been facing as they embrace team centric work have actually been confronted by numerous organizations prior to Agile. Automobile companies, professional consultancies, oil companies, and even the world bank have encountered this challenge where their technical experts have become ensconced in cross-functional project silos. Looking at how these organizations have addressed this challenge offers us some interesting insights. The successful organizations didn’t try to bolster their functional silos or build standards groups, but rather they embraced a more informal and organic model for sharing knowledge, solving problems and even making strategic investments: communities of practice.

What Makes a Community of Practice?

It can be easy to misconstrue a community of practice with other similar constructs such as functional silos or centers of excellence. When well implemented, communities of practice are meant to be distinct from these other entities, offering them certain advantages. Etienne Wenger identifies communities of practice based on three primary attributes.

Domain

Communities are defined by a common interest that defines the boundaries and interests of community members. The domain indicates precisely what that shared interest is. It may be functional in nature, such as a development or QA community, but it could also be based on other shared interests such as a market, geography or even a specific technology or skill. The domain represents that shared interest in which community members are looking to support each other, build more knowledge and capacity.

Community

Unlike functional silos, communities are informal and social in nature. They are based on the connections that are built and cultivated between community members. As such, membership is optional and people’s level of involvement will vary by person and over time. Within a community, some people may serve as outspoken experts, others may be involved and make regular contributions, and still others may simply quietly consume information. All of these roles are acceptable and individuals may even more from one to another over time. This dynamic nature means that membership is fluid and dynamic. The social structure means that involvement in a community is defined by people’s interest, rather than explicit role or function. This offers a dynamism absent in formal structures as new members can join bringing new energy and people who are less interested can disengage easily.

Practice

Communities of practice differentiate themselves from centers of excellence by being focused on practice. Namely, community members participate in a community as a means of furthering their skills and solving problems. Good communities produce interest and engage people by solving problems. This also provides an elegant way to prioritize and focus the energy of a community, as it is organized around the problems that community members bring to it. This is a critical distinction and success criteria for communities. I have seen numerous communities form based on a top down directive and then try to organize around establishing a body of knowledge or standards that appeared to be valuable to the organization, but were distant from the day to day demands facing community members. Unfortunately, working groups like this frequently run out of energy and disband. In order to be vibrant, community members need to see immediate value from participation in communities.

Why Use Communities of Practice?

So what are the benefits that we get from communities of practice? For people who have existed within cross matrixes organizations, excessive formal hierarchies can become very cumbersome and take time to adjust. A given individual may have interest among more domains than an organization can provide formal structures for. In any organization using cross-functional project teams, each person has at least two: a functional specialty and a project team. Thus, communities of practice allow for informal structures to interweave people into multiple domains without carrying the burden of additional structures. This is not at all unlike the concepts of “meta-scrums” described described in several agile scaling approaches. The focus on practice is also a key advantage, as it balances interest in a domain with practical and tactical benefit. If a community can not deliver value, then members will stop showing up and the community will end. This provides an elegant model for the creation and destruction of communities over time based on where the interest and energy is within an organization and it requires no formal organizational intervention.

I must confess that I didn’t first appreciate the value communities of practice could play in an agile organizational transformation. This was a fortuitous discovery for me when I began working with the PMI Agile Community of Practice and began to learn more about communities of practice in general. Let’s take a quick look at some of the value communities offer and how it aligns with agile organizational transformations.

Functional Specialization vs. Team Focus

Invariably, every organization I have worked with encounters this problem when they charter cross-functional, dedicated project teams. Communities of practice allow for functional specialists to remain in contact with one another, share experiences, coordinate effort, and maintain their own sense of identity. In the case of Chrysler and several other organizations, as project teams reduced the need for functional managers, many of them become more involved as community coordinators, playing a more facilitative role to cultivate and develop vibrant communities of practice around their specialties (Wenger et al, Cultivating Communities of Practice 81).

Building Expertise & Standards

Another chronic challenge that faces agile organizations is how to help grow functional expertise across teams and agree on standards. Communities of practice provide a powerful engine for sharing experiences and learning. The social structure of a community plays a key role in allowing information to spread quickly. The most formal example of this being in Xerox, where repair technicians created habits of socializing with other technicians in order to share stories and experiences. This provided a rich body of informal knowledge that made the technicians significantly more effective at their jobs (Brown & Gray, 1995). In fact, Xerox has since gone on to implement online tools to allow technicians to communicate and share expertise from any geography.

Impediment Resolution

Good agile teams need to be aggressive and methodical about solving problems, and communities provide additional resources to help people do just that. In fact, if you look at the informal nature of communities of practice, and the shared domains they use, this model is ideally suited for creating a sense of ownership of these problems and their solutions by the people doing the work. As removing impediments is a critical role of Scrum Masters and agile coaches, I frequently set up a such a community at clients to help give these people within an organization a common forum to support one another and bring more force to bear in removing obstacles for their teams.

Self Organization

Following concepts from complexity theory, many agile organizations look to move decision making to the lowest responsible level, as those who are closest to the domain are frequently in an excellent place to make informed decisions. But how exactly can you build constructs that allow individual contributes to make strategic decisions like where the organization should invest its finite resources for future products or services? McKinsey offers a powerful example where they actually built service offerings and pursued business based on consultants working within informal communities of practice to build knowledge and capabilities around new services and markets (Wenger et al, Cultivating Communities of Practice 17).

As you can see, the informal, member driven nature of these communities of practice aligns very much with the challenges that organizations embracing agile practices must confront. I hope to write much more about this later, as I’ve already seen some interesting patterns using communities of practice at clients as well as quite a bit of impressive activity with the PMI Agile Community of practice. For now I’ll just have to leave this as an introduction to the concepts. I would love to hear what types of experiences you have had with your own communities and informal structures, whether called communities of practice or not, at organizations using agile practices.

Three Faces of Power

1. Decision Making – The power to make and implement decisions

2. Non-Decision Making – The power to set agendas and therefore limit what is even being discussed

3. Shaping Desires – The power to manipulate what people think they want

Lukes’ work is an extension of Max Weber’s Three Types of Authority, in which Lukes argues that Weber only focused on the first face of power, Decision Making.

Others such as Kenneth Boulding have described these power dynamics as the carrot, the stick and the hug.

Regardless of the names used, by simply being informed about these types of power you can become more aware of your surroundings.

The Engineering Manager ordered the Developer to change his task estimate.

An order from a Manager to a Developer is the most public form of power and is an example of how the Manger wants to be perceived. This first face of power is rather easy to spot and diagnose.

This meeting lead by the Director of Engineering only had task estimation standards on the agenda.

A Director who is controlling the meeting agenda is a bit more subtle and requires a level of awareness to see. What is it that they hope to accomplish by limiting the agenda in such a fashion? Limiting the agenda is a technique used to prevent issues that could cause opposition. Do they address issues if they arise in the meeting or do they misdirect? The second face of power tends to leverage delay, inconclusive questions and bureaucracy to avoid the needs of the weaker team members. Sound familiar?

The CTO convinced his team that accurate task estimates are the key to hitting quarterly goals.

A CTO who has convinced his management team that his interests are in their best interests is far more difficult to identify and diagnose. It isn’t always obvious that the actions of the team are a result of coercion from their boss. They can convince people that their wants and needs are actually harmful to them. This third face of power is often aligned with ideological institutions.

These are just a few examples of the faces of power you may experience every day in a large organization.

I believe that being aware of these faces of power help me become oriented during an organizational transformation. Perhaps you’ll find value in them as well.

We then got talking about Peter Weir’s 1989 movie, Dead Poets Society, starring Robin Williams and Ethan Hawke. In the movie, Robin Williams plays an English teacher who fosters a love of poetry in his students and encourages them to demonstrate freedom of expression and a willingness to go against expected norms. The movie takes an unexpected turn when one of the students commits suicide. The kid wasn’t free to live his own life but was being forced to live up to his father’s expectations and dreams. The father wanted his son to become a doctor and viewed poetry and drama as frivolous activities keeping his son from the real matter at hand — preparing for a future in medicine at Harvard. The son, in frustration shoots himself with his father’s gun.

So, the question is, whose fault was it — the dads for forcing his expectations on and disregarding his son’s feelings, or the teacher’s for introducing the concept that when faced with conformity, it is your responsibility to stand up for what you believe is right and to not blindly do what others tell you is just.

Recently I ran into Joe, a tech lead on a big Agile project I had coached. Joe is easily one of the best senior developers at the company, is enormously respected by the other developers and by the business stakeholders he interacts with. Joe has also done a stellar job on the Agile project and has been crucial in keeping multiple project teams functioning smoothly.  However, Joe got dinged on his just concluded annual review. IT management expressed dismay at Joe’s “lack of communication” and “poor planning.” What was actually meant was that IT management was not happy with Agile, was not happy with the business being part of the team, and was not happy with their inability to get ahead of any bad news and spin the message to the business — Joe’s superiors considered transparency to be a very very bad thing.

In this company, the C-level folks have utterly failed in convincing their subordinates that they truly believe in what they are espousing and have failed to create an environment that values and rewards openness. Thus far, senior IT managers have only paid lip service to changing the existing assessments, metrics, and reward systems that encourage lying and hiding material information. Employees believe that to be successful in this organization you need to keep a low profile, not stick your neck out, and to lie and shift the blame to someone else anytime something goes wrong. Senior IT managers have also failed to create any new experiences that would cause people to question and challenge their existing beliefs. Senior managers take their cue from C-level managers and try to do what they think their bosses actually want. I don’t blame them for simply going through the motions; after all, past experience has taught them that there is no benefit in doing something counter to what your boss expects (irrespective of what he/she says).

So, once again, the question facing me is: is it right for us to coach teams and get them dreaming about possibilities knowing fully well that they are not going to get real support and encouragement from their bosses, who say one thing to their business counterparts but do the exact opposite and have no interest in changing their modus operandi? Is it ethical for us to show people the great things that are possible and then have them penalized for their good work?

Have you faced a similar situation before? What did you do? What do you think is the right thing to do — call people out on their hypocrisy? Part ways with the client because long-lasting meaningful change is not a possibility at this time? Spend even more time on educating management and executives?

Let’s bust those myths!

Myth: Agile Doesn’t Work for Projects in the Highly Regulated Medical Environment.  (The reason usually given is that FDA regulations require detailed requirements prior to project approval; hence, waterfall.  However, in reality, you can develop in phases, with small incremental sets of requirements and the FDA requires only enough documentation to demonstrate your process.)

Truth: Abbott Labs overcame medical device regulation and stringent Class 3 certification and developed the m2000 Real-time PCR Diagnostics System, a human blood analysis tool, with four agile teams.  Compared to the prior methodology in use, this project resulted in a less cumbersome process, fewer defects, a reduction in costs of 43%, and a reduction in cycle time of 25%.

(Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155)

Myth: Agile Doesn’t Work in Government

Truth: The FBI overcame a CMMI level 3, ISO 9001, government-mandated document-driven waterfall life cycle and developed the Domestic Terrorist Database & Data Warehouse with three agile teams.  Compared to the prior methodology in use, this project resulted in significant improvements in release planning, developer satisfaction, and a focus on the true goal: “to catch bad guys.”

(Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100.)

For another example, the U.S. Department of Defense developed the Strategic Knowledge Integration Website utilizing three agile teams.  Compared to the prior methodology in use, this project resulted in improved quality, fewer defects, better teamwork, and a 200% productivity increase.

(Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii,USA, 464-473.))

Myth: Agile Doesn’t Work for Large Products

Myth: Agile Doesn’t Work with Distributed Teams

Truth: Google’s AdWords product busts both of these myths.  With 20 teams and 140 people across 5 different countries, this large agile program was a groundbreaking success at Google and resulted in more predictable releases, higher quality, and an improved ability to accommodate changes, as compared to the prior methodology in use.

(Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201)

Myth: Agile Doesn’t Work in the Regulated Telecom environment

Truth: British Telecom moved their entire IT department to agile, starting with 2000 people from 2004-2007.  This large transformation resulted in an improvement from 10% value stream effectiveness to 55%, created an attitude of delivering real value to the business through IT, and shifted the company’s perception of IT from a service provider to an integral part of the business solutions.

(http://www.agilistapm.com/casestudy-british-telecom/. http://scalingsoftwareagility.files.wordpress.com/2008/06/scrumbt-v14.pdf)

Myth: Agile Doesn’t Work for Client-based projects

Myth: Agile Doesn’t Work for Fixed Price projects

Myth: Agile Doesn’t Work well when integrating a Third Party Product

Truth: I coached an agile team at a prominent consulting company through a project with a client who was a well known record label.  They built a new, fully rebranded, eCommerce website using open source CMS and Search engine, and a third party eCommerce provider.  The site included product bundling, integrated music player, and social networking integration.  It was implemented using Scrum/XP with a single team of about 12 people over 5 months.  The result was an award-nominated site that improved conversion rates dramatically, ultimately profitable for and considered a strong success for both the agency and the client.

Myth: Agile Doesn’t Work for Manufacturing Vehicles

Truth: Wikispeed developed a 4 passenger, 100 mpg, street-legal road car in 3 months using modular, off-the-shelf, carbon-fiber body construction, with no capital investment, and no paid employees.  Agile processes were utilized with a single international team.  The project went beyond the prototype phase and cars are available online.

(http://www.solutionsiq.com/the-agile-ceo/bid/51480/Agile-Innovation-or-How-to-Design-and-Build-a-100-MPG-Road-Car-in-3-Months)

What else ya got?

(note: leads for some of these case studies came from David Rico’s presentation on Lean & Agile Project Management for Large Programs & Projects)

Edgar Schein is a former MIT professor at the Sloan School of Management and author of numerous books on organizational development, the consulting process as well as other subjects. Schein’s work is based on over forty years of consulting experience. He is also generally regarded as the originator of the term ‘organizational culture’.

Schein views the consulting process as essentially a ‘helping’ relationship between the consultant and the client. He gauged each interaction with a client by the degree that the relationship had been helpful and whether or not the client felt helped.

I found Schein’s list of ten tips on creating and maintaining a helpful client relationship to be directly applicable to our work as coaches and essential to helping us create and maintain great relationships with our clients. I have included Schein’s list below along with one additional tip and a bit of personal commentary.

1. Always try to be helpful – Coaches have to know when to help, how to help and learn to see what the client is really asking.
2. Always stay in touch with the current reality – this could be the most important principle because it is really about being mindful. Staying present and aware of what is happening here and now is one of the most fundamental skills that a coach should develop and the key to performing well with all of the other principles listed here.
3. Access your ignorance – asking ourselves what we really know vs. what we think we know is an important exercise for coaches and one that can help keep us grounded and in touch with what is happening now. In other words, question your assumptions.
4. Everything you do is an intervention
5. It is the client who owns the problem and the solution
6. Go with the flow – if you remember principles one through three you should have not trouble with this one
7. Timing is crucial –Finding the proper moment to bring up a sensitive subject is crucial to building and maintaining a helpful relationship with your client.
8. Be constructively opportunistic with confrontational interventions – there are times when clients are more likely to respond to intervention. Be patient and wait for the right time. Any questions see principles two and seven.
9. Everything is a source of data; errors are inevitable – as Schein says, we all make mistakes. We, as coaches, have to accept the fact that we make mistakes and do what we tell our clients to do – learn from them.
10.  When in doubt share the problem – this one is about coaches helping each other, which is something that we do continuously at Big Visible.

I really like this list and find it helpful to refer back to it occasionally. However, I would like to add one of my own…

11) Set expectations up-front and adjust as necessary – your personal preferences and coaching style and that of your client’s will contribute to the specifics of this conversation, but suffice it to say that open, authentic, conversation about expectations is essential at startup and throughout the process.

Everyone Wants to be “Agile”

First, let’s agree on a definition. When talking about an agile enterprise or organization, we mean an entity that is capable of quickly sensing changes in an environment and responding to them so that it may continue to thrive. Agility, in this sense, isn’t so much the use of specific practices like Scrum, kanban, or XP, but rather the properties that they – hopefully – create for an organization. Let’s further consider Agile practices to be  our organization’s ability to respond to change. As a measure of an organizations capabilities, we can refute the claim that some industries can’t be Agile. While an online retailer can be faster than a bank, they are not in direct competition. The goal is simply to be more agile than your competition rather than achieving some absolute measure of agility. From this perspective, all organizations want to be agile. They want to be able to respond to stimuli telling them to exploit new opportunities or respond to new threats. The question really is: how agile is your organization and how does that impact your organization’s ability to execute?

How Do You Measure Agility?

If we remain focused on Agility as being manifest in the capabilities of an organization, we can consider the Agile spectrum based on the level that an organization’s ability to respond impacts its overall execution. In this model, there is a simple spectrum with three distinct points worth considering.

Capabilities as a Liability

Beginning on the left are organizations that suffer from poor capabilities being a liability towards their execution. Fundamentally, this is when an organization must change it’s approach, compromise what it wants to do, or in other ways pursue sub-optimal strategies due to serious limitations in its ability to be responsively execute. This could be the organization trying for the “single, perfect” implementation of a project, because they lack the ability to do multiple releases or work iteratively. The situation that always comes to mind for me is the stakeholder that rarely gets the opportunity to be a part of a development project, and they see this next project as their only hope to get everything they ever want, thus they begin to ask for an inordinate number of features as they never know when they will get another chance. In an idea world, would they ask for stuff they think they may possibly need two year from now? No, but considering the apparent limitations of their current delivery model, they are asking now, because they have no faith that, should they actually need those features two years from now, the organization would be able to deliver them at that point in a timely manner. Organizations in this area frequently suffer from a lack of trust. Another common example would be business units expressing their requirements as solutions – ones they believe will make the delivery easier – without actually engaging with technology about the real problem they want to solve. Ironically, this anti-pattern frequently undermines the project. The technology team doesn’t see the real objectives and is simply trying to build a solution as conceived by the business, however impractical that solution may be.

Balanced Capabilities

In the second position along the spectrum, the organization has achieved a level of agility in its delivery such that it can consistently deliver what the business requests as they request it. While this position is in the middle of our spectrum, it is a major achievement and represents one of the major benefits of an agile transformation: namely the ability to align an organization’s operational capabilities with the goals and strategy of the organization. When talking about the value proposition of Agile, most people point to tactical improvements such as improved quality or time to market. These tactical improvements are not useful unless they are in the service of a business strategy. So if the first position represents an organization whose capabilities are so lacking that they undermine an organization’s strategy, the second position represents one of balance where the organization is capable of consistently delivering the tactical objectives of the organization. In our last example, we talked about the business conceiving of their own solutions that they believed would make delivery easy. In this case, business and technology would have a healthy enough relationship to discuss real objectives and jointly figure out the best solution.

Capabilities as an Asset

While the balanced position may seem to be an ideal, it still suffers from the systems anti-pattern known as “Garbage In, Garbage Out“. Namely, if an organization is able to deliver upon tactical objectives, but those objectives are poorly conceived, the organization will still fail. In good organizations, fast enough feedback may offer businesses with the opportunity to learn from their failures. In great organizations, the very operational capabilities are such that the organization learns by doing. Their ability to get rapid and constant feedback on many levels allows the organization to learn, improve, and ultimately produce a better strategy than what they originally conceived. If the balanced position is where the organization has sufficient capability to implement its desired work, this position represents an operational capability such that the delivery part of the organization is not only able to deliver the work, but learn and implement solutions that better serve the higher purposes and long term goals of the organization than what people initially imagined.

Agile projects are fundamentally learning endeavors, and this position represents the ideal point where empirical feedback is used to improve not only operational capabilities, but also the strategic plans of the organization. A truly agile organization is not only able to build things right, but capable to learn and adapt in order to build the right thing. Going back to our earlier example of business sharing requirements with technology, in this domain, not only would the business share their objectives with technology to figure out the best solution, but the technology group may implement incremental solutions and other demonstrations to help validate assumptions and improve everyone’s understanding of how best to solve the problem so that the final solution they implement is significantly better than either group could have conceived at the beginning of the project.

Beyond A Spectrum and Towards a Map

Before going further, I must confess an apprehension. Until sitting down to think about this blog I would have described agility as a spectrum implying a single dimension as the last diagram outlined. The more I think about this, the more I can’t help but see that successfully responding to changes in an environment actual requires two distinct capabilities: the ability to detect that change and the ability for the organization to respond.  Considering that my last blog post just looked at the role of a product owner along two dimensions and mapped out different points, I’m feeling like I have only one trick that I am continuing to use, but I can’t help but escape that these two dimensions must be looked at individually. I promise to my readers that my next few posts will steer clear of charting a problem along two dimensions and thank you for your patience. With that out of the way, let’s dig a little deeper into this and turn our spectrum into a map. At first we said that organizations have this simple measure of agility, but let’s tease apart ability to change from ability to sense.

Ability to Change

This is probably the more obvious of the two capabilities, and it really is a measure of how quickly, once we have decided to do something, can we go about executing it. Lean processes offer the powerful measure “concept to cash“, which represents how long it takes an organization to get from the point it has an idea to the point it can be capitalized. It implies not only overall speed for delivering large things, but also an ability to change directions mid course in case circumstances change. This measure is more rooted in the operations of an organization as it really looks at the entity’s capacity for accelerating and overcoming its own inertia once a new direction is set. The most common model I see is for organizations to implement some level of work in process limits – either by establishing Scrum-like time boxes for delivery or using a lean-centric general WIP limit – to provide better visibility into the delivery process, force prioritization, and increase cycle time of delivery. By focusing on minimizing inventory – generally in the form of work in process – and focusing on high technical quality , we retain the ability to change and take advantage of new learning.

Ability to Sense

If the ability to change measures an organization’s capability for adjusting what it is working on quickly based on feedback, then the ability to sense is the organizations capability to rapidly get that feedback. It represents an organization’s capacity for identifying new trends, getting feedback on what it’s doing and in general sensing changes within its overall domain. This feedback can be gained from a number of agile practices including going to market rapidly, extensive customer engagement in the development process, and front-loading risk early in an iterative development process.

Mapping Along Both Dimensions

Using these two dimensions, we find five areas that represent different sets of emergent behavior for an organization based on how well it can respond to change and how well it can sense what’s going on. This diagram over simplifies as it visually seems to indicate that there are only five points where a given organization can exist. My experience certainly indicates that this is still on a scale, where an organization may have caring degrees of capacity in sensing and responding and that it is not a binary switch. However, for our purposes, these areas offer a way to look at distinct characteristics of each area.

In this model we see the original three points we’ve already discussed: capabilities as an asset, balanced capabilities, and capabilities as a liability. The characteristics of these points would remain the same, but by extending into two dimensions we see that an organization must balance both abilities or fall into a place of imbalance where they may have capacity in one dimension but lack it in the other. These imbalances can lead to common anti-patterns.

Chaotic

A common challenge we see with many organizations is that they first perceive agile as being exclusively in the domain of operations, or even just development. This may be because agile was sold as a silver bullet, it may be because change is threatening so many people are quick to try and label it merely as tactical improvements in the delivery of software. They present agile as merely working in small cycles and improving through put. Organizations with this mindset very well may experience some success, improving their ability to deliver. However, if they don’t grow their definition of agile, engage their business and other organizational leaders, they risk moving into the top left area, which I’ve simply dubbed “chaos”. In this realm, the organization is able to move swiftly, but it does not have high quality channels for feedback to direct that activity. Teams may find themselves jumping from item to item based on whims or other apparently arbitrary reasons. In such an environment, an organization’s ability to deliver is undermined by the fact that they are unable to get feedback and validate assumptions quickly. Thus, even if they can rapidly iterate, they may find that the iterative nature of their work is entirely encapsulated in a more traditional release process. Some organizations may invest in their technical development to the point where they can build new features every two weeks, but this benefit is seriously limited by the fact that they are unable to get meaningful feedback on these features prior to being launched, and launches are quite infrequent. Thus, the organization may tactically operate in an Agile way, but they are unable to really take advantage of those abilities. If they are adapting and moving quickly it is merely to the whims of powerful stakeholders or to address fire drills that are most likely not truly valuable. Hopefully, champions of this process will then advocate and educate their business partners about the benefit of agile projects so that they can jointly invest in increased ability to sense and get feedback.

Confined

The confined organization faces a similar challenge to the chaotic one, but from a different direction. Rather than being unable to get feedback quickly, this organization can not reduce the cost of change to the point where they can implement changes at the rate that they are learning. They find themselves in this area when they start in the lower left area lacking both an ability to get feedback and an ability to change. They invest in a practice like Scrum and begin to put working product in front of internal users, stakeholders and maybe even customers. Ideas begin to flow incredibly fast and the team becomes lost in a never ending backlog that overwhelms their ability to deliver work. Or they learn important things about the system, but lack the technical capability to do anything about it. In either case, they now face a situation where they are able to get new ideas and better understanding of the problem domain, but unable to properly exploit it. Frequently this happens if organizations begin to embrace agile practices, but are not quite so aggressive in removing impediments and improving engineering practices. As the old saying goes, knowing but not doing is no better than not knowing. In this situation, hopefully organizations see the case for investing in their ability to change such that they have the technical capability to match their every changing list of requirements.

Implications of this Model

The single most important implication of this model – for better and worse – is the very transitional nature of an organization’s position on the map. The chaotic and confined positions offer prime examples of an inherently unstable position. They expose a major gap in an organizations capabilities and cause problems. In the optimistic situation, this apparent gap is correct and the organization continues to move to the top right part of the map. However, it’s quite possible that the organization decides the best way to deal with the uncomfortable exposure of their shortcomings is to simply stop doing whatever it is that’s exposing those shortcomings.

Additionally, if we consider this map a broad landscape upon which organizations may spend years moving, than we appreciate that the journey is profoundly important and it is not simply defining an ideal state to achieve. In fact, the changing nature of the marketplace as well as most companies indicates that even if you occupied the top right position a decade ago, the standard has changed. That which was once state of the art very well may no longer be so. Thus, the most important thing is continuing to move in the direction of increased capability to sense and respond. Right now several luminaries within the agile software development field are having a big discussion about two lean concepts: kanban and one-piece flow. The discussion brings up many good points in arguing the superiority of one-piece flow over kaban – indeed, the Toyota philosophy is to flow if possible, then pull (kanban) and only push as a last resort. However, the more important thing is the continued path towards improvement. A team embracing Kanban practices very well may be improving from their current state without getting into a discussion of whether or not this is the ideal longer term end state. Indeed most of the research on change management and learning shows that moving too quickly towards some perfect goal may very well undermine the change if it is too ambitious in the short term. Going back to the beginning of this article, the goal isn’t some absolute measure of agility, but rather one’s organization’s ability to continue to improve those capabilities such that it can out maneuver its competition.

I hope you find this model useful in conceptualizing that task and communicating it to others, and would welcome other’s perspectives.

Join BigVisible’s Brian Bozzuto and AccuRev’s Chris Lucca on Thursday, November 17th from 1:00-2:00pm for a free lunchtime webinar on Incorporating Agile Methods: Top Traps for Development Teams to Avoid.

In this session, BigVisible’s Brian Bozzuto and AccuRev’s Chris Lucca will explore several dimensions of moving to agile practices and how they can magnify the benefits possible with agile or ultimately undermine the agile adoption –depending on how they are managed.

Specifically, this webinar will explore:

• Common hurdles a team adopting agile may experience
• Team training needs to consider, including agile certifications like Certified ScrumMaster and Certified Scrum Product Owner
• Criteria for evaluating or selecting agile development tools to enable agile methods
• How Agile impacts a broader scope, such as compensation, evaluations, finance, and sales

Reserve your space today!