My Contrarian View

Abstract

One of my favorite sports personalities is Bill Belichick, who at the time of this writing is the coach of the New England Patriots. Belichick famously talks about not remembering wins or positive plays, instead focusing on negative outcomes in his never-ending cycle of attempting to improve. Belichick has had a Hall of Fame career, but immediately at the end of each game he focuses on the things his team could have done better vs. the things they did well.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

At the beginning of Anna Karenina, Tolstoy states, “Happy families are all alike; every unhappy family is unhappy in its own way.” Likewise, all successful Agile adoptions are the same—they focus on the creation of value and bringing people together; but each unhappy Agile adoption is unhappy in its own way.

In a book about Agile/Lean adoption and the benefits of becoming a Lean/Agile organization, it might seem counterproductive to talk about why organizational change fails. However, we feel that we learn much more from failure than from success.

One of my favorite sports personalities is Bill Belichick, who at the time of this writing is the coach of the New England Patriots. Belichick famously talks about not remembering wins or positive plays, instead focusing on negative outcomes in his never-ending cycle of attempting to improve. Belichick has had a Hall of Fame career, but immediately at the end of each game he focuses on the things his team could have done better vs. the things they did well. Although his approach might seem extreme to some, it certainly illustrates how many extraordinary people learn from what is deemed by others as “failure.”

With that in mind, the following sections describe the primary failure modes of business transformation .

Lack of Executive Leadership

There must be leadership who understand, at least at a high level, the outcomes that need to be achieved and earmarks of good adoption for a business transformation to succeed. It doesn’t matter where you are transitioning from or what you are transitioning to. Leaders must stand behind the changes that occur and provide leadership to get there. You cannot tell your teams to “do as I say, not as I do” because they will try to get around the directive at every turn.

Training the execution or development teams and not the leadership can cause many issues within an organization. Teams can define “Agile” in any way they want if the leaders cannot say differently. When a leader becomes involved in a project, usually because the wheels have fallen off, the leader can single-handedly derail an entire transformation in one day by asking for metrics that don’t exist in Agile environments. We have seen leaders demand teams start using traditional methods and blame agility for slowing down a project, when in actuality it’s just the first time the leader has seen the true capacity of the team.

Agile methods will highlight every issue a team is having. Suddenly, a leader can see every process misstep, every communication issue, and every poor estimation that their teams make. We have seen leaders panic as Agile methods start to make every issue a team is having transparent to everyone in the organization. We have seen the leaders blame Agile methods themselves and say they don’t work, because it was more comfortable to sit in a room and agree that a team was 95% sure they could complete a project on time, on budget, in scope, and with the resources allocated, even when everyone knew those plans were untrue.

You cannot fix issues if you hide them or punish teams for having them. Expect that all of your issues will be highlighted as teams take on more and more Agile practices. Expect that this will happen at every level in the organization where you adopt Agile practices. Know that this will happen and lead your teams through it. When we used to lead Agile transformations for corporations, we used to tell executives that there was some information (metrics) they weren’t allowed to see for a year. The data were for the team only. After a year of training, coaching, and mentoring, if the team was still struggling, then we might have a personnel issue and at that point they could have access to the data.

We also find that lack of executive leadership involvement means that the leaders cannot tell if they are transforming correctly or not. Teams get away with doing “Agile their way,” which often leads to what we call feral Agile teams. These are teams that don’t work together, don’t adopt similar best practices, and don’t produce any more data to steer your business than they did when using traditional practices. As a matter of fact, they often produce less because leadership cannot tell them why they are wrong when they say that Agile means no planning, no estimating, and no release dates.

Making sure your entire executive team learns enough about Agile and how to apply it to gain the most value for your organization is mandatory for organizational transformation. Ensuring the practices your teams adopt are consistent so you have the data you need to run your business is vital.

Lack of executive leadership drives all other failure modes. We generally see one of two scenarios in this situation:

• Skunk Works operation

• Checkbook commitments

Skunk Works

The designation skunk works originated in aerospace and is generally used in product development businesses to describe a team in their organization given a high degree of autonomy, and who don’t have to follow the rules. When we first heard of skunk works, it related to teams who were working on cutting-edge, incubator, or secret projects. In some companies, every Agile team becomes a skunk works team and no longer has to abide by any best practices, processes, or oversight. This is not Agile.

A few years back, and in some areas of the world where agility is just starting to catch on, we see the Agile transformation being done as a skunk works project. The teams start using Agile practices without approval. They hide their new skills from management for fear of being shut down. They try to bypass or evade product life cycle processes, including gates, milestones, and oversight.

Having an Agile organization will only benefit you as an executive. If you find this is happening in your organization, go talk to the teams and give them the support they need to be successful. Let them become the pilot program and leaders of your Agile transformation. If you have many teams who are all applying Agile practices differently, have them determine a consistent, agreed-on way of applying the principles so you can have consistency. It will greatly benefit your organization in the long run.

Checkbook Commitments

We see this so frequently in companies that it’s becoming commonplace. An executive decrees the change to Agile delivery across the entire IT or product development organization. Lately they are decreeing they are to become an Agile business! However, there’s no real follow-through, knowledge of the goals they are trying to reach, reason they are moving in this direction, or knowledge of how the executives themselves will need to change their behavior: It’s simply a “checkbook commitment .” More often than not these days, it’s a commitment of pennies and not even a check to get the help the teams need to be successful.

The executive demands results, yet doesn’t change the metrics by which success is measured. He or she also asks for things that don’t exist in Agile practices, like Gantt charts. These leaders continue to hold weekly or biweekly staff meetings and show that they are not committed to changing their own actions to support an Agile business. They keep people in place to “drive” the projects to completion.

Unengaged, the executive proclamation for an Agile adoption will never move to a true business transformation, no matter how much money you spend.

Think about that for a minute. At best, without the executive’s continued engagement, the organization will only have pockets of Agile success, typically limited to the team level. The business will never see an increase in quality or productivity, get products to market more quickly, or respond to the market any better than they did before they “went agile.”

Teams will move away from the light discipline they had under waterfall processes to a more chaotic coding method with no planning, no idea of when something will be done, and no data to give a good project status. Leadership will lose sight of what they are getting for the millions being spent in their organization. The organization will likely grow to blame Agile (and each other) for decreased quality, productivity, and insight into the value being created.

The executive’s resignation letter will conveniently not include the word “Agile” in its summary of successes.

Failure to Transform Leader Behavior

We cannot even begin to count the number of people in leadership roles who we talk to who believe that an Agile transformation will not affect them or their own behaviors. Transformation is a journey that includes every person in an organization.

Leadership must make a personal commitment to each other and their teams, and expect a commitment from their teams to truly transform a business.

You need to commit to your peers that you will stop running your business with false data and assumptions. Here is an example of what we mean: At the start of both of our careers we were part of product teams that planned using waterfall or iterative and incremental approaches that were governed by a phase-gate process. To clear Phase 2, we presented plans and hundreds of pages of documents that proved we could meet a certain date, with a specific scope, budget, team, and quality level. Everyone sitting in that room knew that this would never happen. Everyone knew we weren’t 95% sure we could meet this plan. Everyone agreed we could meet the plan and congratulated us for creating a plan to get the work done. We see this type of thing happen all the time and it has become a standard way of running a business. We see it in strategy meetings where the market analysis numbers are made up or not current, we see it in planning meetings for projects on which we are basing our revenue projections, we see it in sales planning meetings, and so on. It seems somewhere along the line we went from running our businesses on real data to pretending that the made-up numbers were valid.

If you are in a business that does this, stop now. Start calling each other on it and agree that the decisions made based on the false data are probably not the right decisions. If this is all the data you have right now to use in making decisions, then do the best you can, but stop pretending that those plans won’t change. Promise yourself and your teams that starting today you will all be allowed to voice when something isn’t real. You will make the best decisions you can while you work to get real data, and you must agree that the plans made will change.

So what commitments do you need to make to your teams? You need to commit to measure them differently. You’ll start to measure value delivery over meeting a schedule, that working software will be valued over software specifications. You also need to promise them that you will provide them with the training they need not only to learn the basics of an Agile method, but also to engage in continuous learning. You will need to understand the methods well enough so you can back them up when someone questions them or when another leader asks for traditional project details. You must also promise that you will call them out when they want to revert back or not be transparent. You’ll provide the guidance they need as they learn to work in a new way, especially at the beginning, when Agile practices are highlighting everything that is not being done correctly or that is going wrong.

Also promise them that you’ll reward learning and celebrate even the small successes, that you understand the chaos curve of organizational change and will lead them through it, and that you will help them become predictable.

Leaders must accept that a successful transformation is a journey and seek guidance for a transformation with a broad, sustainable impact. Leaders make a personal commitment to their teams, and in turn they recognize the personal commitment they are asking of their teams.

In some of the most successful companies we’ve worked with, we find leaders who just get things done. They know the right actions to achieve success. They direct their teams to perform those actions, and they have the power to control all aspects of the work and do whatever it takes to get it done.

How often does that really happen?

Many times, in the not-so-successful companies, we find leaders telling the teams what to do, which generates a false sense of success via control. When a well-meaning leader powers through difficult circumstances regardless of the impact on the team, they leave the wisdom and the morale of the team behind. These types of leaders also reward heroics; those who work nights and weekends to get a job done, or those who are constantly jumping in to “put out fires.” Quite frankly, if an organization is continually on fire and needs a hero to get the work done, it’s not being run well. Planning is not done well or people would not need to work late nights and weekends on a regular basis. Unexpected events should not be the norm. Although these things occur in even the best run organizations, it’s the frequency with which they occur that should sound the alarms. If your teams are constantly having to perform heroics to get their work done, take a step back and figure out how to get them to a sustainable pace. Often you need to slow down initially to move faster in the long run.

As leaders, we don’t want to be standing behind our teams’ back pushing buttons or pulling strings. Who has the time or desire to do that? Instead the leader needs to take a service-lead approach and use the following principles:

• Systematic neglect: In 1970, in his booklet titled The Servant as Leader, Robert K. Greenleaf identified two extreme types of leaders: those who thrive leading under pressure and those who endure pressure to lead.¹

  The manager knows the limits of how much focus can be allocated to issues, and learns what to focus on and what to let go of to support the team and achieve goals effectively.

• Acceptance: A leader knows when to let go and trust the instincts of the team, accepts the wisdom of the team, and is prepared to support it. You pay the people on your teams for a reason. Trust them to get their jobs done. Almost everyone we meet wants to do a good job. If your teams are not succeeding, find out the real force behind the failure. It is rarely a lazy or unwilling team.

• Listening: A manager facilitates useful and necessary communication, pays attention to what remains unspoken, and is motivated to actively hear what others are saying. How often do you actively hear what others are saying or trying to tell you? As leaders of corporations, we get so busy and need to focus on so many different areas that it can be difficult to stop and really listen to what we are being told.

• Language: Leaders speak effectively and nondestructively; they clearly and consistently articulate the vision and goals for the team. Leaders need to fully understand their strategy and initiatives and be able to efficiently and effectively communicate these ideas to the teams, as well as have an understanding of how the teams’ work will help the company meet those goals.

• Values: The manager is responsible for building a personal sense of values that are clearly exhibited through consistent actions. He or she supports team behaviors that build this sense of values. What values does your company truly support? What do you incent with your bonus programs? Do they align with the values you state to the public? We have worked with many companies whose core values state that they value teamwork, yet they incent people to work against each other and only bonus the individual. Make sure your actions align with your values.

• Tolerance of imperfection: A leader modulates his or her own sense of perfection and offers to each team member an understanding of their strengths and challenges, and cares more about “How can I help the team grow?” Giving teams the time they need to change how they work and understanding the change curve and what the teams will go through is vital. Agile is simple but not easy. It highlights every issue going on and can be quite uncomfortable at the beginning, especially for introverts. Encouraging teams throughout this process and supporting them as they learn is something every great leader must do.

• Goal setting: A leader owns the vision. He or she doesn’t advocate for a personal belief in what is right, but rather maintains the goal for a higher purpose, inviting others to align with the vision for the overall good. Everyone in the company should have similar goals that they are working toward. Sharing those goals and why they are important is key to successfully leading teams. We see many organizations where lofty goals are described in jargon and they mean nothing to the front-line teams. Be sure you are setting goals that people can get behind and make sure everyone understands how they will be measured. Make those measurements visible so everyone plays a part in owning the outcome.

• Personal growth: The manager recognizes the value of continually finding diverse disciplines that invite new ways of acting in service to the team, and models this growth behavior to inspire others. Modeling how to always improve is an important quality in a good leader. We see many organizations that require their teams to continuously improve, but they don’t follow a similar model. Requiring continuous improvement of our own practices and procedures models the best example for the teams.

• Withdrawal: A leader knows when to step back and allow the team to figure out its course, rather than inflicting a personal sense of what is right for the team. He or she carefully decides what to bring forward and when. Knowing when to provide guidance and how to provide it is imperative. As long as the team is following the standard requirements needed for you to get consistent data to run the business, they should be able to use the practices that suit them best. We often give options to help the team solve their pains or to help the team continuously improve.

No Change to Organizational Structure

How your organization is aligned can play a large role in whether Agile principles are adopted long term. Most people think this means restructuring their development teams to create entire product increments, but it goes beyond this.

We often ask questions like these:

• What is your current organizational structure?

• How many layers of management exist around each Agile team?

• How is governance perceived?

• What walls are required to be broken down over and over again for value to flow through the organization?

• What else do you ask your teams to do? What do you decree from on high?

We say we’re changing but are we really?

• We ask how they measure performance and find specific metrics for various departments.

Typical organizations have been set up for suboptimization of corporate goals . They pit department leaders against each other and give bonuses and awards based on one group winning over another. This goes against the basic Lean principles of optimizing the whole. If you are doing this, you are not encouraging your people to do better; you are instead incenting them to belittle others’ work.

We consulted with one company that incented individuals. Most of their bonuses were paid on the work done in addition to their job description. This sounds like a good idea, but over time it meant that people focused on the other things and didn’t do their day jobs—some weren’t even rated at all on how well they did the job they had been hired to do. It also meant that what was most important to each person was that his or her own idea won, not the best idea for the company. These employees would hide and step on some really great ideas so that their idea won. They would move forward with some initiatives so that it was too late for the other ideas to take hold. They, the individual, would win at any cost, and the cost often was to the company as a whole.

We limit visibility of the organization’s overall effectiveness and focus on our team’s success at the expense of success for the organization. Often, traditional metrics create accidental adversaries and enable finger pointing. Let’s look to reframe what we measure and how we measure our teams to ensure the company and the customers are benefiting.

What if instead we measure value delivery? Think of the results we could achieve if we change our focus from individual success, hero work, and pitting employees against each other, and instead focus everyone on creating value for our customers. We could work together to optimize for the whole system.

We need to make sure that everyone associated with the value delivery has visibility into the current state of the value stream, including its blocks and bottlenecks. Successful Agile transformations understand the goal as successful delivery of value to the customer and they coordinate as a whole to deliver that value.

Is your organization clinging to the notion of resource utilization? This involves believing that loading people to 100% capacity is the best way to get work done, and measuring people annually by how well they deliver in this fully loaded mode.

We recently were talking to a company that paid attention to every hour of every employee’s time. If a project came in two hours under schedule, they assigned new work to those people that took two hours. What do you think happened? Do you think any future projects ever came in ahead of schedule? This is completely predictable behavior based on actions, but discussions about these types of actions were met with blank looks and a resistance to do anything differently. This company was losing productivity because of how they tracked and managed their employees’ time. There are much better ways to increase productivity. The processes and policies they had in place to increase productivity had the exact opposite outcome.

To incent greater productivity, collaboration, and communication, you need to revisit how you appraise work . Instead of annually, by individual, 100% utilized, with MBOs set 12 months earlier, invite frequent feedback and focus more on team effectiveness and outcomes. Bias performance appraisal toward efficiency of value flow versus efficiency of workers. We are seeing many organizations that base MBOs on cross-organizational outcomes, which drives and incents collaboration between departments, teams, and business units. With the right automation, you no longer have to rely on manually generated Gantt charts to see how well a team is working. You can tell how value delivery is progressing early in development, in real time, to make trade-off decisions based on real data. We talk about this in more detail in a later chapter.

No Change to How You Work

You have invested heavily in predictive model delivery practices (a politically correct way to say waterfall)—and you know your projects will always be late and cost more than they are supposed to—but you’re comfortable with the practices and know how to effectively manage late projects within your organization. Maybe you are like the financial institution we recently visited. You are one of the largest financial players in the world but the people doing the work on your projects do not provide statuses; the project managers simply report how they “feel” about the work being done without a need for pesky facts.

You really want to be able to say you are delivering in a modern way, however. It might make the new people you have hired more comfortable as they settle into your company. You are in luck: Heavy, prescriptive frameworks are the new waterfall. We see far too many companies decide to simply rename what they are doing and pretend to be “Agile.” One hundred-forty person teams are now “Agile teams.” Multiyear projects are now made up of 12-week “sprints.” Two-hour status meetings are now “daily standups,” where they don’t happen daily, no one actually stands up, and someone assigns the day’s work to the team members. We’re Agile damn it, because we say we are. Even though we reap no real benefits from agility, we need something big and extremely complicated so we can justify our bad practices. Enter scaling frameworks.

To be fair, we really do not think the scaling frameworks that have become behemoths purposely cause this problem. Most of these frameworks, in the beginning, were a great idea. We have really gone too far, though, and they have become very bloated. In an effort to be everything to everyone, the modern crop of frameworks that companies adopt in a quest for “agility” have become incredibly heavy, prescriptive, and governance driven. When you need a several-hundred-page book to understand a framework that is guiding your efforts to produce value, something is wrong.

If we compare and contrast the concept of Agile, of Scrum, and of scaled frameworks, there are many interesting take-aways. Here are the first that came to us:

• Scrum has three roles: Scrum master, product owner, and team (everyone else). Some of the scaling frameworks have those same three roles plus at least 17 more. Agility was all about making the teams self-organizing and self-reliant as much as possible. Having so many people and roles needed for oversight eliminates this benefit.

• Scrum is described completely in the Scrum Guide, created by its founders Ken Schwaber and Jeff Sutherland, in 17 pages, and that includes the cover sheet, table of contents, and so on. Some of the scaling modalities devote almost as many words to describing single constructs in its hierarchy. Are complete descriptions bad? Of course not. If something is so complex, though, that you have to take 17 pages to describe one of more than a hundred parts, we have lost the concept of simple.

• Agile is defined as a philosophy of values that makes getting work done in the best way possible. The original manifesto is only a few paragraphs long. There are at least four different versions of some of the scaling methods—we see customers struggle for weeks deciding which one they want to adopt. If picking the thing that is supposed to make it easy to get to where you want to go is that hard, maybe things have become too complex.

Agile development is meant to be something you are, something your organization becomes. It’s a journey, not a multi-hundred-icon-driven map to a very specific destination in a one-size-fits-all model. The proponents of frameworks will tell you that delivering value is hard in a complex environment, and there are many people that need to be involved. That is all true, but there is no need to replace your huge and complex waterfall software development life cycle (SDLC) with a huge and complex new one. Set your developers free: Allow them to decide how best to deliver value. Adopt common-sense practices like letting teams plan, work, and deliver together rather than following a highly prescriptive model that tells them how to do everything. People are not icons on a map; they are the true value of your organization. Forcing them into yet another complex, prescriptive model is not progress. It’s simply the new waterfall.

No Business View of the Value Stream

Value stream is a phrase that is being used by many people to mean many things. In Lean, we talk about value stream mapping, which is a technique used to document a process as it exists today, then analyze it, optimize it, and continuously improve it. Others have started using value stream to mean a line of business, or a product (something valuable) that is delivered to customers. Still others say it’s a method used to define, construct, and deliver something of worth to a customer.

For the purposes of this book we will be using the Lean view of a value stream: a process your organization uses to get something of value done. This can be any process, not just those that create products. Almost every process touches more than one department or group within your company so we need to make sure we understand who is involved, who is responsible, and where the bottlenecks are.

Think of your most important process. It’s generally either the process that you use to create products and services or the one that allows you to collect money for providing value.

• Who is involved?

• Who is responsible for the entire process? Is there one person responsible?

• How are you incenting those that are involved in managing the people who participate?

• Are you optimizing the entire process or just a piece of it, as an indirect result of the incentive?

• Do you know where the bottlenecks are?

• Have you worked to mitigate them without negatively affecting the remainder of the process?

• Is someone optimizing their part of the process without seeing how that affects the entire process?

We have seen so many companies where they allow teams to optimize a small portion of a vital corporate process to the detriment of the company—and get highly rewarded for doing so! You need to have a clear line of sight from beginning to end, from ideation to utilization.

Most executives at companies we work with generally understand the process used to get a product created from ideation to release. They hear people complain about portions of the process but they don’t know how to optimize the process to gain optimal proficiencies.

Today we are all in the software business and it is vital that we don’t have process for process’s sake or we will never be able to gain optimal efficiencies. Today it’s about IT and product and technology organizations providing more value through product development. We find most organizations embraced silos, to the degree that even as they were adopting Agile practices, they did so in “Agile silos.” They optimized the engineering teams, without optimizing QA. They develop products more quickly but can’t get to them to market more quickly. We see companies optimizing parts of the organization, but not the whole. It’s great that your development or IT teams are creating product more quickly, but if your marketing teams can only plan campaigns around major releases, or your sales teams are used to selling the next big feature, the rest of your company can break down. Collaboration and aligning around value streams is key.

We all have one or more value streams or we wouldn’t have a business or a job. The goal is to map your system at whatever level of detail best articulates your sense of handoffs and bottlenecks, taking regulatory requirements into consideration. Those handoffs and bottlenecks represent delays and waste. We talk about optimizing a value stream later in this book.

Servant leaders don’t relinquish all control; rather, they recognize the value in releasing control when all concerned are better served. The level of control changes. You no longer need to manage teams day to day or ask for weekly status reports. With disciplined Agile practices, your teams provide you with data you need to run your business and to make the key decisions so you can beat out your competition. Realigning your organization to optimize your key processes will increase productivity, predictability, and quality, and mitigate bottlenecks and pain points. Maintain centralized control when you see that this is in the best service to your teams, but let go of the reigns and trust them to get the work done.

Failure to Decentralize Control

In a modern business, you don’t give up all control , you give up the need to control everything. Ensuring that decisions are made by the most qualified level in your organization can speed the pace of work, allow work to flow continuously, and ensure the best decisions are made.

When we talk about business agility, I like thinking about the ability to pivot and change as conditions do, or the ability to take advantage of opportunities. However, we also need to be cognizant of where the pivots occur in the organization.

Businesses need to pivot to drive their markets. Some of these are big pivots and some are small pivots. The big pivots happen at the portfolio and strategic level. Big pivots are things like changing what you invest in, adding a new strategy, and reallocating funds or people to a different area. Small pivots are made at the program or release level. They include technical decisions, architectural trade-offs, and decisions about providing broad functionality or deep functionality to create the most value. Big and small pivots should inform and influence each other.

Principles of Product Development Flow

There is a time to trust your teams and a time to provide oversight and guidance. Here are two basic rules for when to hold the reigns and when to let them loose:

• The Scale Rule: Centralize control for problems that are infrequent, large, or that have significant economies of scale.

• The Perishability Rule: Decentralize control for problems and opportunities that age poorly.

It’s pretty common for large enterprises these days to have a wide disbursement of teams across many time zones. Some companies even implement 80/20 rules that guide projects to employ 80% offshore teams with only 20% of teams located in the same building (or the same city). This trend seems to swing like a pendulum: The next decade we see 70% in one country and 30% offshore. We now realize that certain types of work are best done in certain areas of the world, as countries optimize for various business roles.

When you have such distributed teams, it’s even easier to fail at your Agile transformation. We have seen companies do things that directly contribute to these failures, such as these:

• Set up a complex geographic maze based on the economics of resource utilization.

• Ensure a time zone difference between 7 and 11 hours.

• Rely heavily on e-mails and large documents (especially detailed product requirements documents and test plans) for your communication.

• Definitely don’t invest in bringing people together to collaborate or train.

• Trade face-to-face for late-night or early-morning telephone calls.

Many companies trade face-to-face collaboration for the promise of lower costs. For this technique to be successful, it is even more important that you have the right processes and tools in place and that you trust your teams to do the right thing. You need to ensure consistent practices are in place, a good tool that can be accessed by every team, and consistent understanding of your rules of play. By rules of play, we mean that if your engineers are in one country and your QA team is in another, everyone understands that the entire team (engineers and QA) are responsible for the quality. Work cannot be thrown over the metaphorical wall. Monitor the value stream progress and the flow of work when full teams or portions of your teams are distributed.

Ensure working agreements and communication plans are fully implemented and that these agreements and plans work across cultures in your organization. By definition, distributing work to teams around the world requires you to understand each culture, how they work, and what motivates them. How much control do you need over these teams? It doesn’t matter where your company originates or which teams are “offshore” for you. What matters is that you take every culture and work environment into consideration.

With your distributed teams, how fast do you get feedback? One of the big mistakes we have seen over and over with distributed teams is that they use the same process and feedback loops as they did when they had all work originating in one country. When deciding where to put work in your global business, do you calculate the cost of delay in your return on investment (ROI) equation? Do you have people who know how to and who can mitigate the challenges of distributed teams for the entire organization? What is your escalation path when the constraints become overwhelming?

To solve for these problems, do the following:

• Hire a coach that knows how to work with distributed teams. Ask potential coaches how they solved these problems before. We can’t tell you how many times we have been asked if we work with distributed teams and after one shallow, overly simplistic answer, we are accepted as knowledgeable. Make sure your candidates can articulate how they have solved for cost of delay, communication, and culture issues. They should be able to tell you in detail how they have put in place processes and tools that work worldwide so they could see progress against goals.

• Train everyone on the same Agile practices. This might seem like a given, but when you aren’t training even your local teams on disciplined Agile practices and when you can’t articulate at a high level what those practices are, there is no way this will happen worldwide. You must have a common understanding of things like a definition of done for stories, iterations, features, and releases. You must have the same toolset used to manage your stories, defects, tasks, test cases, and test run results so you can have your data normalized and you can have consistent data to run the company.

• Invest in high-definition, large-screen video technology to bring everyone’s voice into the same room. Make sure the team can see each other frequently.

• Have a facilitator in each location when teams plan their dependent delivery commitments. During your planning cycles, you need to have your execution teams behaving as full teams and not as “us and them.” Having someone who can facilitate these sessions is imperative.

• Whether using audio only or adding video, use facilitation techniques that ensure all insights are welcome (small-group brainstorming, round-robin check-ins, frequent breaks). It is especially important that you take all cultures into consideration when determining the best facilitation techniques to use.

• Invest in technologies that support transparent workflow communication. Your communication and discussion flows should allow fluid communication and discussion. As we bring new graduates into our workforce, they are more experienced at having discussions through electronic channels. Find a tool that has the features you need and use it consistently.

• Maintain a regular cadence of visits across all geographies and all roles. This item goes beyond where we talked about having team members spend extended periods of time at the other locations. Managers and executives need to be engaged at every location as well. We often see roadshows where executives go and give speeches to each location, which isn’t very effective in the long run. Spend time talking to the team members, solving their issues, removing impediments for them, and really hearing from them what is working and what isn’t.

• Ensure you are linked in to their retrospective outcomes. Every team should be creating action plans and will have things they need from leadership to succeed. Make sure you are solving these issues while you are visiting the global offices.

• Build working agreements that support core hours for availability, or alternative solutions for quick turnaround of feedback. Working agreements are mandatory among team members, especially when teams are split across geographies. Make sure your teams have them and adhere to them.

• Trade or share the burden of dealing with broad time-zone differences. We have used many different techniques to ensure the time-zone burdens are shared. Have meeting times change to be convenient for one team one week and the other team the next week. P ick a time that affects each team just a little (early morning for one and late evening for another). Share this burden to develop a real team mentality.

Better Yet, Eliminate Distributed Teams

Nearly everyone we talk to says this isn’t a choice for them, yet if they knew the amount of waste built into the distributed delivery model, they’d realize the irony of thinking it’s saving them cost and providing a value. The realization of the full cost is one of the main reasons we see for the pendulum swinging back to where teams are colocated.

Mitigate distributed teams as much as possible by having full execution teams at each location. We constantly see companies sending a portion of their execution teams offshore. This seems very popular with the QA portion of teams. Using this model sets up your organization for finger pointing and inefficiencies. It allows your engineers to disown the quality of their work. It puts the quality of your products in the hands of one team. Agile is all about the entire team owning the work, including the quality of that work. Allowing a part of the team to be in a different location undermines this principle. The most effective and efficient companies end up having as many full teams as possible in each location. It can take more than a year to get the right people on board at each location and to get some retraining completed, but it is well worth the effort.

When you do have to have a significant portion of the teams in a different location, send team members to the other location for extended periods of time. We sent engineers to the QA location for three to four months so they could integrate better with the quality team members. We sent quality team members to sit with the engineering teams for five to six months so we could advance automation and align the teams. It’s harder for teams to finger point and blame other team members when they have met them and know them well.

There are quite a few studies you can find online that will help you justify the investment in a nondistributed delivery model. Either put the whole team in one location and solve the feedback loop problem or put them all in the same time zone. Direct cost might increase, but so will quality, productivity, and predictability; in addition, time to market, waste, and indirect costs will decrease.

Lack of a Transformation Product Manager

In many organizations, we find that there is a real understanding of the need for a product manager role. As we develop products, we know we need someone to oversee the entire profit and loss of the product line. We understand their role and that they have a deep knowledge about their markets, customer needs, and how to gain the most value for the company.

When we go about transforming the entire company, however, we expect this to just happen on its own. Some companies leave it up to a grassroots effort, and still others exclaim that they will “become Agile” and expect it to happen on its own.

Do you see the problem? It really makes no sense to believe that transforming your entire corporation can be done haphazardly, in people’s spare time, as their interest dictates, and yet expect to have real outcomes that affect your organization.

• Is there consistency across your organization in practice and principle?

• Do people take ownership?

• Do you have fundamental corporate-culture issues?

• Who owns the transformation?

Does your organization look the same no matter where we drop in and look, or are there different practices and philosophies? In many organizations, the leadership believes they have to let the developers choose how they want to work, what tools to use, and what best practices to adopt. For an organization to be successful today, though, you need detailed data to run your business. Having consistent portfolio, project, initiative, feature, story, defect, test case, and test run result data across all teams means that you need some consistent practices to which all teams adhere and you need them to track data in a consistent format so you can roll up the results.

Having a common definition of done for stories, iterations, features, and releases is important. It doesn’t need to be exhaustive, but instead serves a baseline to which all teams are held accountable. Just like you have always had release criteria, you now have story, iteration, and feature criteria.

Best practices are important to define across all teams. Just like the definitions of done, these practices should not be heavy but should provide guidelines for how products are created and completed at your company.

What are the most important things that you do as a company? Create products for sale, reduce costs, and keep the business running. You need a consistent understanding and definition for the processes and practices you use to do these things, and consistent data must be part of the outcome.

Drop in on different areas of your organization and see if you see similarities in how they work.

• Congruency evidences itself through changes in behaviors across the team.

• Congruent team members move away from a yes–no, black–white, or us–them mentality.

• Congruent teams abide by norms in which pathological (yes, we said pathological) behaviors are not acceptable, because relationships matter.

The pathologies of blaming or placating are replaced with an emphasis on equal stature and equal voice. In environments of congruency, each member is heard, understood, and valued. Imagine your transformation as a product, but not software or a service you would sell. Rather, this product is one that works “on” your business. Your transformation product manager is the scout leader delivering a high-quality transformation.

This role works in a tight relationship with the executive owner of the transformation. Together, they define the disciplined exploration and execution to deliver a world-class transformation. They must be the models of congruence among all players in the transformation. They help the teams be attentive to the incongruent behaviors that can eat away at the sense of “us” and “we.”

If you walk around your teams and notice tendencies toward pathological behaviors like blaming, placating, distracting, or being overly focused on process and structure, you are smack in the middle of incongruence. Ignore these harmful behaviors at your own risk. How can we better behave as a whole system to bring about the best results? Ensure your transformation product manager has the vision and empathy to recognize the destructive, incongruent behaviors and the skills and knowledge to fix them.

There must be a nonnegotiable value of trust, not just within a team, but across teams. Incongruent product owners focus on “what’s in it for me.” There is a protectionist attitude about their particular backlog and the teams that work on them. Blaming others becomes their primary communication mode.

Instead, you should expect your product owners to value what this product brings and its projected cost and value, and make decisions based on what’s best for the overall portfolio. Remember, Drucker said culture eats strategy for breakfast.

Failure to Create Fast Feedback

For every action, there is an equal and opposite reaction.

—Newton

The best-laid schemes of mice and men / go often askew.

—Robert Burns, from “To a Mouse, on Turning Her Up in Her Nest with the Plough” (1785)

We’ve been part of product development companies for decades. In all those years, we have found a few principles with which everyone seems to agree: Plans change, and everything we do causes something else to happen, whether intentional or unintentional.

The law of cause and effect fostered the idea of assembly lines, waterfall processes, and postmortems. All of these are sequential, predictable, repeatable processes. Software development is anything but sequential, predictable, or repeatable, so we need to have frequent feedback loops.

In manufacturing, feedback loops on quality were less important or nonexistent compared to how many items came off the line at any given point. The nature of knowledge work is inconsistent with the predictable, sequential work Newton helped foster. We have to inspect to get feedback on bad behaviors or missed designs quickly and adapt.

Here are some examples:

• Clinging to a strict sense of predictability for when feature work will be completed.

• One centralized organization deciding all standards and rules for every team at the start of the transformation.

• Large-batch delivery of feature sets.

• Holding onto the belief that precision in analysis can resolve all risks in product delivery. We find that it is better to be roughly right than precisely wrong.

• Lack of experiments to test cause-and-effect assumptions about time, effort, and value.

• Blaming between business and development about delivery predictions and actual dates to support projected value.

• Blaming between development and testing about defects long after the features have been built.

• Failure to get feedback through retrospectives, or the retrospectives produce those pathological behaviors.

Fast feedback is the unspoken hero of congruency. We seek feedback on guesses (estimates), value, behavior, risk, culture, and Agile practices.

We look for feedback not only from our external customers, but from all of those involved in the transformation of your organization to a more modern way of working. We want feedback from team members, managers, directors, and all other levels of management. We want feedback from your natural leaders, whether they are management or not. All departments and all business units should be giving feedback.

Healthy Agile transformations crave fast feedback on every aspect of how the transformation is progressing. For this to occur, ensure you deliver feedback both ad-hoc and on a cadence, the latter being more formal and facilitated. Trust must be a fundamental part of your organization for you to get real feedback. Be sure to not give negative feedback to those making suggestions or those who mention things that are not working.

Ad-hoc feedback reduces the waste of waiting for direction on very transactional decisions; cadenced retrospectives ensure regular inspect-and-adapt sessions across the organization.

Shortchanging Collaboration and Facilitation

We are constantly playing with the balance of how to be a team member and how to remain an individual. This happens in all areas of an organization, from frontline engineers to C-level executives. Collaboration and teamwork is discussed as preferred, but we still need to stand out to get ahead.

Every day we struggle with balancing how to speak up, be valued, and not be afraid of recrimination while working toward the good of everyone. This is where a sense of congruency can help.

We are similar but all different and we need to facilitate our meetings in a way that lets everyone’s voices be heard, regardless of the type of meeting or the level of people involved. The success of each meeting can hinge on how well each person was heard and how much their ideas were acknowledged.

When we don’t facilitate well we create distrust in the team. People feel left out or that they aren’t being heard. Facilitation is a skill that good Scrum masters should have. Being a good Scrum master requires more than just taking a two-day class. They also need to be great facilitators so they can integrate diverse perspectives to converge on actionable decisions. The Five Dysfunctions of a Team by Patrick Lencioni is a great read on this subject.²

To be clear, collaboration does not mean groupthink. Let team members disagree. We need to hear every perspective, and at times argue our points, so that we uncover risks, opportunities, puzzles, and surprises. Some of the best collaborative efforts we have participated in included quite a few arguments. From our perspective, people argue about something they are passionate about. If they don’t care, they let someone else’s opinion win. You want your teams to have passion about what they are doing. This leads to better products and outcomes, and usually to stronger teams.

We’ve all heard the statement that we are only as strong as our weakest link. The same holds true for voicing opinions: We are only as smart as the least vocal person on the team.

Failure to Transform Beyond IT

We hear many people talk about the reasons they want to take their company through an Agile transformation . These often include faster time to market, building things faster, improving quality, and meeting the demands of a fast-paced market. They expect their IT or products organization to carry the burden of making this happen.

We were working with one company who had brilliantly transformed their development teams. The teams focused on value, and delivered things more quickly and with higher quality. They actually completed a product that could completely disrupt their market before any of their competition. They couldn’t get it into the market, though. The marketing department didn’t know how to market it. The sales department didn’t know how to sell it. The product sat on the shelf for four or five months so the rest of the company could catch up. During that time, a startup released a very similar product and beat them to market. They lost their disruption advantage. They lost a lot of revenue. They lost.

Transformation is about organizational change management. Change involves humans and sometimes humans are complicated. You need to address time, safety, and direct experience required to guide us through change or fail. You need to expand the transformation beyond your development teams or else it really doesn’t matter how fast they move.

How are you tending to your sense of change—not just as steps in a process, but as humans and teams in transition?

When we leave the human context behind—when we ignore the time, safety, and direct experience required to guide us through change—we have failures in transition.

The perspective of many executives is to build it faster and get it to market faster, but we can’t be successful simply by having a product ready. It’s a whole system problem, not an IT problem. You cannot take the mandate approach we discussed earlier, nor can you simply throw more people at the problem.

You must address the root problems your company is having to succeed. Many executives come from the perspective of looking at how to build products faster and get to market faster, with more innovation, by making their engineering teams more efficient.

Speeding up value delivery by concentrating your transformation on product development is suboptimal. Concentrating Agile transformation in the development organization looks slick. They get a sense of speedy efficiency around them, and that’s enticing. It can grab the hearts of people who thrive on heroics. Testers, developers, and UX are “transformed” into a new way of working across the product teams.

Through their work, the product engine begins to attain the purr of feature delivery. Is this truly transformative, though? No. Instead, look at the system as a whole to solve the real problems.

• Declaring the transformation from the executive level is insufficient.

• Rolling out all teams at once is insufficient.

• Starting up teams randomly is insufficient.

• Training everyone at once is insufficient.

Each of these is a useful but ultimately ineffective action, leaving the transformation sputtering toward a “good enough for now” end state. An Agile transformation is far bigger than the efficiency of delivery teams; it needs to encompass your entire organization and go well beyond IT.

Failure to Focus on People

We all have been part of companies that had us follow a process that had no benefit. We had to fill out templates or create metrics that either had no value to the business or that people used to make poor decisions.

In many organizations, we see people who view Agile practices as simply a replacement for the waterfall processes. Nothing could be further from the truth. Agile is not just about checking boxes and filling in templates. It involves teams, people, and their feedback in your transformation and how they work with each other and with you.

We cannot simply apply practices and measures and think we are Agile, and if that doesn’t work apply more practices and measures. No amount of process will stop bad behaviors. The bottom line, though, is that Agile is not just about process and structure.

In many waterfall processes that we used we could check off all the boxes but not check in with the people. We threw documents over the silo walls to other groups and expected them to get everything they needed from those often hundred-page documents. Now we know that communication is key—that anything written down is a placeholder for a conversation.

We need to fundamentally change the way we do business with each other. How does the transformation lead teams to engage with their colleagues in defining success beyond practices and metrics? If we simply apply these practices and measure these things, surely success will come, but it never does. Then when success doesn’t occur, we apply more process, right?

Ignoring the Path of the Individual

Every transformation requires that an organization move through a journey that is well described in the Kubler-Ross change curve . Figure 2-1 is a simulation of the phases Kubler-Ross described for grief, but they have been aligned to the phases people go through for change as well.

Figure 2-1.

Phases of morale during change

We have seen executives who don’t understand that change curve and allow teams to abandon the change before they reach the other side of the curve. They then deem Agile to be a failure and determine that it makes teams miserable. Nothing could be further from the truth. Teams are simply going through the standard change curve. Any change to the way they work will cause this. Any major change to your organization will cause it. Push through to the other side of the curve before you determine the validity of any change.

While teams are moving through this change, we cannot ignore the path of the individual. Change can create fear, uncertainty, and doubt whether you are changing processes, team members, or leadership. We tend to ignore the work of transition for each individual affected by the transformation.

There’s always someone who has something to lose, whether true or imagined. For example, many midlevel managers fear they will be out of a job if agility takes hold. They put up roadblocks to adoption of Agile practices and tend to continuously point out how the new way of working is not valuable in the organization.

Directors who’ve attained their stature through their ability to push through adversity are now being asked to find their significance in how they guide and serve, not push. Heroes who save the day at the end of every project or release are losing their motivation as they’re incentivized to work collaboratively in support of the team and at a sustainable pace. Teams are asked to alter their composition and perhaps their highly guarded bond. The well-meaning goal of creating a better way of working generates the unintended consequence of a big pile of fear, uncertainty, and doubt.

Human psychology is an interesting thing. People in transition shift from we to me. People can find themselves disoriented and disenchanted. In this stage, we guide team members to let go of what they’ve believed or assumed about themselves or about how they see themselves in their work environment and their attitudes toward others.

From me they move to the neutral zone, that ambiguous gap in the middle. Knowing they are there, you can help them begin to craft a new reality. We accept the reality of the gap between what was and what might be, sort of standing in the middle of the street. You cannot stay here forever, but you know you need to be here before you can get to the other side. In this organizational and process wilderness, you can begin to craft a different reality that can enhance or expand what might not have seemed plausible before.

Failure to Work from Backlogs

Backlogs are simply lists of work that has to be done. They are special lists because they are prioritized—not just high, medium, and low, but ordinally prioritized (1, 2, 3, 4)—so that when something is reprioritized, it affects the items that came before and after it.

Organizations that don’t work from backlogs often find that they prove out the Standish Group study that says 60% to 80% of all features implemented are rarely or never used.³ Think about that for a moment: 60% to 80% of the work that teams developing software do is simply waste.

Although the study was for four software products at four different companies, when I used to run QA departments I would determine which areas of our systems were used most frequently so I could do risk-based testing. I found these statistics to be pretty on point. The majority of users used about 20% to 30% of any product I tested, and some portions of the product (generally about 30% to 40%) were literally used by no one. Why is that? Because organizations don’t organize work into backlogs. They use requirements documents. Requirements documents have been used since software was first created, so why are they a problem? Because they force the business to ask all at once for what they want. Because they aren’t sure what they will actually need and they only get to ask once, they list everything they might need. Ability to print checks? Add it. Ability to send an e-mail to Mars (don’t know if we will need it, but we might)? Add it, and so on.

Basically, here’s what happens. The business prints out a huge document that no one has read and certainly no one understands and gives it to the development teams. “Here’s what we want you to build,” they say. The programmers lug the huge document into their programmer cave and begin to do programmer things. Because requirements documents are part of predictive models (waterfall), the programmers might not actually speak to the business for six months, one year, or more. They are just busy programming and checking off items from the requirements document. Finally, late and over budget, they come out of the programmer cave and say, “Behold, the greatest piece of software ever written! It’s bug free, it’s highly optimized, and we wrote it in Turbo Coffee COBOL Sharp+ because we thought you’d think that was cool. Here’s your application.”

The business takes one look at what’s been written and says “Um, what is this?”

To which the offended programmers reply, “It’s what you wanted, it’s written right here in the requirements document.”

Then the business utters the words that all programmers dread: “Well, that’s not what we meant. We cannot use this.”

Then the magical process known as change control begins.

Acknowledgment of Jean Tabaka’s Influence

Much of this section was learned from and inspired by the late Jean Tabaka and her blog series. Jean was the author of Collaboration Explained ⁴ and an Agile Fellow at CA Technologies. Jean inspired untold numbers of people that she touched with her many gifts.

Jean taught me about Agile way back in 2003. We embarked on a never-ending journey to discover what these principles meant to a company and how we could change how we do business simply by applying these principles to all we do. Jean was a remarkable teacher, mentor, and human being, and she is greatly missed. —Laureen Knudsen