Decide to Change


Considerations for the Switch

Set the Boundaries

Upper managers are right to insist on some form of formal project management to meet customer expectations. Why any company would not do so escapes me, yet I have rarely visited a company that did insist. The lack of a formal approach reduces profit, by slowing the delivery of whatever the company sells, and wasting the money paid to workers who aren’t creating output as efficiently as they could. Although these impacts are not as obvious in nonprofit or government agencies, they too want to serve as many people as they can by making maximum use of their limited resources.

Every manager I have talked with on this topic has instantly agreed that a disciplined approach has value and, in most cases, has been lacking in their organization. I have found little research to explain why managers don’t insist on such an approach, so I won’t speculate. What I will do is call on you now to make the decision, or try to convince your managers to. Insist to your employees that they choose not between “doing things as we always have” and Agile, but between these and only these three options:

  • Full waterfall: By “full” I mean designing and planning every detail of the development of the project before starting development, and instituting a standard change management process. The goal is to meet the Iron Triangleby making it as accurate as possible and then modifying it carefully to address the inevitable changes. In this case, I strongly recommend reorganizing the company into a “strong matrix” organization in which project team members are direct reports of the project manager(s), not the functional managers. Regardless, hire experienced PMPs and support their decisions.
  • Another system of Agile-at-scale: Buy books, hire consultants, or take classes if need be, and choose another system to implement. Notice the word “system”—don’t cobble together a bunch of methods on your own from the start. Adopt and learn a system, then modify it. If this approach is chosen, hire an Agile coach to come in full-time for at least three months (for one team) to two years initially (for large enterprise change) and implement that system. Again, support that person’s instructions and consider a strong matrix.
  • Full Stack Scrum™: As discussed shortly, gain agreement that this system will be implemented as presented before changes are made to it.

To repeat, people don’t like change, and non-managers rarely see the value of project management until after it is (properly) implemented. Many would rather complain about problems than admit they have a role in those problems and do something about them. Given a choice of “stay the course,” they will.

The Ideal Environment

One of the biggest myths perpetuated by the teambuilding industry for its own gain is that personality is a key driver of behavior. A mass of clever research studies has proven instead that the scenario is the key driver, a combination of the environment (including business culture) and the circumstances of the moment. So the further away your situation is from the ideal environment for implementing any Agile-at-scale method, the harder FuSS™ transformation will be. In the ideal setting:

  • The entire organization adopting the change reports up to a single executive with profit-and-loss responsibility for the unit.
  • That executive fully understands the implications of the transformation and supports it.
  • If the organization is part of a larger one, the parent imposes relatively few centralized controls on processes and tools; in other words, subunits are allowed to operate more like independent businesses.
  • Each team is or will be a cross-functional, full stack team formed of people in the same building, or at least within three time zones of each other, including the Product Owner and Facilitator.
  • People in cross-team Guidance Roles (the Customer and optional roles) are close enough in time zone to participate in all required meetings without issue, even if they have to work outside their normal business hours.
  • Dates are requested, not imposed, and the executives understand the response is a prediction, not a commitment.

Not having this environment is not a show-stopper—it just makes your life as a change agent harder, and the need for executive buy-in more critical. We’ll cover how to get that in this part of the site.

Two Approaches to Change

Strategies for Evangelizing

The step sets for this topic focus on evangelizing Agile to both the people who will be enacting an Agile method and stakeholder groups. For large organizations—whether entire enterprises, or fairly independent subdivisions—you may choose to work:

  • Top-to-bottom—Go directly to the organization’s executive team and if successful convincing them, ask them if they want to:
    • Try to build consensus across all stakeholder groups and teams, or
    • Make the decision themselves to implement Full Stack Scrum.
  • Middle-up—Evangelize to stakeholder groups and their managers first, and then go to the executive team able to report buy-in at that level.
  • Middle-out—In addition to the previous option, evangelize to teams before approaching top management.
  • Bottom-up—Evangelize to the teams first and possibly start implementing at that level, and then evangelize to the middle managers and executives in that order.

These four choices are built on the two directions of change: self-organization evangelized up, or executive decision explained downward.

Use Self-Organization

If you are working with one team or set of teams, you will be wise to allow it to choose whether to try the system. Formal project management requires much more meeting time and adherence to process than most people are accustomed to. Agile is such a different way of doing things, requiring a much higher level of interaction and accountability, I don’t think it is smart or in line with the Agile Manifesto to insist on it except for organization-wide change. Even in that case, you will likely get the biggest measurable impact if you build agreement to give FuSS™ a fair try top to bottom and side to side instead of imposing it.

Many people are more likely to give it a solid try if they don’t feel forced into the approach. As I reported earlier, research on persuasion suggests that people who come to a decision on their own also become self-motivated to implement it. Chief Financial Officer Stephen Irvin of Namaste Solar said in a 2010 talk that you can either make a decision and spend time building buy-in, or build buy-in and then make the decision. Either takes the same amount of time, he said, but in the former case some people never buy in. I think there is plenty of data to say the approach is financially rewarding despite the hassles. Namaste, a democratically run company, was the largest rooftop solar power company in Colorado at the time by one measure and remained profitable throughout the Great Recession.

As I have said, though, simply telling a team it is self-organizing without providing guidance on how to do so causes wasted time and heartache as they grope toward a process. FuSS shortcuts the transition safely and limits potential conflict by handing the team a proven structure and process to try.

Make the Decision

Bob Galen, an internationally known Agile coach and regular speaker at major conferences, caused a stir in the coaching community in 2014 with his blog post, “What the World Needs is MORE Prescriptive Agile Coaches.”[1] His position was that new teams need a firmer coaching style, someone willing to tell the team what to do and to stop bad behaviors until it gets rolling with Agile. What surprises me is the shock this caused for some people, as if the concept were new.

The only kinds of coach that aren’t prescriptive are the latecomers to the term, meaning business and life coaches. Most people on the planet carrying the job title “coach” are prescriptive, and their “coachees” submit to them because they know that is what it takes to get better. The word was first applied to people (instead of carriages) in the 1830s, for tutors at Oxford University who helped students succeed at exams. There was little in the way of choice for the person being coached. Math is math. Either you learned the information as the tutor presented it, or you failed. In the 1860s the term spread to sports. Even when an especially polite basketball coach says, “You could try this,” the player know he has to try it. I already talked about how sports coaches approach systems thinking. Conductors and directors generally operate more like a general on a battlefield in terms of overall group performance, and their performers generally accept it. They understand the need to subsume personal preferences to the coach’s vision so the group can perform in a coordinated way.

I also feel compelled to note that no successful project manager tells circuit designers what the right layout is; architects what computer language to specify; finance people how to run month-end analyses; technical writers what document format to use; and so on. This despite the fact that the success of the project relies on each of those decisions. Thus it escapes me why designers, architects, and writers are allowed to dictate what project management approach to use. Given the value of outside perspectives, everyone should feel free to ask questions of everyone else. But that is different from preventing the expert from doing the technical part of their job as they see fit, including the project manager who decides Agile is the appropriate method for the work.

Tutors, sports coaches and conductors do not have time to persuade everyone their system is right. The time for high performance is nigh. For large-organization change, executives have to decide how much time they have. My preference is for democratically run organizations that make decisions together, as described in the previous section. This is not, however, speedy, nor is it the method of governance in most companies and government agencies. Executives commonly make decisions about strategic and organizational direction, and the system of project management need be no different.

An organization meeting the criteria under “Who Should Switch” below will benefit all involved by making the switch. The months, or years, it will take to attain consensus among hundreds of people equals months or years of lost benefits. Hence I think it perfectly acceptable for executives convinced that Agile is the way to go to choose an Agile-at-scale system and tell their employees the organization is moving to that, period.

You may reasonably ask how this aligns with the principle of “self-organizing teams.” In addition to giving teams full latitude in how and when they do their work, this approach also respects self-organization by allowing massive change after the system is running well. I tell all executives and teams I train that once they are consistently hitting the Agile Performance Standards, they can change whatever they want to not required to follow them. If a year or two later they are doing nothing I asked them to, other than meeting those standards and pleasing their customers, that is perfectly fine with me!

In the first case, you will still need to do presentations to stakeholders and the teams, but bill them as “training and suggestion” sessions, rather than “consensus building.” People will view it as hypocrisy if you claim to be seeking input for a decision that has already been made.

Downsides for Some

One Meaning of Lean

An open secret among Agile advocates is that some individuals will be harmed by adoption of the Agile mindset across the enterprise. Many consultants will soft-pedal this to make a sale, but I’m not selling anything other than this site, so I can say it: Agile ain’t for everyone. That means executives need to brace themselves for complaints, reassignments, resignations, and perhaps, the need to terminate people who can’t make the transition. Specifically, the following types of people will feel—and may actually be—harmed by the switch to Agile:

  • People uncomfortable to a disciplined approach to any kind of process.
  • Executives accustomed to demanding delivery by a specific date, or directing how project management or technical work is done.
  • People accustomed to working alone, at their own direction, and/or without telling anyone what they are doing on a daily basis.
  • People who duck accountability for their actions.
  • Managers who like giving orders.
  • Middle managers, team leaders and project managers unwilling to shift to Agile roles, even though their old roles are going away.
  • Any of the above for whom there simply are no roles anymore due to team empowerment, so the company can save money by eliminating their positions.

Do not underestimate the damage these people can do to Agile adoptions. I watched helplessly as a FuSS implementation that started out with great promise fell apart due to a single resistor. The primary cause was the former program manager who said she wanted to shift to an Agile Release Manager role but refused to actually do so in practice. A major contributing factor was executive interference, but she consistently blocked FuSS advocates from addressing that interference directly with the executives.

When you seek buy-in, if a team member does not want to try Scrum, decide as a team whether that makes Scrum unworkable. This will likely be the case if the person has unique expertise in a critical skill set, or has management authority to sink the effort. Though the best solution is to train others in that skill set and remove that person and then tackle Scrum, otherwise it will make Scrum difficult to do. Another, less-ideal option, is to decide as the manager whether you have enough non-project work the person can do to make them valuable as an individual contributor (IC). One such person I worked with did nothing but provide high-level help to Customer Support. Another drove vendor relations for a set of hardware teams. In any case, it is vital that others who do agree to try Scrum learn how to do those unique roles in the case of unexpected absences or resignations (see “Cross-Training”).

Lacking an IC position, you may have to scrap the idea to become a Scrum team and use a different method of formal project management. As I will detail later, the choice should not be between “doing what we’ve always done” and Scrum. Or you can remove that person from the team and transfer in or hire someone open to Scrum.

Shifting Direction

Converting current line managers might be the hardest part of scaling Agile. There is no rational way around a simple fact: By definition, there is no such thing as a “team leader” when teams are self-organizing. Middle managers will have to either find other roles for team leaders or let them go.

For many people in those roles, Agile constitutes a radical change in duties, and it will be viewed by some as a troubling loss of power. People accustomed to directing work must provide value now by providing technical help or facilitating better communication. This means, most simply, letting go of control in exchange for the “reflected glory” you will receive when your project shines! Meanwhile, you can be doing all the things you wished you had time for in the past. Here is a generic list, taken from and detailed under “New Roles for You” in my free hypertext book on empowered teamwork, The SuddenTeams™ Program:

  • Process expert
  • Quality champion
  • Technical consultant
  • Special projects champion
  • Teaming champion
  • Customer champion
  • Learner (or researcher)
  • Systems thinker

FuSS does provide some specific roles suitable for former line managers who can make the mental change from directing to supporting. See the descriptions of the Architect, Agile Release Manager, and Agile Liaison roles under “Explain the Roles.”

The Bottom Line

Who Should Switch

If you are building a bridge of a type you’ve built before, with the same suppliers, in similar terrain, with the same core group of leaders and subcontractors, by all means stick to waterfall. I exaggerate a bit, because there are other situations where waterfall is fine. I have led successful waterfall projects in several industries, and would consider using it again in some circumstances. However, the more uncertainty you have about the final product, customer needs, personnel, tools, technology, and so on, the more you should consider Agile. In all my years of consulting or contracting in various technology companies, I have yet to find an R&D or NPI (“new product introduction”) project that would not have been better off using Agile.

A large-scale survey covering 1,386 projects reported by 859 respondents found strong evidence that using Agile methods and limiting upfront planning was correlated with higher efficiency in terms of the Iron Triangle, “stakeholder satisfaction, and perception of overall project performance.” Critically, the levels of technical complexity and team experience did not change those results.[2] This held for all industries that already had high Agile adoption, like technology and health care, but not those that did not, like “construction, manufacturing and retail.” My educated guess is that this is due to lack of experience with Agile methods, not because those methods cannot work in those industries.

The American Management Association[3] says there are four elements to consider when deciding whether you should have an “agile environment”:

  • Internal Uncertainty—This is based on “those things under the project umbrella that can be more or less controlled by the project manager, including scope, schedule, and cost.” In researchand development projects, among others, those three things are impossible to control. Less experience with the type of project you are tackling leads to even higher uncertainty.
  • External Uncertainty—The other cause of uncertainty is from “factors not under the project umbrella, such as the industry’s business environment, the competition, and high-level, business strategy decisions.” Less mature industries or product lines (regardless of the company’s maturity) have higher external uncertainty, the AMA says. Another very common cause of external uncertainty is when a team depends on deliverables from outside companies, or other teams within a company, to deliver the team’s work.
  • Unique Expertise—“This expertise may be represented by the sole individual who understands how all the pieces of a project fit together technically, such as the system architect, or by the most knowledgeable person in a small but critical area.” This expertise is a threat to traditional organizations because the loss of that person brings the work to a screeching halt. Even in less drastic circumstances, over-reliance on one person can slow a project because its progress is limited by that person’s availability. An Agile organization instead cross-trains team members to remove that threat. Also, having cross-functional teams means teams can help other more flexibly.
  • Speed—A final factor in choosing to be Agile is driven by the need for revenues from the project relative to the company’s overall income and its competitors. Because Agile delivers outputs to the customer sooner than waterfall, it better meets the need for speed.

A scientific survey of 189 European manufacturers in 2007[4] found the key drivers toward agility were the importance of:

  • ‘‘Changes in customer’s need.”
  • “Quality over product life.”
  • “Continuous improvement.”
  • “Trust-based relationship with customers/suppliers.”
  • “Customer satisfaction.”

In its 2017 Agile Practice Guide, the Project Management Institute says Agile methods “work well for projects that involve new or novel tools, techniques, materials, or application domains… They also work well for projects that:

  • “Require research and development;
  • “Have high rates of change;
  • “Have unclear or unknown requirements, uncertainty, or risk; or
  • “Have a final goal that is hard to describe.”

Putting together everything we have learned, what emerges is that any organization, regardless of function or industry, whose ability to please customers is critical yet hampered by rapid change of any type, will perform better if it adopts a disciplined approach to Agile.

Who Should Not Switch

That said, there is a fundamental and widespread barrier to Agile adoption, which is, top executives stuck in waterfall thinking. If you do any kind of R&D/NPI work, and your upper managers pressure or penalize you regarding a specific date—or worse, tell you what date you must hit—I recommend against switching to Agile. They will never be happy with anything short of the project plans and Gantt charts of traditional project management. Except for the CEO, this isn’t entirely their fault. Most companies are still hooked on fixed annual budget projections. They come up with educated guesses about how much money they will earn and profit they will make each month, quarter, and year. Critically, in this system they often are not allowed to change those projections even after—as almost always happens—it becomes clear they were wrong. (See alternative approaches under “Agile Budgeting.”) Here’s my key point: Top and middle managers usually have pay or job security attached to meeting those projections. Self-interest understandably drives resistance to Agile.

As a result, some Agile experts have tried to come up with ways like “Hybrid Agile” to marry the philosophies. But I believe they are incompatible. The primary reasons are these two Manifesto principles:

  • “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
  • “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Executives and sales people in a traditionally managed company cannot put customer satisfaction first. Why would they? They are compensated for hitting monthly and quarterly numbers, not customer satisfaction. Therefore they will sell and push for products that cannot be ready as quickly as they would like. In order to meet premature dates, they will either push teams to cut corners on quality (a guaranteed satisfaction breaker), or make people work long hours for weeks, thus breaking another Agile principle: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

When customer requirements are changed late in a waterfall project, executives either resort to the above tactics (“Do it anyway, but you still have to deliver on time”) or enter into negotiations that deny the customer’s requests. Either way, the customer, and in the long run the company, is hurt.

In all of these cases, a formal approach to waterfall will be easier for you, even if it is not the appropriate method for your deliverables. Coaches and middle managers who try to implement any form of Agile, much less a scaled model, are nearly guaranteeing themselves a lot of stress if the culture and policies aren’t right for it. “Create an Agile Enterprise” details the changes a company should make to fully support Agile. If they aren’t made, the result may be a partial and unsatisfactory implementation, leading people to say, “We tried Agile, and it didn’t work for us,” even though they really didn’t.

Having gotten that warning off my chest, I know most of you face this very situation. I would not have a career if people, including me, weren’t willing to try doing the right thing despite ongoing opposition. If you feel you can change your top executives to an Agile mindset, or feel compelled to try it anyway like me, read on, warrior!

Define the Choice

Desired Agreements

Back in my ideal world, the one leader with profit-and-loss responsibility over your unit will agree to the following and require all relevant managers, Guidance Roles, and team members to commit to them. If nothing else, the Agile Performance Standards must be mandated, or there is no point in starting the effort. The rest of the agreements can be left optional, but the fewer you mandate, the longer implementation will take, and the higher the risk of failure to change:

  • Some formal project management system will be selected and followed in a disciplined way (per “Set the Boundaries”), even if FuSS is not the ultimate choice
  • If FuSS is chosen, teams and programs must meet the Agile Performance Standards (detailed further down):
    • Delivery of 100% of stories committed to the sprint most sprints, at a sustainable pace.
    • If Planning Releases are used, delivery of 80% planned features most releases.
    • No escaped defects.
    • No blaming of an individual for failed stories, or of other teams for failed epics.
  • All individuals assigned to teams or programs using FuSS in any role will try the system as described in this site until they are hitting the Agile Performance Standards.
    Exception: Current Scrum teams with stable velocities and able to hit the standards do not have to make any other team-level changes to implement FuSS release planning.
  • Most individuals will be assigned to FuSS projects full-time, except for some Guidance Roles identified below.
  • Teams will be:
    • Cross-functional and full stack in almost all cases.
    • Stable, meaning:
      • Managers cannot assign a worker to another team, even temporarily, without their Scrum team’s permission.
      • When members are done with the current project, new work will be moved to them as a team rather than breaking up and re-forming teams to match the work.
    • Preferably co-located, and no more than three time zones apart.
      Note: People in Guidance Roles other than the PO and Facilitator can be assigned part time, and be more distant if they agree to work early or late hours. I’ve been in meetings starting as early as 5:30 a.m. my time, as late (early?) as 1:30 a.m., and everything in between.
  • Work cannot be requested or accepted outside of the FuSS planning processes, even by or from direct supervisors, unless it is a true emergency.

By a “true” emergency, I mean health or safety issues; a customer having critical issues with your product; a manufacturing plant unable to do work; and so on. Helping out another manager or getting data for a report you knew about prior to the team’s sprint do not constitute emergencies. The supervisors can still make the request, but should understand that sprint stories will come first. FuSS includes techniques allowing for less-critical nonsprint work to get done without impacting the sprint.

Hopefully your leader’s span of control also includes the unit’s Human Resources and Information Technology functions, so the leader can drive the following agreements as well. At least he or she can try to negotiate these with their bosses:

  • HR:
    • Understands that a small number of people may file formal complaints about the change process.
    • Is prepared to help managers move or remove people who cannot make the switch, or whose jobs become unnecessary.
  • IT agrees you may use any software tool you choose to track the work (per “Choose a Tracker”), providing:
    • Your organization will pay for it.
    • It meets company security policies.
    • IT will not be required to support it beyond integrations to existing tools.

Only you can decide whether to proceed with the effort if upper managers “cherry pick” which of the prerequisites to follow. I refuse to, and have lost a number of contracts because of it, happily: I am willing to pay for less stress, in a sense, by not setting myself up to fail. Success is not impossible without all of them. It’s just less likely, harder to achieve, and not worth the pain in my personal equation.

Trying the System

Until you are running Full Stack Scrum smoothly and hitting the Agile Performance Standards consistently, I strongly urge you to follow the steps exactly as shown. Learn how to ride the bike before you start doing fancy tricks! As the Agile Practice Guide says, “adopt a formal agile approach, intentionally designed and proven to achieve desired results. Then take the time to learn and understand the agile approaches before changing or tailoring them. Premature and haphazard tailoring can minimize the effects of the approach and thus limit benefits.”

Continuing the vehicle metaphor, try all the team-level steps before you start dropping parts from it. Like any machine, its parts are interlocking, each serving a specific purpose that supports other parts. You would not buy a new car, open the hood, and start ripping out parts you don’t like the looks of. So don’t remove parts from whatever system you try until you find out what they do. Every time someone has said to me, “Scrum didn’t work for us,” within a few questions I have been able to point out the problem was not Scrum, but the partial implementation of Scrum. (Earlier in my career, I had the exact same experience regarding self-directed work teams!) One of the lessons Primavera Systems drew from its conversion to Agile was, “There aren’t many rules in Scrum, but you need to adhere to the ones that exist.”[5]

Yes, self-organizing teams outperform expert-directed teams. However, that is when comparing similar, mature teams in similar environments. Plenty of self-directed teams fail, and in my experience the top reason is that they are improperly formed. You cannot just say, “Poof, you’re a self-directed team,” and expect members to rapidly improve productivity by magic. The players on every championship sports team first learned to perform the sport using fundamental skills and patterns of interactions (“plays”) mandated by a coach.

I relate this to Situational Leadership, the method popularized by management maven Ken Blanchard. He and his co-creators drew the progression of a new employee on a four-quadrant grid based on two axes, “Leadership Style” and “Maturity.” A new employee needs a lot of direction from the manager, since she knows nothing of the company, its processes, its customers, or her specific tasks. But she doesn’t need a lot of emotional support because she’s excited about her new job. As the reality of the job starts to hit, she still needs direction, but now also needs some emotional support added to the manager’s Leadership Style to deal with the negatives of any new workplace and the frustrations of getting up to speed. After she matures more in the job, she no longer needs as much direction but continues to need support to assure her she is doing well as she becomes more independent. Finally, though, she is both fully competent and therefore confident, so she no longer needs much direction or support.

In my experience, a self-organizing team is such a new experience for most people, it goes through the same cycle. This kind of team needs a formal structure including team rules, role definitions, self-chosen procedures, and so forth—in other words, high direction about how to be a self-organizing team. Do this right, and the conflict many teambuilding consultants mistakenly consider inevitable can be mostly avoided. I know because the SuddenTeams Program accomplished it.

The Agile community recognizes this through a concept Bob mentions that was borrowed from the martial arts:

  1. Shu (Following)—Novice or beginner; narrowly following given practices.
  2. Ha (Detaching):
    • Journeyman; following, but extending, perfecting, occasionally breaking the rules.
    • Mentoring in specific strength area.
  3. Ri (Fluent):
    • Expert; perfecting, to creating your own, practices.
    • Coaching; mentoring.
    • “Sticky” practices.[6]

I have been a martial artist for more than three decades, and certainly followed this path. I spent four years learning one style, tae kwon do, and earning my first black belt. Contrary to common misconception, a black belt is not mastery; I liken it to earning an undergraduate degree. As I moved around the country, I studied with the best instructor in town regardless of style, eventually earning another black belt, and now when fighting I use whatever technique is applicable in the moment, without having to think about it.

Another analogy comes from sports. When a university or professional team hires a head coach, the employer understands it is hiring that coach’s way of doing that sport. Everything from the types of players the coach recruits, to the team culture, to specific plays called during the game, are left to the coach. So, too, is team discipline. As long as the coach adheres to applicable laws, regulations, and ethical codes, he or she is given complete control over how the team goes about trying to win. And the coach is not even expected to win for the first couple of years, until the system is fully in place!

A college basketball coach who was consistently successful for three decades and introduced many innovations to the game, Dean Smith of the University of North Carolina, summed up the “try it” approach perfectly. He said he told his players, “If you do what we ask you to do, the victories will belong to you, and the losses to me.”[7]

As a history buff, I could bring up countless examples about the value of “systems thinking” from science, politics, and warfare. If you aren’t convinced by now, to be blunt, I don’t believe you are going to be successful in driving change in your organization.

Agile Performance Standards

Meeting the Goals of Full Stack Scrum

The FuSS system is founded on four fundamental goals I call the “Agile Performance Standards.” They drive three characteristics that in turn drive customer satisfaction: predictability, quality, and accountability. Deliver the product or service the customer expected, defect-free, when the customer expected it, and they will be happy. A sense of accountability to each other and the customer is the most critical part of building that team “win.”

In the next three sections, I’ll take each of those characteristics and explain the standards. The Agile Performance Standards are the only part of FuSS everyone is agreeing to for the long term. They are the most required of the “Desired Agreements” I will detail further down.

High Predictability

Some Scrum coaches will argue it’s okay to miss one or a few stories each sprint as long as you always deliver a relatively consistent number. Others go further, recommending extra stories as “stretch goals.” Always deliver around 12 stories per sprint, they say, and it is okay or even preferable to put 14 or 15 in each Sprint Plan. (Actually, they would likely talk about story points instead of stories, but the result is the same.)

One problem with that approach is, the customers can never rely on any of those 15 stories being delivered, because they can’t know which of the 15 won’t be. Only promise 12 and almost always deliver 12, and customers now can rely on getting the specific deliverables they are counting on.

A bigger problem is, you lose the power of deadline pressure. When I began working with technical teams in the 1990s, I could not go to a leadership event without hearing about, “Forming, Storming, Norming, and Performing.” These were the phases new teams all go through, everyone said. I believed it, and put it in the first version of SuddenTeams. After continuing my research in the scientific literature, though, I had to admit in the second edition that I was wrong. Those phases came from a 1965 proposed model of team development that seems logical, but does not hold up to the hard evidence. Instead, repeated studies found that we humans get serious about a project halfway through—regardless of the length of the project—and make changes to become more productive or efficient. (The scientists gave it the lyrical term, “punctuated equilibrium.”) And we all know what happens later, when the deadline is looming, and we still aren’t done. How many of you “pulled all-nighters” to get school projects done? Or work projects?

That is the power of the deadline. I said before that prior to Agile, I began training nonproject teams to create continuous improvement projects to harness it. It worked. Scrum leverages that power by giving you a deadline every week or four. But the deadline pressure goes away, and you will not get maximum speed, if you do not hold yourself accountable to delivering everything every iteration.

Hence these two standards:

  • Delivery of 100% of stories committed to the sprint most sprints, at a sustainable pace.
  • If Planning Releases are used, delivery of 80% of planned epics most releases.

The lower number for releases recognizes the realities of longer-term prediction, as discussed related to waterfall. I have achieved 90% in four-month releases, however, so I know that figure is realistic. Lower release predictability is acceptable as long as most epics are delivered, for two reasons described under “The Waterfall Myth.” First, waterfall projects often have far lower than 80% predictability over 90 days, even as late as one month before a release date. Second, the higher transparency of Agile eliminates bad surprises for the customer.

Note that in Full Stack Scrum, nothing prevents a team that promised 12 stories in a sprint from completing 15. If those extra stories get accepted, they can still be demonstrated and delivered. We just don’t promise them, and the extras become what some marketing folks call “delighters.” Of course, if you consistently over-deliver, you should raise the number of stories you commit so your longer-term predictions are more accurate. All this will be covered in detail later.

High Quality

As you read through the “Twelve Principles of Agile,” it becomes clear that a dedication to high quality is critical. You cannot deliver working products every few weeks, satisfy the customer, or maintain a sustainable pace if your product has a lot of defects. Each defect requires backtracking to previous work and labor hours to identify the cause. “If they are controlled and fixed at earlier phases of software development, they save much time and budget,” concluded two scholars after reviewing 12 studies on Agile defect management.[8] This is due to the cost of stopping current development, finding the source of the problem, and retesting after the fix. The labor-hour costs of fixing bugs post-release is significantly higher than preventing them, or finding and fixing them during development.

Two professors who created a Center for Empirically Based Software Engineering reviewed data from various studies to come up with the “Software Defect Reduction Top 10 List” (Boehm & Basili 2001). Among their findings were that:

  • “Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase,” though the “factor for small, noncritical software systems” was closer to 5:1, still a substantial figure.
  • “Current software projects spend about 40 to 50 percent of their effort on avoidable rework.”
  • “About 40 to 50 percent of user programs contain nontrivial defects.”

One study “found that 44 percent of 27 spreadsheet programs produced by experienced spreadsheet developers contained nontrivial defects—mostly errors in spreadsheet formulas. Yet the developers felt confident that they had produced accurate spreadsheets.” Fortunately, eliminating the vast majority of rework does not require a huge investment of time, the list indicates:

  • “About 80 percent of avoidable rework comes from 20 percent of the defects.”
  • “About 90 percent of the downtime comes from, at most, 10 percent of the defects.”
  • “Peer reviews catch 60 percent of the defects.”
  • “Disciplined personal practices can reduce defect introduction rates by up to 75 percent,” especially when coupled with mature team and organizational processes, they add.

Errors that become “escaped defects,” caught by another group in your organization—or worse, the customer—create a sense of urgency bound to disrupt your Sprint Plans and add stress for most people. It also harms the team’s, if not your organization’s, reputation and thus its credibility. If the defects keep getting to the customer, the company’s reputation is harmed and thus the company’s sales. As the manager of a car repair shop I’ve come to trust, Tom Ashley, says, “Find time to do it right, or you will find time to do it again.”

The emphasis of the this standard is to please customers and save your organization money by giving them trouble-free products: “No escaped defects.” Using the techniques described under “Multiple Layers of Quality,” FuSS drives teams to eliminate every defect that could be noticed by customers. Simple in concept, and easier in practice than people think, this means we try not to allow bugs to “escape” the team. In programs requiring system tests of deliverables from different teams, or when those teams work with outputs from others, each team makes every effort to ensure no defects are found by those tests or teams. And everyone works together to ensure the customers and end users find nothing wrong.

High Accountability

Mutual accountability has great value in improving team performance. “Team cohesion,” the level of group identification and mutual accountability among members to each other, has been researched since the 1950s and shown consistently to correlate to higher team productivity and job satisfaction. FuSS provides multiple opportunities at every stage of the sprint cycle for members to raise questions of each other, and expose potential problems while they can still be prevented or fixed. That means everyone on the team has a role to play in ensuring each story is completed within one sprint, whether they work on the story or not. When that doesn’t happen, everyone on the team has a share of the blame.

Scaling the same logic to releases, in FuSS all teams have multiple opportunities to influence the release-level decisions of the other teams. Therefore the teams commit to the decisions together.

At both levels, making clear up front that everyone will share both the glory and the blame encourages higher levels of involvement in decision-making and higher motivation to carry those decisions through. The resulting standard is: “No blaming of an individual for failed stories, or of other teams for failed epics.”

Customer Satisfaction

Given the emphasis in Agile on customer satisfaction, it should seem odd to you that high satisfaction ratings is an optional Agile Performance Standard. I encourage you to develop a standard along those lines, but feel I cannot make a specific suggestion that will translate across organizations the way the four above can. Measurement is the key barrier. You must have a way to objectively and fairly measure satisfaction, with enough potential variation from one period to the next to be meaningful.

Many companies measure end-user satisfaction, of course. You know this from the constant requests for your ratings as a customer, in pop-up Web surveys; e-mails after you make an online purchase; phone system requests after you speak with Customer Service; and links printed on paper receipts.

In the case of a Customer Support team, it is easy to tie these results to the team. Just as important, there are many inputs from a lot of different people, so the numbers can change a lot. Reports from 200 people in a month on a three-point satisfaction scale yields 600 points, so it’s relatively easy to prove improvement. To turn a 90% satisfaction rate (540/600) to a 92% rate, improve your approach such that 10 people give you one extra point. Also, with more raters, personal biases are less of a problem. Even if some of your customers are prejudiced about your nose ring or your gender, you can still find 10 who won’t care. (Or remove the nose ring while at work!)

However, most workers do not directly provide deliverables to large numbers of people, and they are not solely responsible for the “sat score.” (Even Customer Support people can only do so much; if the product they are supporting sucks, they can get low scores despite doing their support duties perfectly.) Most people are in the reverse case where their input is only a small part of a larger output. If your team is responsible for laying water pipes in a new residential neighborhood, the project manager may be the only person you have to please. Here’s hoping he or she isn’t bigoted against the majority race on your team—nothing you do is likely to get a positive satisfaction score. Beyond that, a problem with leaky pipes could have occurred in the design, materials, manufacture, storage, transportation, and/or laying of the pipe. Plus the PM has often moved on by the time problems arise, and the general contractor may never know who was at fault!

That scenario also raises the issue of delays in measurement. Say customers are really unhappy with one feature on a new oven design. You could potentially tie that to the team who designed that feature. But there may be a gap of years from the time they developed it to the time reports come rolling in. And again, the team members don’t have full control: Maybe they gave the product manager exactly what he or she wanted.

A more logical approach seems to be having your internal Customer supply the ratings. Now you are back to the low-variability issue, however. One person using a 10-point scale is likely to only go up or down by a point or two per period, but that jump would equal a substantial 10%−20% change. Furthermore, they will be influenced by the desire to keep a good working relationship with you, and can’t be anonymous, so they might not give honest ratings. Even if you throw in some other stakeholders, that doesn’t help much. With one or a few raters, bias becomes a factor again, and the ratings can be strongly impacted by irrational demands. I have been forced to work with more than one product or sales manager who made impossible promises to their customers without consulting the R&D teams, and then got angry when the teams could not deliver on those promises.

In short, I have rarely come across cases outside of Customer Support where meaningful, fair customer satisfaction ratings could be gathered and tied to specific teams, with results that were mostly under the teams’ control. The best way around this is to get satisfaction scores for the entire enterprise and apply them to all teams. Every team in your organization impacts the satisfaction of the customers. Imagine how delayed your projects would get if the janitorial staff wasn’t on top of things! Similar to this approach but more specific, on projects with external users, you could gather results on the deliverables and apply them to everyone on the project. That is, if only 73% of customers like the oven from the example above, everyone from the top managers who signed off on the project to the product managers to R&D to Manufacturing has room to improve.

Without knowing a lot of details about your organization, I can’t tell you how best to measure satisfaction fairly, through there probably is a way. If you can figure it out, I’m all for it: Create an Agile Performance Standard based on customer satisfaction and add that to the list.

Otherwise, in effect Agile treats customer satisfaction as binary: Either you are satisfying your Customer and stakeholders, or you aren’t. Assuming they are fully engaged as described on this site, you will know. And if they aren’t fully engaged, their lack of satisfaction is at least partially their fault.

Gain Buy-in

Be the Change Agent

You are reading this site because you are interested in making a positive change in your organization. You would not be wasting valuable minutes of your life on it otherwise. There are significant problems in your company or non-profit… government agency or religious community… start-up or school, that you think FuSS might ease. And yes, they are problems. Despite the double-speak of business jargon (“Opportunities!” “Challenges!”), these behaviors are causing emotional pain. I don’t care whether the issue is lack of revenues, customer complaints, falling profits, internal conflicts, or a cluster of these. The behaviors need to change, and you realize you might have to be the agent of that change.

For your sake, I hope you are the top executive of the organization. That will make your mission much easier. According to a Harvard Business School report, “Agile succeeds best as an executive-led initiative that includes well-thought out strategies to effect foundational change across an organization.”[9] You still need to gain buy-in from the people who report to you, for the reasons discussed. But the most difficult person to sell is already sold—the top executive. More importantly, if you adopt the practices of FuSS, it eliminates both the interface issues between the lower and upper levels of the company and a lot of the resistance below. Rightly or wrongly, the psychology of human hierarchies is that many people go along with what you decide if they believe it is going to stick. Using Agile yourself proves this isn’t just the latest management fad.[10]

Unless you are the head of the entire enterprise, you may still need to persuade others. For example, as P&L leader of one relatively independent unit within a larger corporation, you would need your boss to agree not to interfere. The HR Department in that scenario is probably a separate entity and must be prepared to deal with complaints brought directly to it. The IT Department may resist your choice of tracker even though you are willing to fund it from your own budget.

Failure to take the time for this effort is the root cause of the interface conflicts I call, “Scrum pox.” I steal the term from rugby: Males involved in close contact with opposing players within a scrum will grow enough facial hair to cause irritation, potentially leading to a rash that goes by that name. In the business context, people who do not understand, and/or feel threatened by Agile, will fight it. Some of the conflict will be public and can get harsh. They will also crawl into the ears of executives, peers, and direct reports and tell them “Agile isn’t working” at every opportunity. Difficult to quell after it has started, Scrum pox is easier to prevent. Smooth out the bristles before the game starts.

Usually, though, the “Agilista Zero” is someone far down the ladder from the Big Boss. You are going to have to evangelize up, down, and sideways, over multiple verticals and horizontals in larger enterprises. This takes a lot of persuading. Fortunately for you, I wrote a master’s thesis on persuasion!

Recipe for Persuasion

Improving Your Odds

For an earlier career, I went through a different set of hundreds of sources, this time on persuasion. I define persuasion as the attempt to change someone’s attitude or behavior through facts and logic. Based on that research, I created a class I have delivered in numerous forums on how to persuade within an organization. There is no “silver bullet” for persuading everyone. Otherwise, everyone would buy everything in every commercial! So this can’t guarantee you will persuade people to try Full Stack Scrum. However, following it will greatly increase your chances.

The bottom line to effective persuasion is proving your proposal will benefit your audience. They don’t care that you believe in it; they want to know how it will benefit them personally. My “Recipe for Persuasion” walks you through the steps, modified here for creating a presentation to propose FuSS or the aspects relevant to you. You can download our draft proposal slides and customize it to save time.

Tie Facts to Needs

1) Choose Your Argument:
  1. Read the rest of this site so you have a complete view of the system.
    Tip: Do so even if you are only trying to convert one team, because issues discussed there may pose problems for your team or be raised as objections during your presentation.
  2. Write a list of the issues your organization is facing that you think FuSS would address.
  3. To guide your work, write a single sentence (your “proposal”) that states:
    1. The key issue(s).
    2. Why you believe FuSS is a solution to try.
2) Aim at Your Target:
  1. You cannot change everybody’s mind, so target those who are interested in the relevant problems and seem open to discussing what to do, even if they have their own suggestions.
  2. If you are only trying to influence one person, target the subpersonality or interests that may be open to your argument.
  3. Identify their needs:
    1. Figure out what motivates the people or person in your target audience to do what they do.
    2. Write down the motives or needs likely to be most important to the target audience and prioritize them.

Example Needs:

  • Company or Team Needs:
    • Higher sales.
    • Higher productivity.
    • Lower costs.
    • Higher quality.
    • Attraction or retention of good employees.
    • Better morale.
  • Personal Needs:
    • Stature in the company.
    • Being liked.
    • Being respected.
    • Job security.
    • Reduced work stress.
    • More money.

Warning: Be careful with fear appeals—people try to resolve fear-based cognitive dissonance by rejecting the message.

3) Gather facts about the relevant problems:

For persuasion, these can include:

  • Physical evidence.
  • Statistics from respectable sources.
  • Opinions from respectable sources.
  • Examples or illustrations, such as case studies.
  • Presumptions, meaning statements not provable but accepted as fact.

Warning: Do not ignore facts that argue against the switch to FuSS.

4) Create a benefits list:
  1. Combine the Step 4 motives list with the “Benefits of Agile and Scrum” to come up with a list of benefits FuSS would provide to your target audience.
    Note: Benefits are not the features of FuSS, but how those features address the needs you identified.
  2. Select two or three benefits relating to the most fundamental needs.
  3. Decide on the most persuasive benefit, or a theme encompassing all (in advertising terms, the “Unique Selling Proposition” or USP).
5) Create an opening slide that:
  1. States the problems in a few words.
  2. States your proposal to adopt Full Stack Scrum.
  3. States your USP.
6) Create slides that:
  • Logically string together the evidence for using FuSS.
  • Relate the proposal to the target’s needs.
  • Acknowledge and refute alternate positions or facts as soon as knowledgeable people are likely to think of them.
  • Subtly repeat the proposal, strongest evidence, and deepest target motives.
  • Use personal language including “I” and “you,” not third-person (use “I believe…” rather than, “It is believed…”).
  • Use humor carefully.
  • Cover the agreements stakeholder groups must support (per “Desired Agreements”).
7) Create a closing slide that:
  1. Restates your proposal, the most motivating need, how FuSS fills that need, and, possibly, the best evidence.
  2. States clearly what you want the audience to do.
  3. Provides the information needed to take that action.
Important points to remember:
  • Keep your presentation short to maintain attention.
  • Use at least 18-point text.
  • Use words you are certain your audience will understand, based on education levels and experience in your industry and company.
  • If you have to mention potential threats, take away the resulting fears quickly.
  • If possible, do a practice run with someone and update accordingly.
  • Don’t forget to run spell-check!

Take Action

This site is not just about Agile at scale: It is a “how-to” manual for implementing FuSS. Unless you are doing an initial read-through of the entire site, the time for action has come! The change agent—you or an employee you designate—will be doing the first set of steps to gain buy-in. They are linked below and also from the Steps page for later reference.


  1. Obtain Permission to Evangelize
  2. Determine Next Steps
  3. Evangelize FuSS
  4. Obtain Team-Level Support
  5. Begin Implementation

System | ← The Agile Difference | → The Sprint Process

[1] Galen 2014.

[2] Serrador & Pinto 2015.

[3] AMA 2007.

[4] Bottani 2010; the surveys were collected in 2007.

[5] Schatz & Abdelshafi 2005.

[6] Simplilearn Solutions 2013.

[7] Smith 1999.

[8] Noor & Fahad Khan 2014.

[9] Harvard Business School Publishing Services 2015.

[10] See “Isn’t Agile just another management fad?”

Share this page