Scrum isn’t SAFe: a values-based perspective

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/

Why Scrum Case Studies Don’t Work

You may be asking, “what do you mean Scrum or Agile case studies don’t work?” Afterall, isn’t the point of a case study to provide information about the successful Scrum or Agile transformation? Yes, case studies do just that. They provide the information about a particular company and its journey. But please remember that any Agile approach, Scrum in particular, means change. Structurally changing and behaviorally changing.

In Collaborative Leadership Team’s experience, there are 2 reactions to Scrum or Agile case studies that simply don’t work. Or that do more harm to your organization’s agility than good.

1.  Cognitive Dissonance: When asked for “real” examples of organizations adopting Scrum or Agile frameworks we provide real company case studies in our classes and in our coaching. These examples contain factual information about decisions made, structural changes made and behavioral changes made. Yet countless students and clients then immediately reply with “Well that won’t work for our company because (fill in the various reasons)”. Dr. Harvey Robbins gave us a simple explanation. It’s cognitive dissonance. Even when presented with facts, the people in question will start to rationalize or hold true to existing beliefs that prevent them from making those changes. It’s not a case of “Scrum doesn’t work” or “Agile doesn’t work”. They work. If used as intended. If an organization does not want to change, they could choose not to. But there’s no value in calling something Scrum or Agile if there is no change behind it.

2. Copying without Knowledge: It’s great if case studies inspire your organization to change or to do something differently. But there is no quick fix, no magic pill or any shortcut. Too many organizations think they can simply copy another organization’s journey. Dr. Edwards Deming called this “copying without knowledge”. He noted that American management thinks they can just copy Japan but they do not know what they are copying! The same is true with Scrum and Agile. How many people try to copy Spotify? Never mind that their business has nothing to do with an online music streaming business, they just copy buzz words that Spotify doesn’t even use and say they are doing the “Spotify Agile method”. Even though no such thing exists. The reality is that every company has to take their own journey. They have to talk to each other, make decisions for their own business, make structural changes along with behavioral changes to achieve those goals and objectives.

What can you do instead? Create your own “case study.” Really make the structural and behavioral changes required and discuss what was learned from doing that. It doesn’t have to mean changing the entire company at once. It can be as simple as starting with one product or one initiative but really making the necessary changes. Then determine if goals and objectives were met for the product release or initiative. Were they not met? What did we learn? What could be improved?

If you are interested in learning for yourself and curious about how to get your own journey started, we’re here to help. Whether it’s joining our free user group, accessing free podcasts and blogs or attending one of our live, online workshops, check out our course schedule here.

Use These 3 Tips Next Time You're Coaching Up In Your Organization

We asked and our community answered!  You asked for more tips on working with your leaders in an Agile or Scrum adoption. Read on for our top 3 tips to coach “up” in your organization or just have a more meaningful conversation with your leaders.

1.       Respectfully ask Why: the number of people filling our classes who are unable to answer us when we ask “what is the reason or goal for your company changing the way it does work to Agile or Scrum?”.  If the people doing the work do not know the answer to what the goal is it’s unlikely that this goal will be met. Going Agile isn’t a Goal. Scrumming isn’t a Goal. Goals can be measured. Respect is key here. A common mistake is asking “Why”? and it sounding like a challenge to someone’s authority. Phrase the question honestly. If you are confused or the teams of people are confused, say that:

·       “We’re confused as to what the goal is. We want to meet goals and objectives, we want to do a good job, we just don’t understand what problem we are being asked to solve”.

·       “What does Success look like”?

·       “How will we measure this goal”?

·       “How will we know when we’re Done”? 

2.        Don’t use the “A” word or the “S” word:  it’s a common mistake for people newer to Scrum and Agile to talk about those as if they are separate things as opposed to what they are – different ways to approach work. In projects, did you say project management every other word or sentence?  Did you utter waterfall constantly?  No. It’s just the way you did work. When you talk about Agile and Scrum as if they something else, that’s where those ideas stay – as something else. The language can also confuse people if they don’t understand it. Or worse. It can put a leader on the defensive if you say something silly like “that’s not Agile” or “that’s not Scrum”. Who cares!  They are different ways to do work. Try phrases like:

·       “You have asked us to change the way that we’re doing work but I’m hearing you also ask us to do the same work the old way.  Can clarify what the expectation is please?”

·       “We’re not meeting goals and objectives so it may be helpful to take a look at our approach to the work – can you help us with that”?

3.       Be Brief, Be Clear, Be Gone:  another mistake for people newer to Agile and Scrum who are enthusiastic about this change, is that they verbally throw up entirely too much information and vocabulary on their leaders in their excitement. Depending on the level of leadership being addressed, it’s not that they don’t care or are uninterested necessarily, it’s that there is a lot on their mind. They may have the best of intentions but little time and a limited attention span. We’ve experienced many leaders rolling their eyes, sighing and looking at their watch who then reply “what are the top 3 things you need from me right now?”.  So try this:

·       Come prepared with the top 1, 2 or no more than 3 things that are most pressing that require that leader’s attention

·       Craft that message as succinctly as possible with facts, no unnecessary “A” or “S” words

·       When you’re done be gone. The leader can always ask for more information if they need it or want it or follow up with you if necessary.

With any advice, tips, tricks, etc. they are only effective if you use them and most importantly continue to use them. Practice is what will bring about more permanent changes to the way you and your organization approach work.

To learn more, check out our course schedule and join us for a training!