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>.

Introduction

My current assignment has me coaching a software development group that is responsible for adding features to a legacy product that is on a yearly ‘shrink wrap’ release cycle.  The product is over 25 years old and is approximately 18M lines of code and has millions of users.  There are not many software products out there that are this old and this big and are being developed by a team that wants to embrace Agile.  We are like pioneers in a new territory.

The product development group (approximately 20 teams) started their Agile adoption process approximately 18 months ago on their own.  After a year of adopting Scrum they decided to get an outside perspective on their progress so they contacted BigVisible to help them assess where they were and help plan next steps for Phase 2 of their Agile adoption.
 

Goals, Strategies and Tactics

Two of the stated goals for their Agile adoption were to increase throughput while also increasing quality.  In order to achieve these goals one of our strategies has been to focus on catching defects much sooner in the development cycle.  This meant two things.  First, we will no longer rely primarily on a ‘testing phase’ at the end of the development phase for catching defects but rather engage QA team members as part of each Scrum team so they can test User Stories as soon as they are ‘Dev Complete’.  The teams are embracing this concept of ‘building quality in’ and getting away from focusing on rushing features into the product in order to hit their annual ‘code complete’ date.  (We have also suggested that the developers not start a new story until QA signs off on the completed story in order to keep the developers available for immediate defect correction and to limit work in progress.)

The second tactic we have worked on for increasing throughput while also increasing quality is to introduce more testing into the process.  The group has a very seasoned and effective QA group that does a lot of manual testing and there is a good level of automated testing in place but we felt like we could still raise the bar.  (Most of the automated tests are Silk scripts that test the application from the UI layer. There is some functional testing being done using homegrown test harnesses. But Unit Tests are new for most of the teams so there is very limited code coverage.)

So where do we invest in our testing efforts in order to effectively increase the product’s quality and to increase the team’s throughput?  Because we are an Agile development group and we don’t have much in the way of Unit Testing the obvious answer is to invest heavily into our Unit Testing framework right away.  Right?  Well, maybe not.  Let’s look a little deeper.

Assessment Summary

The following table is an assessment of the five primary testing practices within this development group.  The table shows to what extent each is being used to achieve the goals of the organization.

With this assessment in hand, let’s look at our situation again, this time using the Five Focusing Steps from the Theory of Constraints:

Step 1: Identify where the constraint is in their current process. Our assessment determined that for this client the constraint is QA cycles at the end of the development phase;

Step 2: Exploit the constraint. Can we exploit QA?  In other words, can we squeeze any more cycles out of QA?  Not really, QA is already overburdened.  Let’s move on to Step 3;

Step 3: Subordinate everything else in the process to the constraint. This is interesting.  The rate of which features are being introduced into the system by Devs is greater than what the Constraint (QA cycles) can handle.  This means that Devs should slow down and not work at 100% utilization.  Okay, but how does this help improve our throughput?  On to Step 4;

Step 4: Elevate the system’s constraint. To elevate the constraint of QA could mean hiring more QA folks to elevate their capacity. But elevating the constraint also means we might want to look at offloading some of the responsibilities of QA to other resources that are underutilized like the recently underutilized Devs due to Step 3 above.  Now I think we are getting somewhere.  But before you conclude that we are going to ask Devs to do QA testing, please keep reading.

Getting to Root Causes

Let’s look back at the assessment table again. One of the things that should have jumped out at you is that the team has not consistently had Acceptance Criteria for each User Story.  That’s a bad process smell.  Let’s dig in a little deeper there.

This is what effective User Story Acceptance Criteria does to enhance the development process:

• It helps set up the boundaries for the scope of a User Story (User Stories tend to be very small in terms of scope so clearly establishing the scope of a story is important)

• It lets the Developers know what is going to be expected of them in order to complete the User Stor

• It lets QA know what to test

• It lets Developers know what QA is going to be testing (ah ha!)

One of the problems we found is that QA and Devs were out of sync in regards to the scope of Users Stories.  This caused some churn between the two groups as they were too often debating what was in scope and out of scope for the User Story being tested.

But even more importantly, we found that Devs, because they were driven by the current system to get as much code written before their code complete date rather than get stories completed (signed off by QA), didn’t always test their work before they said their User Story was Dev Complete.  Defects that could have been caught by developers by testing against the User Story’s Acceptance Criteria would have prevented a lot of defects from being passed on to QA.

Conclusions

In order to break our current system’s constraint, we have made consistent and effective Acceptance Criteria with our User Stories a top priority.  We have also included developers executing the Acceptance Criteria before they ask QA to sign off on the stories as part of our Definition of Done for a User Story.  This will result in fewer defects making it to QA and therefore reduce the overburden on QA.

But let’s get back to the original question: what about Unit Testing?  Our assessment found that a lack if Unit Testing was not a constraint in their current process. But that doesn’t mean we aren’t going to address Unit Testing as we all know that there is tremendous value in Unit Testing.  Not only will Unit Testing help in catching defects, it will also help make for cleaner code design and self-documenting code, both of which will eventually address potential upcoming constraints if the constraint in the system moves to Developers.

So, while we are focusing on Acceptance Criteria we are also encouraging and coaching teams to start doing Test Driven Development (TDD). But we won’t be measuring code coverage quite yet.  You recall the adage ‘You get what you measure’.  If we start measuring Code Coverage then we may lose focus on the real system constraint.  We’ll start measuring Code Coverage when it makes sense, but not right now.

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)

Last fall I went on a 2-week vacation with my wife in France.  When I returned, of course, the gag was “Did you run your vacation agile style?”  ”Did you start every morning with a scrum?”   I love playing along, but as I thought about it, to my horror, there was a lot of “agility” to my vacation, and maybe their teasing wasn’t so far from the truth.

As an example…

We spent three days in Paris and the rest of our time roaming around the country in a car.  It was essentially a sightseeing vacation.  I maintained a big list of things that we intended to see.

A Backlog.

Much of the time, we woke up in one town and the only real objective for the day was making it by nightfall to a town where our next reservation was.

Sprint goal.

While we might have several things we wanted to see and do every day…

Sprint backlog.

…there were always things that got in the way of our plans, like unexpected traffic or bad weather.  Sometimes we simply left a little late having spent extra time savoring our croissants and café au lait.  As a result, we might have to drop the least important excursions.

Continuous prioritization.

We wouldn’t always have a clear idea of exactly what we wanted to do once we arrived at a new destination, but we usually had no problem coming up with a plan.

Grooming the Backlog.

At one point, we found ourselves in the Alps with inclement weather.  My plan to take the cable car up to the top of Mont Blanc fell apart because they were having snow and whiteout conditions at the top of the mountain and high winds closed the cable car.  So we changed plans and headed south to the Riviera one day early.

Sense and respond.

At the end of the trip, during the TGV ride back to Paris, we reflected on our trip.  I asked my wife if she were to plan the trip all over again, what would she do differently?

Retrospective.

I don’t know whether to be embarrassed or proud.

At least the inside of our car wasn’t covered with stickies.