This post will tick some people off. Especially people who reply solely on catchy titles without reading the entire post. My goal is to share my own experience and perspective while also making an effort to cite original sources to provide references.
In 2003, the organization where I worked wanted to try something called Agile. We got together in a conference room and reviewed the values and principles posted here: https://agilemanifesto.org/
We talked about what those values and principles meant in our context and what we could change to realize better outcomes for our customers. We decided to adopt a more formal framework from those represented at the creation of the Feb 2001 Agile Software Development Manifesto. Those frameworks represented can be viewed here: https://agilemanifesto.org/history. We chose eXtreme Programming. There really wasn’t a training class that we knew of to attend at the time on the practices of Test-Driven Development, Pairing and Continuous Integration, so our organization hired an Agile Coach. The coach was with us temporarily to teach us those programming practices including how to write actionable test cases from criteria based on user conversations, how to set up our continuous integration environment and how to deliver higher quality software more readily to our customers and users.
By 2006 I had moved on to a different organization and had started to hear more about another framework represented at the famous 2001 Snowbird meeting. It was called Scrum. At that time, the only Scrum training class I heard my peers talking about was something called the Certified ScrumMaster®(CSM®) from the non-profit, mission-driven Scrum Alliance®. The only reference to large instances of Scrum or at “scale” that I was aware of was something called Large Scale Scrum from Craig Larman and Bas Vodde (https://less.works/).
Fast forward to 2011. The Agile Manifesto turned 10! Scrum was even older than that! I attended the Agile 2011 Conference in Salt Lake City with many other people who also celebrated these milestones. Most of the original 17 manifesto authors were present at the event. They took turns answering questions from the audience in a large, open forum. We got to hear their thoughts live…straight from those 17 creators directly. They talked about agility. About organizational structure change. About teamwork and technology practices. Toward the end of a long week there was a speaker named Dean Leffingwell giving a presentation on agile at an enterprise level. It was not called SAFe or Scaled Agile Framework. Although the word “scaling” was briefly used in the presentation, the phrases SAFe, Scaled Agile Framework, Release Train Engineer, PI Planning, etc. appear nowhere in the title, the description or content of the presentation.
That makes sense because in the timeline leading up to 2011, there was no company called Scaled Agile Inc. or any approach called Scaled Agile Framework (SAFe). It didn’t exist. The creators of SAFe were not at the 2001 creation of the Agile Manifesto for Software Development. They were not involved with Scrum or eXtreme Programming at all. People I worked with during this time didn’t use words like feature, epic or release train. Even more importantly, nobody misused concepts like user stories, acceptance criteria or story points. Although Mr. Leffingwell’s talk at the Agile 2011 conference didn’t mention SAFe, Scaled Agile Inc. was founded later that same year: https://scaledagile.com/dean-leffingwell/.
Why go to the trouble to share all of this with you? I have a values-based disagreement with SAFe. If the creators of SAFe wanted to do something different, why didn’t they use different vocabulary? Instead, they took vocabulary words and ideas from someone else’s creations and changed the definitions of those words.
Did they do something illegal?
I’m not a lawyer and I don’t play one on TV either. But no, I don’t think it’s illegal because Scrum was put into the Creative Commons. It’s open source – given away to the world for free: https://scrumguides.org/. eXtreme Programming practices can be found free of charge here: http://www.extremeprogramming.org/. To my knowledge, no creator of any framework represented at the creation of the Agile Manifesto for Software Development endorses SAFe. I follow many of them on social media to this day and their posts suggest quite the opposite.
Did the creators of SAFe do something that I believe is unethical or disrespectful? Yes. If they wanted to do something different, why didn’t they use different words? It feels like “bait and switch” when they hook people with the word Agile or the word Scrum. I laughed out loud recently when I saw something from Scaled Agile Framework saying it’s trademarked. Really? Trademarking a collection of other peoples’ work? How is that even possible?
I would have more respect for Mr. Leffingwell and his peers if they had just come up with different words to define their ideas. Instead, it feels like they are counting on the popularity of Agile, Scrum and even elements of eXtreme Programming to reel people in.
You may be thinking, “Ok, Angela, so you find SAFe disrespectful, so what”? The real damage that’s being done isn’t to me. I’ve been working with Scrum and Agile longer than SAFe has been a thing so I know the history lesson, learned many Agile practices as intended from original sources and experienced them in action in the workplace. The introduction of SAFe into the world hasn’t changed my mind or the values-based disagreement I have with it.
The real damage is being done to people and to organizations who are new to Agile ways of working such as Scrum and eXtreme Programming. They spend a lot of money and a lot of time to learn a bunch of new words that are misused. Which often results in no behavior change and no delivery of value to customers any sooner than the project management way of working – sometimes referred to as waterfall.
Here’s just one example from a recent Certified ScrumMaster® (CSM®) class. When asked why Scrum doesn’t have terms such as User Stories and Acceptance Criteria I shared the Scrum approach to these ideas. But then I also shared the original meaning of these terms – largely from eXtreme Programming. The human being is intended to tell the story or what’s needed. They answer questions that people doing the work have. As those answers are given, the people doing the work capture those results in actionable form of acceptance criteria which is the basis of test first. Sometimes referred to as Test Driven Development. The executable test is created first. Programming occurs and hopefully fails so that it can be corrected until the tests pass. Now there is something of value that can be delivered to a user or customer. And the Sprint or Iteration isn’t even complete so we can deliver even more value with these practices.
After sharing the original intent of these practices, I asked the class for a show of hands if they are working in a Scaled Agile Framework environment. I then asked for a show of hands if what’s happening in their context is someone is told to write user stories. Those are then given to someone who codes them. Then items are given to someone at the end of the sprint or iteration who tests the stories. The same people raised their hands indicating yes - this is exactly what’s happening in their context. So, I asked them “what does that sound like to you”? Everyone said “waterfall”.
The student who originally posed the questions said “but the original stuff makes so much sense; it’s frustrating to find out we’ve been put through a lot of hoops which basically mean keep doing work the way we used to do things but with a bunch of new words”.
I agreed with this student. From my perspective, original ways of working are an enormous amount of common sense that when used as intended, deliver value to our customers and users more readily. Isn’t that the whole point? The problem is further compounded by software tools that misuse the vocabulary terms. They include a hierarchical database with layers of labels and people feel like they are being forced to work the way the software tool “makes” them do things. So much for “individuals and interactions over processes and tools”.
While my perspective is that Scaled Agile Framework disrespects original work and confuses the world of work, I respect people who get educated about the options available and choose SAFe anyway. You read that correctly. My stance is that after getting knowledgeable about the choices available, if someone actively chooses SAFe, that is their choice. I choose differently and hopefully my own choice is also respected for me and for the way my organization chooses to work. I will never be a fan of “copying without knowledge” where people haven’t been given a chance to learn for themselves, to own their own ideas and can make an informed decision.
What can anyone working in an “Agile” environment do?
Read original sources. Don’t gloss over the words. Read to comprehend. Really understand what is being offered. Read the free, official Scrum Guide. Read the Agile Manifesto for Software Development – not just the values and principles but the history link also. Read anything you can get your hands on by the original authors. Yes, and read what Scaled Agile Framework defines as “agile”. Read what other corporations also define as “agile”. Scaled Agile Inc. is not the only company that is taking these ideas and saying that they now mean something else.
Own it. Own your own choice. Be transparent about what your stance is to avoid confusing people you are interacting with.
Name it. When you say Agile it is confusing even if you are talking about the Agile Manifesto for Software Development since there were 7 frameworks represented at that meeting. If by Agile you mean Scrum, name it. And even then, in 2023 you may need to go a step further about which definition of Scrum YOU mean. As an example, in every talk I give, every workshop I lead and even in customer conversation, I ensure that the context I give when I’m talking about Agile is the values and principles in The Agile Software Development Manifesto. When I say Scrum, I mean the framework described in the official Scrum Guide. And so on.
If we can all commit to working towards shared understanding in our own contexts about what we mean when we use the word salad that Agile has become, we just may begin to change our ways of working for the better.
Angela Johnson is a Certified Scrum Trainer® with Collaborative Leadership Team. For more information, please visit us at: https://collaborativeleadershipteam.com/