Full Stack Philosophy


The Next Step in the Agile Revolution

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 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 every sprint through the backlog and the Demos. 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 “Iron Triangle” to simply satisfying the customer. The methods now lumped together under the term “Agile” were not just different ways of managing work: They were a revolutionary yet realistic way to think about work.

As often happens with revolutions, the Agile Revolution 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] His warning failed, and the United States now spends far more money just on “defense” than all other countries of the world combined.

I believe a similar “Agile Industrial Complex” has developed undue influence over the business world by telling executives what they want to hear, subverting the entire point to the Agile Revolution. 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 Iron Triangle 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 Stack Scrum™ 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. (In its draft document form, it was more than 500 pages long!) 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.

Those competing systems like weird acronyms with upper- and lower-case letters, so I had some fun by reducing Full Stack Scrum to “FuSS™.” There’s an American expression “make a fuss,” meaning to cause trouble, so it fits!

FuSS 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 Revolució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 Stack Scrum to be Agile.

At the same time Scrum was being developed, I began training “self-directed work teams” (SDWTs) that met all of the principles of the Agile Manifesto years before it was written. They had all the functional roles needed to complete their various duties. They met every week or two to review issues new and old, make decisions, and create, volunteer for, and report on tasks. They were in contact with customers every day, and released changes in small increments as those were ready. One set of teams I worked with delivered a major change project to high customer satisfaction without creating a project plan, and without overtime. 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 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 viable 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.

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 FuSS, 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 Stack Scrum’s 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 approach 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 continue with this one.

How this Agile Site is Different

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 method called “Scrum” at the cross-team and enterprise levels.

You can find dozens of books on 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 have written 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 Stack Scrum 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!

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 Stack Scrum. But I have rarely walked into a company that said it was using Scrum and found the 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 Scrum teams are doing that, FuSS is not going to work.

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

  • Individual teams not using Scrum, or not getting the results they want from Scrum.
  • Groups of successful Scrum teams that must coordinate their output.
  • Organizations that create new products or services, of any type, and are experiencing problems with those deliverables.
  • 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 Agile 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.

Although I words like “corporate” and “company” at times, the Full Stack Scrum system is intended for any kind of organization that does any kind of project work. Many books on Agile focus on software, and there is a separate literature on manufacturing “agility” which I consider the same thing. While addressing the reality that most readers will probably be in software, I regularly address scenarios faced by nonprofits, creators of tangible products (“hardware”), and continuous improvement teams.

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 that go 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 in the next section.

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 is so I don’t have to keep writing the system up with each new contract I take. Those write-ups have proven invaluable in evangelizing, teaching, and supporting adoption of the system.

That leads to the biggest difference from other systems for Agile-at-scale: Full Stack Scrum™ 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 in this site or the Web site, as long as you attribute Jim Morgan as the author of the original content (or other site contributors as named) and this site as the source. (If you print the entire “System” section, the license requires you to keep one section unchanged, “A New System for an Old Revolution,” and include a back cover page with these words: “Based on content available for free at FullStackScrum.net.”) The copyright notice behind the title page provides the legal fine print.

Although I hope the creators of the Agile Manifesto would appreciate my attempts to return Agile-at-scale to its philosophical roots, they would not like parts of this system. They got some things wrong about human psychology. For 14 years I had a side business in which I taught how to apply the lessons of academic research on individual and group psychology to business teams. In the course of that, I read hundreds of studies and created a system for maximizing business team performance called The SuddenTeams™ Program.[4] FuSS modifies some typical Scrum practices based on that research and my pre-Agile experience with creating self-directed teams.

For this site, I extended that teamwork research to peer-reviewed content specific to Agile and Scrum. 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.[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. 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. The long-term problems I have witnessed or heard about, and those mentioned in current Agile research, do not exist in mature Full Stack Scrum programs. A disciplined approach to implementing the system always shows positive results within weeks, and can achieve high levels of predictability and quality within a few months.

That said, this site lays out an approach to attain long-term success in Agile-at-scale. 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 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 Stack Scrum will help any organization having delivery problems implement a systematic approach to project 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 FuSS.

If managers do not change their own ways of managing or insist that teams try the system fully, this site will fail badly. So will any other approach to improving performance. For those who 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 FuSS.

Agile is a philosophy of project 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 Agile 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, Scrum Pox[3] 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 some projects lends 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.

Make a FuSS! | ← Why FuSS? | → How to Use

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

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

[3] Scrum.org 2015.

[4] Though published as a profitable book, it now is available as a free hypertext because it required a level of support I no longer wished to provide.

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

Share this page