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?

• Leadership is crucial for defining a shared vision and generating buy-in from employees.
• C-level managers are responsible for creating a learning organization that values systems thinking, craftsmanship, and team learning.
• C-level managers must design an organization whose structure, processes, metrics, rewards, and talent align with the organization’s mission.
• Managers are responsible for creating a well-trained, well-organized, well-managed company. If people require constant supervision then management has failed to do its job.

Last year, the new CEO at a client decided to leapfrog existing competitors by creating an innovative product; a product that would attract customers and cause competitors to play catch-up. A team that included the best developers, in the company, was hand-picked; the business was told that cost was not a concern; and the group was secluded from the day-to-day madness and allowed to focus on getting the job done. Despite this the program was a failure and ultimately the task of innovation was “outsourced.” What happened?

A number of major shortcomings inherent in the existing culture doomed the endeavor from the start; these shortcomings were very visible to outsiders but not to long-term employees. Not all organizations face all of these shortcomings — based on my experience, these are more prevalent in larger organizations.

• C-level managers not creating a learning organization
• Lack of a compelling vision
• Lack of prioritization and understanding of what is truly valuable
• Org structures and policies that stifle collaboration and communication of ideas, information, and feelings
• Reward/merit system that punishes innovation and risk taking
• Overly focusing on utilization
• Perception that senior management does not walk their talk

C-level managers not creating a learning organization

A belief that there is one right way and one right answer coupled with the allure of doing it right the first time makes it hazardous for employees to experiment, learn from mistakes, and to try novel approaches. Most command-and-control cultures penalize mistakes and those who have the temerity to try something new quickly learn that it is wiser to dutifully follow every rule and guideline — it’s safer to claim that any failure was due to a shortcoming in the process.

Over time, existent unwanted company behaviors, norms, and values supress any creative desire and motivation that employees may harbor about building a culture that encourages inquiry and trust. The job becomes a 9-5 grind and people stop offering ideas for improvement.

Lack of a compelling vision

Executives sometimes think that what ought to be done will get done without them getting personally involved. They tell what they want but fail to explain how to achieve what they want and why the want is even important. People lower in the organization hierachy are left to wonder, “Why should I/we ___?”

A non-existent vision or one that doesn’t align with what employees value and is imposed top-down guarantees lack of buy-in. As Patrick Lencioni so succinctly stated, “Trust and ability to speak freely are the building blocks for eventual results.”

Lack of prioritization and understanding of what is truly valuable

Some companies lose their ability to probe, sense, and respond to market conditions. They inadvertently fail (or purposely ignore) to ask existing and potential customers what they want and what they are willing to actually purchase. Assumptions are made by marketing heads or business owners based on their beliefs, prejudices, and opinions. These unvalidated assumptions often prove to be untrue and result in products being developed that no one wants to buy.

The problem is exacerbated when teams are not provided proper guidance on what is truly important. If everything is deemed a high priority (happens in cultures where IT is unable to say “No” to any business customer) then people end up multitasking, which leads to a loss of focus, more defects, delays, and no time for learning and self-improvement.

Org structures and policies that stifle collaboration and communication of ideas, information, and feelings

A command-and-control culture combined with a fractured (silo) organization causes an “us” versus “them” mentality to take root. Looking good, hiding bad news, shifting blame, and painting an overly rosy picture soon follow. A greater need for written communication (used for CYA) further dampens progress. When silos are present you often hear statements like, “that’s not my job” or ” I don’t care about the rest, I did my part.” Eventually we also lose the concept of teams and end up with a group of individuals working on a project. We also lose any understanding of a system-wide value chain. Incentive systems that reward local optimization worsen the situation by encouraging groups to make locally optimized self-serving decisions that negatively affect the whole. (See the Robbers Cave Experiment for how easy it is for such a mentality to spring up.)

Reward/merit system that punishes innovation and risk taking

When being right, making no mistakes, and doing what you are told is valued, people stop trying new approaches. They stop taking risks when their annual merit increases and bonuses are tied to metrics (often vanity ones) that aren’t aligned with the company’s goals. When meeting project time, scope, and budget constraints is how people are evaluated and compensated then it is not surprising to see them disregarding the concept of providing value; its more common to see fudged reports and gamed metrics. (Also see Jim Highsmith’s article, “Can-do Thinking Makes Risk Management Impossible.”)

Managers who don’t understand the difference between common and special causes only create additional rules and policies that further burden teams. Most managers also don’t understand that artificial targets and incentives don’t help if the process itself has problems. (For additional information search for Dr. Deming’s red bead game on YouTube.)

Overly focusing on utilization

An unhealthy stress on maintaining high utilization leaves no time for learning, thinking, improving. Departments want to show that they are very conscientious in how they spend scarce dollars; pushing employees to book all their time to specific projects helps show that employees are valuable and busy. Batching large chunks of work and getting people to be as efficient as possible at each step defeats the goal of making work flow so as to provide value to customers early and often.

Utilization goals of close to 100% are counter-productive as they encourage multitasking and creation of busy work, cause employee burnout, increase defect rates, slow down throughput, increase focus on activities instead of on outcomes, and leave no time for self-improvement. Without time to learn new technologies and keep with with new trends employees cannot be expected to come up with creative ways of getting things done.

Perception that senior management does not walk their talk

People quickly see through any political maneuvering or chicanery that senior managers might employ in order to look good. They lose faith and respect for managers who are more interested in playing the political game and not in doing what is right for the company or for the team. Such managers lose moral authority and have to resort to organizational power to get anything done. At best they get compliance; not the passion and creativity that an engaged employee brings to the table.

Other managers talk a great game but fall short on execution. Ultimately, actions speak louder than words and when there is a disconnect between what is said and what is done, people begin to disregard the spoken word. If managers and executives really believe in something, they should take every opportunity to demonstrate its importance. When employees don’t see the passion and don’t hear the message communicated over-and-over again they rightly assume that the new thing is just another passing fad. It isn’t the emloyees’ fault that they don’t belive; it is management’s responsibility to create new experiences that permit employees to question their existing beliefs and to try new actions in the hope of getting better results.

In conclusion

So, why did this company fail to innovate? The group had shortlisted 8 possible things they could work on but they dithered for months about which of these to work on first. They failed to quickly validate their assumptions on whether the market really wanted any of the things being proposed. The group continued to rely on tried-and-true methods and constantly referred to what had worked in the past; they failed to realize that new approaches to development were called for. They lacked managers unfraid of making decisions that were not guaranteed to succeed. They lacked executives who could provide the group with a clear direction or a challenging vision. A political struggle between the CEO and CFO worsened the situation and neither wanted to compromise on his agenda.

This company had over the years deemphasized systems thinking, personal mastery, shared vision, and team learning. Was it then any surprise that their ability to innovate had withered and disappeared? Losing the innovative edge makes it harder to keep up with faster nimbler competitors who aren’t resting on their laurels and are actively looking for ways to leave you in the dust. Ultimately, being nimble and agile is not a choice — it’s a necessity for survival and growth.

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)

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.

“Hey, man! One week down, two weeks behind…” -Kirk Lazarous, Tropic Thunder (2008)

While not a terribly serious movie, I have always enjoyed this quote from the comedy movie about the ill fated making of a war movie. The concept of being only one week into a project, and yet somehow already two weeks behind seems so absurd as to be impossible, and yet it has been the reality for a lot of projects encountered. Invariably, ambitions around projects can get so high, with so many stakeholders that our definition of success rapidly becomes so great we watch the possibility of completing our project recede into the horizon. Properly defining and then managing project success is a critical activity in any project. There are a number of excellent resources I’ve drawn upon over the years to do this. This blog post is more a compilation of my thinking on this topic threading through some of these techniques.

The Iron Triangle of Project Management

Fig 1 - The Triple Constraint

The first concept I encountered on this topic was introduced to me as a project manager. I was told to manage the triple constraint of scope, schedule, and budget. The concept is simple and quite effective. On any given project, there are fundamentally three constraints, the amount of work you’re going to deliver, the amount of money you’re willing to spend, and how long the project can run. As the name implies, these are constraints imposed upon a project, “you must finish by 12/31/12″ that will be used to determine if a project was successful or not. As the triangle image demonstrates, you can constrain on up to two dimensions, but not all three. Thus, you could engage with a project sponsor in an earnest discussion about where you would put the prioritizing focus for a given project. Let’s look at some examples to better illustrate this point.

Fig 2 - Triple Constraint Examples

The first example is a pretty straightforward single constraint where the delivery of a set number of features is most important, while schedule & budget being less important. My favorite example of this would be Blizzard entertainment, who explicitly refuses to announce release dates in advance for their games, rather insisting they build them properly and that it’s “done when it’s done“. The next example we see is a double constraint. In this case, we are prioritizing one of the two constraints over the other. A colleague working with an entertainment company offered a great example for a project like this. He had a specific team (fixed budget) and was building a new application for an upcoming sporting event. Thus, if they didn’t release by a given date, the application was worthless. In this case, the scope of what they release was actually the least important thing. Lastly we come to one of the failure models for this approach, which I would call the cop out. In this case, the sponsor basically puts the focus exactly in the middle, saying that everything is important. As you can imagine, this does not set up a project for success, as we have no flexibility along any dimensions.

From a project management point of view, I can see the value of this tool. However it leaves many questions unanswered. How important is it that we build something which is reusable and can be built upon in the future? How important is it that we invest in the team? Are there specific ROI figures that are required for this project to be viable? These are all left unanswered by such a tool. These limitations were clearly articulated when I managed to deliver a project on time, on budget, and to scope but it delivered zero business value.

Success Sliders

Rob Thomsett introduced the concept of Success Sliders as a means of exploring more than just three dimensions when considering the success of a project. This technique offer the ability to break apart that ambiguous concept called “scope”, or prioritize other dimensions like quality and team experience. Indeed, you can use this type of model to prioritize along a virtually infinite number of criteria.

Fig 3 - Success Sliders with a force ranking

Figure 4 - Score based Success Sliders

There are two common implementations I’ve seen of this technique. The first, demonstrated in Figure 3, is a force ranking. In this example, a number of stakeholders each individually had to force rank the priority of a number of different criteria such as “realize ROI”, “High Quality”, and “Deliver Project on Time”. Each individual stakeholder’s values are represented with a different color. The precise list may vary from project to project. In fact, eliciting and elaborating specific criteria can be an art in its own right. This example shows how different stakeholders show their perspective of priorities so that discrepancies can be discussed and reconciled before a project falls into duress. The ultimate goal is a single prioritization, as demonstrated in Figure 4. This is a screen shot from a tool made available by Mike Cohn on his website. This example is different in two counts. First, it represents a single set of agreed upon values. Second, it is not force ranked, but rather a budget. You can only increase the priority of one dimension by lowering the priority of another. This sort of tool, especially when used with a number of stakeholders, can be an excellent way to work through different expectations and amongst different stakeholders. However, this technique also introduces some limitations. While it does allow us to prioritize, it can’t quite distinguish what the absolute criteria is. We can focus on dimensions, but are the top 3 deal breakers? What about the top 4? There still is some ambiguity we need to cut through.

Project Constraints

Jim Highsmith proposed the use of identifying project constraints to as a way of reinventing the triple constraint. His argument is that those dimensions can be prioritized into “Fixed”, “Flexible”, and “Accept”, but those can additionally be illustrated with threshold criteria. Let’s illustrate that tool with the case of the sports application.

In this example we see that the primary constraint is schedule. The application must launch by 3/1/11. The flexible constraint is budget. In this case there is an existing team, so while there is a little bit of flexibility with the budget, this dimension shouldn’t move too much. The final constraint is that they can generally accept an application that can provide scores and game highlights. Thus we see the project team must deliver the application by the specified date while adhering to the general burn rate it currently has in order to opportunistically deliver whatever functionality it can within those constraints. As you can see with this model, whave a more precise conversation around the precise criteria.

The concept of a fixed constraint compared to a flexible constraint can be applied to the broader set of criteria identified in our earlier exercise. Let’s take a look at the situation illustrated in figure 4 using a constraint table.

What Do You Mean, “All Scope”?

Regardless of which of these more detailed techniques you may use, clearly breaking apart the “scope” dimension is critical. I have participated on too many projects that have blindly said something like, “our new system should deliver all the scope of the old system”, without really doing any analysis of exactly what that is. Indeed, I find that the question of scope can usually be broken into smaller pieces. Let’s look at some examples.

• Break by users: some applications have either a wide array of user times or clients who use an application differently. In this case, you may want to identify different dimensions to prioritize. For example, you could take an online book store and break it apart by the different roles and say something like the functionality for an online book shopper is the highest priority, as they are the ones actually buying the books. Support for wholesalers providing the books and your administrative support staff may be lower priorities for your first release.
• Break by business objectives: many projects have hard interdependencies or down stream processes that require time in order to deliver their own functionality. For example, imagine you have a web service that a customer must interface with. You may have priorities by date, based on the delivery schedule of your partner. Let’s say that you and your hypothetical partner plan to launch a new service for the holiday season, which must be live by 12/1/12 in order to take advantage of the holiday season. However, your project is not responsible for integration with the vendor. Rather you, must simply provide them with a usable web messaging interface by 11/1/12 so that they have 1 month to tie it together an test. That delivery of a usable service may be a more important criteria for the team than the actual 12/1/12 implementation date.

Let’s take one last look at a hypothetical project book store project and see how this whole thing plays out

This is More That Just Mechanics

While these exercises might seem pretty straightforward and simple, sometimes they can be quite contentious. I have encountered a number of anti-patterns when trying to use these types of techniques

• “We already know what the priority is” - frequently a project manager or sponsor may state quite simply that this level of detail is not important, because they already agree on it. In these cases, sometimes the easiest thing is to ask them simply to write it down and compare it to what some other major stakeholders think. Frequently, this will reveal enough inconsistency that they realize they need to entertain a more detailed discussion about criteria
• “But I’m the sponsor, Isn’t this simply my decision?” – sometimes project sponsors may feel offended that you are trying to democratize what they see as their decision to make. It’s very important to be clear about the point of this type of exercise and how you will use it to make decisions. Chances are, a project sponsor funding the project will ultimately make the prioritization decisions and define the final criteria. The point of an exercise like success sliders or constraints isn’t to do that for them, but rather to surface the expectations and perspectives of other stakeholders so that the sponsor can make the best informed decision. If the dev manager says that reusability is very important for the success of this project, that very well may at least be worth entertaining the discussion to understand why. There’s a chance they may know something the sponsor doesn’t and the discussion will help lead the group to a better decision.
• “This is ALL important” – some groups of stakeholders may be unable to parse more detailed criteria like in some of our later examples in this article. Rather, they may have a very hard time saying precisely what is or isn’t critical for success. This is usually where a force ranking, like in FIgure 3, can be most valuable. Before even engaging in a discussion about which dimensions are truly must have, or even the precise dimensions, stakeholders must simply prioritize in a force ranked order.
• “We don’t want to preemptively surrender scope” – when engaging in this exercise with groups that have little trust, its quite possible the business may reject this type of exercise feeling like the development team is simply trying to get them to give up scope or lower expectations. The point of this exercise isn’t so much to surround things; ideally, we’d like all dimensions. The point of the prioritization is to do responsible project management. We want to know what’s truly important before we start the project so that people can make informed decisions along the way ad new can manage risk so that if things do go wrong, we are able to maximize the chance it won’t impact our primary success criteria.

Kaizen

Kaizen is that attitude of maintaining the habit of constant little improvements.  Once an organization accepts this as everyday work, they wield a powerful tool for keeping themselves nimble in the face of the ebb and flow of change.  The idea is simple: examine where you are, process-wise; agree on where you want to be; and identify what next step can you inch you closer.

For many teams who are first starting this process, the list of improvements can be overwhelming.  It’s long and everything seems like a high priority.  How do they know where to start?

Faced with this problem, I came up with a simple tool to help teams quickly prioritize their efforts and get to a roadmap for change.  I call it “Kaizen Map”.

Herding The Archicats…

The story begins with a group of Architects (read: lots of strong personalities in the room).  This team is a critical part of a larger program (~100 people total engaged in a multi-system technology refresh); their job is to reflect on the first release (about six months in duration) and come up with problems that need attention.  Specifically, they need to identify the top one or two problems that require immediate attention and dig into those: showing what the root cause was and suggest some potential solutions.  They only have two hours to do this.  Part of the challenge is that they need to not just come up with ways to improve their own team’s performance, but the target two items need to be process improvement recommendations for the program leadership.

I knew it was going to be difficult to get through even just one item but I knew I needed to leave them with a backlog of potential improvements.  I had been storming over various ideas of how to herd these cats when, 10 minutes before the retrospective, I had that flash of inspiration.

Here’s what we did:

1. Without a whiteboard in the room, I quickly fired-up Visio and drew a Cartesian coordinate system in standard orientation.  Along the abscissa I noted “Value” and down the ordinate I wrote “Level of Control”.
2. I handed-out pads of sticky notes and pens.
3. I oriented the crew toward our goal: we needed to come up with our top two suggestions for improvement.

… the crew began writing, some feverishly, others tapping pen to their yellow pads…

1. One-by-one, I had them pass me the items.  I read them out loud so everyone knew what was going up.  The author always had some color to give and then a pinball of chatter. I gave ‘em up to 1-2 minutes to bounce it around.
2. Then I asked, “so, if we were to solve this problem, how much of an impact would this have on our ability to deliver (compared to the other items on the map)?” I walked up to the graph and positioned the sticky note horizontally according to consensus (higher-up the greater the impact).
3. I followed on with, “okay, how much control do we have over this problem?  Is this something that we can completely solve ourselves?  Or does this require coordination with another group?  Or is this something that we’d need someone else outside this room to take on?”  I would slide the sticky note from left-to-right depending on their answer (the less control they had, the more to the right the item would slide).

… and we repeated this process for each new item.

Within 50 minutes, we had achieved our first pebblestone: identify the top two problems that needed to be address.  With the Kaizen Map, it was simple to see: the two top-right-most items were it (i.e. the two problems that, if solved, would make the biggest impact to the program’s ability to deliver and required the most help in addressing.

Over the next hour, the team tackled these two symptoms (using a technique I call “SCSC”, more on that in a subsequent post) and produced meaningful, supportable, actionable recommendations for the program to consider.

A Summit of Solutions

In this same program-wide retrospection, ten other teams went through similar exercises, independently, to produce their own program-level process improvement recommendations.  We then faced the task of prioritizing all of those items.  Each team sent a representative with their recommendations to a working session wherein we would coalesce all these items, prioritizing them against each other.  To do the relative prioritizing we again used the Kaizen Map:

1. each representative presented their two recommendations, which spurred a discussion around the merits of the proposed solution.
2. We asked the same two questions as before:
   1. what’s the impact and how much control do we have in implementing the solution?
   2. As a team, we determined the right spot on the map for each item.

Again, the power of the visual prioritization helped keep the tempo of the meeting at a proper clip: fast enough to get through the items, slow enough to allow the key elements of each solution to be presented and discussed.  From there this combined group (i.e. all of the teams making up the program) now had a backlog of improvement suggestions which they could continuously pull from.

The Kaizen Map is a worthwhile tool because it focuses the discussion around the two most important aspects of process improvement: putting our energies toward the changes that lead to the most value — maximum impact in our ability to deliver; and categorizing those items across the three major possible levels of control (each having a different kind of response).

Next Time…

In our next episode, we’ll dive into the problem-solving technique that the people in this program used to make potent improvement recommendations — ones that tie the lived experience of the participants to powerful solutions that were best poised to make real change — a technique I call SCSC.  Stay tuned…