Contents
The Semi-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 FuSca™ transformation will be. Few companies will make all the changes required to maximize agility, which eliminate the usual pyramid structure. In the ideal setting within a standard hierarchy:
- 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 Team Guide and Facilitator (see “Teams in Charge“).
- 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; only a quarter ahead (at most); 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.
Evangelize the Change
Organizational culture change has been studied for decades. The process is well documented and repeatable. There is a professional organization and robust certification related to it.
Almost nobody uses it.
I wrote the first paper on using this process for agile transformation in 2018. You won’t be surprised to hear my strong recommendation you follow the transformation section of this site based on that paper to evangelize the change to both the people who will be enacting an Agile method and stakeholder groups.
Many people are more likely to give it a solid try if they don’t feel forced into the approach. 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 wrote earlier, 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. FuSca shortcuts the transition safely and limits potential conflict by handing the team a proven structure and process to try, regardless of which process on the site that is.
Downsides for Some
One Meaning of Lean
An open secret among Agile advocates is that some individuals will be harmed by adoption of agility across an enterprise. Many consultants will soft-pedal this to make a sale, but I won’t: 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 culture change efforts. I watched helplessly as a FuSca 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 FuSca advocates from addressing that interference directly with the executives.
If you seek buy-in on Self-Directed agile or Scrum, and a team member does not want to try those, decide as a team whether that makes agile 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. The best solution is to train others in that skill set, trade that person to another team, and then tackle agility. Otherwise that person will make Scrum difficult and self-direction impossible. 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 the new method 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 an agile team and use a different method of formal project management. As I detailed earlier, the choice should not be between “doing what we’ve always done” and agile. Or you can remove that person from the team and transfer in or hire someone open to agility.
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 team shines! Meanwhile, you can be doing all the things you wished you had time for in the past. Here are some possibilities:
- Process expert
- Quality champion
- Technical consultant
- Special projects champion
- Teaming champion
- Customer champion
- Learner (or researcher)
- Systems thinker
FuSca 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 agility. 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 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 Triple Constraint, “stakeholder satisfaction, and perception of overall project performance.” Critically, the levels of technical complexity and team experience did not change those results.[1] 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 structural barriers or lack of experience with agile methods, not because those methods cannot work in those industries.
The American Management Association[2] 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 research and 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[3] 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 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 agility.
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 unless you can change their attitudes. 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 agility.
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. “Agile Across the 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!
↑ System | ← Decide to Change | → Define the Choice
Full references are in the Agility Bibliography.
[1] Serrador & Pinto 2015.
[2] AMA 2007.
[3] Bottani 2010; the surveys were collected in 2007.