Contents

• The Pillars of Radical agile
• The Next Step in Agile Evolution
• You Don’t Need a Framework to be Agile
• How this Website is Different
• Environmental Change for Maximum Impact

---

The Pillars of Radical agile

The Full Scale agile™ home page highlights the concepts that differentiate my approach to agility from others. These concepts are “radical” only in the sense that most Agile coaches seem ignorant of the history and science underlying the principles of the Agile Manifesto. Allow me to explain:

• Agile was nothing new. All of the principles of the 2001 Agile Manifesto had been identified as improving performance decades earlier. By making “Agile” out to be something new as of then, or so unusual you can’t do it on your own, Agile experts increase their profits. But they also increase resistance to agility as “just a fad” that has seen its day.
• Agility applies to all work. The principles of empowerment, iterative delivery, high quality, cross-training, and short planning cycles underlying all agile approaches would improve efficiency and satisfaction in most work situations.
• Don’t train to be agile; practice it. Agility involves changing how a group of individuals coordinate their actions, like team sports, which are not learned through lectures. A multi-day training on any agile/Agile method is a waste of time and money.
• Don’t hire agile experts; train them. Agile approaches can eliminate the need for traditional team leaders, project managers, and middle managers, causing resistance when you bring in a squad of outsiders. Bring in one coach, and let them train existing personnel to adopt agile roles, principles, and processes. However…
• You don’t need a framework to be agile. Methods like Scrum and Crystal were created by people just like you, and self-directed work teams designing their own processes meet the principles of agility without adopting pre-packaged systems. But if you use one…
• Adopt, then adapt—not the other way around. The Association of Change Management Professionals; Project Management Institute; Six Sigma; and the most-cited book on organizational change (Leading Change) all say you should follow the recipe for the change you are making before changing the ingredients.
• A team with a full-time organizer is not “self-organizing.” If a group has someone designated as the single person who organizes their work, research on group psychology and social power proves group members will defer to them—and the organizer will expect that to some degree. There is no psychologically valid difference between “self-organizing,” “self-managing,” and “self-directing” teams.
• You cannot predict the future, so don’t waste time trying. The Project Management Body of Knowledge does not say project plans are accurate predictions of the future. Nor are meeting initial budget, schedule, and scope targets its measures of project success (see “The Waterfall Myth“).
• An agile manager must give up control. Decades of research on empowerment; numerous case studies; hundreds of “management guru” books; and the principles of the Agile Manifesto agree that “control” of one or thousands of employees is impossible, and attempts at it harm performance. Agility requires letting go of social power.

To clarify my terms:

• lower-case-“a” agile is the current term for having human/technical systems that allow your organization to rapidly adjust to changing customer demands and market environments. Long before the Agile Manifesto was written, these systems emphasized: worker empowerment, flat organizations, decentralized processes, and (only) short-term iterative planning.
• capital-“A” Agile is a set of frameworks or methods intended to help users become more agile based on the principles of the Agile Manifesto, some more evidence-based than others.
• The Agile Industrial Complex comprises associations, companies and individuals who try to maximize revenues off of Agile, and thus will not help you become agile as cheaply as possible.[i]

The Next Step in Agile Evolution

In my dream Agile world, you would have one small cross-functional team of full-time members whose time was dedicated 100% to doing one project for one customer who was engaged nearly daily in the process. You would have a contract that simply said the customer would pay a flat rate per month or sprint until the customer was happy with the product. Upper management would leave you alone to do your thing and earn the company its gazillions of dollars/euros/yen unless the customer complained, which she wouldn’t, because she took the opportunity to influence the progress by attending some team meetings (in Scrum, the backlog and the Demonstration Ceremonies). And because the team delivers a defect-free working increment of the product every iteration, pausing afterward to ask the customer for input.

Excuse me while I pinch myself… yeah, I was dreaming. Almost every team I’ve dealt with had multiple responsibilities and/or projects with limited resources and/or schedules, with their upper managers and/or customers demanding to know, “When will it be done?” Unfortunately, the evidence is powerful and consistent that no human can predict what will be delivered when at a specific cost. This reality helped shift the focus in Agile project management from that so-called “Triple Constraint” or “Iron Triangle” to simply satisfying the customer. The methods now lumped together under the term “Agile” were not new ways of managing work: They were practical methods for implementing better ways long known but mostly ignored.

As has happened repeatedly to prevent the evolution of management practice, the Agile Evolution has been interrupted by moneyed interests. U.S. President Dwight Eisenhower, once the most powerful general in human history,[1] warned about connecting the goals of a society with the profit motive. “In the councils of government, we must guard against the acquisition of unwarranted influence, whether sought or unsought, by the military industrial complex,” he said in 1961. “The potential for the disastrous rise of misplaced power exists and will persist.”[2]

As I first wrote in 2017, I believe an “Agile Industrial Complex” has developed undue influence over the business world by telling executives what they want to hear, subverting agility. By pushing fictions like “scaling Agile is hard”; that Agile can provide long-term date predictability; that drop-in consulting can create lasting change; and that each team needs a professional Scrum Master, an entire industry has found a way to earn a living. In the process it does some good, but at the cost of millions of dollars of unnecessary spending on seminars, onsite trainings, certifications, and unneeded Scrum Masters. Some babies of the complex, such as the Scaled Agile Framework (SAFe), are partially waterfall in disguise—attempts to make Agile palatable to top executives who don’t want to admit they cannot predict (much less control) the future. Other fully Agile approaches like Large Scale Scrum (LeSS) are proprietary, only providing a certain amount of information before you have to buy something. Or they are specific to software, like Nexus.[3]

Agile was supposed to be a revolution in the management of new product development. Instead, some managers and consultants more interested in keeping their jobs than changing the world have sold out by trying to create methods for marrying two fundamentally opposed concepts. A job ad for an Agile Project Manager that seeks candidates with both Agile experience and a track record of meeting Triple Constraint commitments completely misses the point of Agile. If you want dates, you have to stick to waterfall. And the first set won’t be right most of the time.

Full Scale agile (FuSca™) is a nonproprietary alternative to other methods of Agile-at-scale. It is modeled on the concept of “open source” software, with all of the background information, steps, and tools freely available on this site. I have no intention of creating certifications, high-cost seminars, conferences, or training events outside of my ongoing coaching career. Other than meetings to introduce the concepts, I refuse to be a “seagull” consultant, flying in to drop my poop and then flying off to get more fish until I return with more droppings. Every time I have been hired into a company after seagulls were there, I spent much of my time breaking the bad habits those consultants allowed to develop, either through unscientific information or by not being there for mid-course correction.

FuSca rejects compromises that go against scientific fact. If I don’t convince anyone else to use it, I don’t care. I will have spoken up for reality in a way that helps me sleep at night after a day spent changing an enterprise. It has already hurt my career because I refuse to implement waterfall-like methods or take a job as a Scrum Master of a single team (except as part of larger coaching duties). And I’m quite comfortable with that. I am fighting for a return to ideals of empowerment and sacrifice to make things better for everyone in the enterprise. Viva la Evolución!

You Don’t Need a Framework to be Agile

Any systematic approach to managing work is better than no system. And any of the existing Agile frameworks are better than a “waterfall” method where Agile is more appropriate, the majority of cases. But you don’t need Crystal or SAFe or even Full Scale agile to be agile.

At the same time Scrum was being developed, I began training “self-directed work teams” (SDWTs) that met the principles of the Agile Manifesto years before it was written. All were also truly self-organizing: They created their own team rules and procedures, and had no team leaders.

A pioneer of a popular Agile method has described how various methods now called “Agile” co-evolved in the early days.[a] Obviously, all of the current methods had to be created by somebody! “The New New Product Development Game,” a groundbreaking report in Harvard Business Review in 1986, described highly empowered and successful product development groups in which executives provided marching orders and money and little else.[b]

My point is that any line manager could easily implement an Agile mindset simply by turning their team into an SDWT. Adding in the scientific evidence that decentralized firms based on small empowered groups improve financial performance, and the best approach for upper managers to create an Agile organization might seem the most radical:

1. Decide on a specific need you want to fill, and how much you can spend on a workable design or minimal sellable product.
2. Choose an initial set of people with all the business and technical skills needed to produce that product or service, and strip them of their job titles.
3. Tell them to follow the Agile Manifesto, replacing the word “software” with their product type if it isn’t software.
4. Exempt them from all organizational policies not required by law, regulations, or ethics.
5. Put them in an offsite conference center with skilled big-meeting facilitators to self-organize.

That’s it. The rest, including the schedule, is up to the people. Read the “New New” article to see how this works out (or “Evidence of Success” for other examples).

I spent months writing up this site for do-it-yourselfers, yet the steps above are the way I wish everyone would implement Agile. The goal is complete freedom for all programs to meet their customers’ needs as they see fit. They might choose to implement an initially prescriptive methodology like FuSca, but wouldn’t have to.

Unfortunately, few executives appear willing to implement this approach, despite the data in its favor. My attempts over 14 years when I was a teamwork consultant to get managers to succeed by giving up control met with limited success. One objection I still hear today is that this would show the company is “out of control.” In a sense that is true! But again, the best evidence says a lack of centralized control will improve a firm’s financial performance.

Nonetheless, these executives feel more comfortable buying a package other executives have bought, though created by strangers, than trusting their own workers to create something workable. In the old “make or buy” dilemma, they feel safer buying. I don’t mean this to sound as critical as it probably does. There are a host of reasons why good managers often cannot adopt radical empowerment even when they want to.

That being the case, the question then becomes, what is the Lean-est way to implement Agile quickly that eventually maximizes team and worker empowerment for the benefit of all stakeholders? An approach like Full Scale agile is my psychology-based answer:

1. Use an organizational culture change method to build consensus behind one pre-built system.
2. Get agreement to try the system completely, with all its parts, until everyone understands how they fit together
3. Then allow process experimentation as long as performance standards are met.

This strategy provides managers a greater sense of confidence and oversight, and balances efficiency with empowerment. My hope is that once a program or team proves itself through this disciplined means, managers will free people to maximize both.

However, in the spirit of 1960s counterculture figure Abbie Hoffman, who wrote a book called Steal this Book, I say: “Don’t use my Agile framework!” Create your own. Only if you aren’t allowed to, or need something workable right away, should you implement the FuSca system.

How this Website is Different

Reasons to Write

An author on the American Civil War suggested that you weren’t a Civil War “buff” until you filled six feet of shelving with books on the topic. There are easily enough books on Agile and its various components to become an “Agile buff” by that standard. Given the amount of time required to write a book-length Web site, it might seem a insane for me to decide it was needed. I have written several books and know the pain well. I would not have tackled this topic if I didn’t think there was a true need. Let me run through the reasons to help you decide whether you need to read it!

As a veteran trainer and coach, I believe most books and sites on Agile fall short in the level of detail needed for you to put their theories into practice. They also tend to stop at the tactical level, focusing on a team or set of teams. In some cases they cover the strategic needs without the tactical details. Some cover specific techniques. This site, in contrast, is a do-it-yourself manual for leading an organization through the transition from traditional (“waterfall”) project management—or no project management—to using the Agile methods called Scrum or Kanban, or creating your own system, at the team, cross-team and enterprise levels.

You can find hundreds of books on Kanban and/or Scrum. Despite all those, I keep getting hired to help teams struggling with the basics. I have a long history of hands-on work to improve business team performance, and wrote a DIY book for better teamwork. So I thought maybe a step-by-step guide that captures how I reliably achieve measurable successes would help. This is is a cookbook.

Humans struggle to translate abstract information into how to handle a given situation in a given moment. Sending people to a class or handing them a general book on the topic and thinking that is sufficient to change behavior is a mistake. Scientific evidence on adult learning makes clear that training without persistent follow-up provides little or no long-term behavior change. This site incorporates that evidence using several techniques:

• Step-by-step instructions for implementing the information, to encourage “learning by doing.”
• A chronology that drives mastery of lower-level skills before ramping up to more complex levels.
• Prominent use of a common vocabulary of clearly defined terms which facilitate easy discussion—going against my wonderful writing instructors, I capitalize any used an atypical way in Full Scale agile to reinforce consistent use.

This site is not intended to be a sit-down read for most users, though I suggest the person leading the transition read it through first. Instead it is a guide to action, just like books at home improvement stores that show you how to build your own cabinets. It includes plenty of background to explain what you will be doing and why. But the key is the section of detailed steps, which you must actually do to implement the system!

Scaling Up the Knowledge

After the draft was under way, I realized there was an even greater need for help with scaling and supporting Agile, so the emphasis changed. I could have written a site exclusively about the “scaled” part of Full Scale agile. But I have rarely walked into a company that said it was Agile and found its chosen method being applied in a disciplined and systematic manner, even within a single team. I once heard a coach in the National Hockey League say that you could tell which teams had a “system” within 10 minutes of watching video of their play. His implication? Teams that created and visibly implemented a systematic way of doing things across players were more likely to win. Unless business teams are willing to do that, FuSca is not going to work.

Furthermore, parts of the scaling method I present require techniques experienced Agile teams may not be using. So I chose the content for this site with four audiences in mind:

• Individual teams not using agile approaches, or not getting the results they want from Agile.
• Groups of successful agile teams that must coordinate their output.
• Organizations that create new products or services, of any type, and are experiencing problems with those deliverables, including startups.
• Organizations using Agile, but not getting the benefits they were expecting at the team and/or release levels.

Elsewhere the site explores various data-driven trends in corporate governance that together support agility for maximum benefit to customers, employees, and shareholders. If you are debating the switch, it can help you decide whether the benefits are worth the effort for your organization. Speaking as a certified project manager, I think the answer is “yes” for any organization doing complex work with significant unknowns—which applies to parts, at least, of every organization.

Although I words like “corporate” and “company” at times, the Full Scale agile system is intended for any kind of enterprise. Many books on Agile focus on software, and there is a separate body of literature on manufacturing “agility.” While addressing the reality that most readers will probably be in software, I regularly address scenarios faced by nonprofits, creators of tangible products (“hardware”), continuous improvement teams, support teams, and more.

My motives for writing the site differ from most. All of the books I have seen published since the early ones on Agile are by people with something to sell you. No doubt the authors also have altruistic motives. However, they are not going to say something in their books going against what they are trying to sell you, no matter how much scientific evidence there is for a contrary position. I’ll rant more about this further down.

A Coach at No Cost

For those who cannot afford a full-time coach, my intent is to fill that coaching gap as best I can in printed form. I have poured my two decades of team coaching experience into this site in hopes it will be the next best thing to having a live coach there to help you. Because you can refer to it over and over and specific steps are included, you should be able to stay on course. Indeed, another motivation for writing this was so I didn’t have to keep writing the system up with each new contract I took. Those write-ups proved invaluable in evangelizing, teaching, and supporting adoption of the system.

That leads to the biggest difference from other systems for Agile-at-scale: Full Scale agile™ is free. Specifically, in legal terms it is modeled on “open source” software. You are free to copy, print, and modify any materials and downloads on the Web site, as long as you attribute Jim Morgan as the author of the original content and this site as the source. (If you print something out to hand out, the license requires you to add to the last page or include a back cover page with these words: “Based on content available for free at fullscaleagile.com.”) See the “Legal Information” page for the fine print.

For this site, I extended the teamwork research described earlier for The SuddenTeams Program to peer-reviewed content specific to agile/Agile, Kanban, and Scrum (see “Bibliographies“). Much of what you read about Agile is not objectively verified, and often amounts to different interpretations of the same sources, plus the author’s personal experiences within specific circumstances. “The literature on scaling agile has been dominated by consultants proposing a number of frameworks… developed in recent years to facilitate the use of agile principles in larger projects,” a 2017 literature review concluded, the year I wrote the first version of this site.[5] The biggest lesson of my research into teamwork psychology was that most of what “teambuilders” sell is a waste of money bordering on fraud. The scientific method prevents you from throwing away time and money on unproven theories, by testing those theories in ways that isolate the real causes of change and minimize self-deception caused by our shared, subconscious, human biases.

There was effectively no scientifically valid research on Scrum as late as 2008,[6] and no overarching theories to guide Agile study by 2012.[7] In research literature terms, ten years of studies is nothing. As recently as 2015 two researchers noted, “To date, the majority of research examining the (Agile) methodology’s usefulness has been anecdotal, based on small-sample case studies, or research limited by sample size, industry or geography.”[8] In well-researched topics, many, if not most, books on a university library shelf will be written by scientists or scholars. At my nearest engineering school, North Carolina State University, as of 2017 not one book was. They were all anecdotal, written by practitioners. My approach to Agile applies the lessons of science regarding teamwork and Agile so that organizations are not repeating mistakes others have made in making the change.

For example, most companies and teams get stuck during Agile transitions due to inadequate managerial support. Typically they end up blaming Agile when the real problem was refusal by upper managers to change their ways plus, related to that, partial implementation of the chosen Agile. I don’t blame the teams, but rather organizations that think Agile is something line workers do so they meet deadlines better. That is quite simply false. Companies who want that should implement a more disciplined approach to waterfall project management. I have never visited a company that appeared to be using Project Management Institute concepts in a systematic way.

I also do not hide behind caveats consultants and authors often make about there being no such thing as “best practices.” Therefore, they say, they aren’t going to require you to do anything specific. There are practices that will work with any group of humans, because they are based on human psychology. I have proven this over and over in my work with a huge variety of teams. The fact there may be alternatives that work just as well doesn’t matter, at least initially. The practices I teach via Full Scale agile will help any organization having delivery problems implement a systematic approach to work management that will improve performance. That done, I encourage you to research and experiment with alternatives one piece at a time after this one is in place. This advice applies to any system you choose to implement, even if not FuSca.

If managers do not change their own ways of managing or insist that teams try the system fully, this system will fail badly. So will any other approach to improving performance. For managers who do change, this site can be your coach.

By definition, the self-discipline is up to you!

Environmental Change for Maximum Impact

As you may have figured out by now, I am a dogmatic realist. I enjoy watching science fiction and Harry Potter movies, but I don’t run my life based on wishes. So long as an action is legal and ethical, I only care about what works. And I base that decision not solely on what I have experienced, which could be a result of a specific set of circumstances, or due to reasons other than those I noticed. Instead, I actively seek out objective, measurable results that can only be due to a specific change, and then try out that change. When the change obtains the same result in multiple settings, it makes it into my teamwork toolbox.

People who manage their organizations based on what they wish were true, or what they learned from their managers years ago, often cause emotional harm to their employees. They also harm their companies financially, it turns out. Though you must be careful in applying case study results to a different situation, a 2011 report based on studies of 24 companies backed up academic findings. Most of those companies survived the Great Recession without layoffs, and all had the kind of financial success any business owner wants. Three traits the profiled companies had in common were low turnover rates, “high customer satisfaction rates, and strong year-to-year customer retention.”[9] Each company emphasized the approach to management reflected throughout this site, focused on values-based, transparent processes that emphasize employee empowerment and well-being. Critically, this approach infused each company in its entirety. Everyone from the top leaders down hitch themselves to the same philosophical wagon, even in an agile enterprise of 3,500 workers in one case from the report.

A key marker of agile manufacturing firms in a European survey was an emphasis on the “employees’ role and competency in the company, in terms of development/training, enhancement, flexibility, (and) satisfaction, which are found to be related to information provided to employees.”[10] That’s another way of saying self-organization, transparency, openness to change, and cross-training, all themes in FuSca.

Agile is a philosophy of work management that can apply to general management because it aligns so well with the realities of human beings working in groups. Though practitioners trying to make a sale will tell you otherwise, I believe the idea you can maximize the benefits of agility in a waterfall company is wishful thinking. Try to drive a team-oriented mentality when compensation is based on ratings of individual behaviors, and you create cognitive dissonance. Say “we embrace change” when your manager’s bonuses are based on hitting financial goals that only change once a year, and your definition of “we” needs to be narrowed. Emphasize quality over hitting dates when Sales is promising dates “no matter what,” and yelling matches are quite likely. How much productivity will you lose if you sit around waiting for an Architectural Runway when the company’s “gate process” insists architects deliver a complete specification before the development starts? In these cases and more, conflicts between agile- and non-agile elements will consistently sap your agile teams of productive time, slow projects down, make employees unhappy, and dissatisfy customers through improperly set expectations (and in extreme cases, flat-out lies).

Although a small percentage of projects lend themselves to waterfall equally well as agile, an enterprise facing rapid change in the market is more likely to attain maximum long-term success if it adopts a reality driven “agile management” philosophy as a whole. To out-compete, you have to do something different than your competitors do.

← Why FuSca? | ↑ About FuSca | → Agile 101

---

Full references are in the Agility Bibliography.

[1] He was the Supreme Commander of Allied forces in World War II.

[2] http://avalon.law.yale.edu/20th_century/eisenhower001.asp.

[3] (Removed.)

[4] First a proprietary training manual, then published as a profitable book, it became a free hypertext because it required a level of support I no longer wished to provide. Most of the content now is incorporated into this site as “Self-Directed agile.

[5] Hobbs & Petit 2017.

[6] Dybå & Dingsøyr 2008.

[7] Dingsøyra, Nerurc, Balijepally & Moea 2012.

[8] Serrador & Pinto 2015.

[9] Broughton 2011.

[10] Bottani 2010; numbering removed.

[a] Rigby, Sutherland & Takeuchi 2016.

[b] Takeuchi & Nonaka 1986.

[i] Although I came up with the term independently sometime prior to 2017, when I put it on the first version of this site, I do not claim to have coined it first (so to speak). Indeed, a Web search suggests it first appeared there at least as early as 2014.