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/

4 Signs Your Agile Coach is a Fake

Today’s business world is saturated with Agile Coaches, Scrum Masters, and certifications. Everyone is “going Agile” (if they haven’t already). Companies across the globe are engaging Coaches to guide their organizations and teams.

Why are some gaining immense value with Agile, and others frustrated and failing? Not to say it’s all contingent upon the Coach – company culture, structure, and leadership have a hand in it too. But without a great coach, what happens to nearly every team?

They lose.

Have you ever encountered an “Agile Coach” who can talk the Agile Talk, but in practice, they’re clueless?

In this post, we’ll share red flags that show whether your “Coach” is actually a Fake! You’ll learn how to spot a dodgy coach, and how to know when you’ve hit the jackpot and found a great one.

Red Flag #1: Your Agile Coach is obsessed with Buzz Words

“They won’t realize I have no idea what I’m doing if I use lots of Agile words.”

While we expect people to be honest on their resumes and at interviews, that doesn’t always happen. I don’t want a coach with an impressive resume and credentials galore if they can’t deliver results.

There seems to be an army of “coaches” these days who’ve never actually been on a team – of any kind – let alone an Agile team. They try to mask it by “sounding smart” and being vague about their experience. They are obsessed with Agile buzz words, and constantly use Scrummy language.

A great coach doesn’t need to show off their vocabulary. They know it’s just “the way we do our work.”

Take Apple TV+’s Ted Lasso. Ted successfully coaches a professional soccer team, and he doesn’t even know the rules of the game.

How, you ask? Keep reading to find out.

Red Flag #2: Your Agile Coach is extremely prescriptive

“This is how it’s done. Any other way is simply wrong!”

A Fake Coach sees their beliefs about Agile and Scrum as absolute truth. They are not to be questioned or altered in any way. They know the rules (or at least think they do), and treat everything as set in stone.

A good coach understands that the Agile Manifesto and Scrum Guide provide guidelines. Yes, there are prescribed roles, events, and artifacts. But how we incorporate these practices is up to the team.

One size does not fit all. No two Agile or Scrum adoptions look the same! People have a significant effect on how everything plays out.

Ted Lasso’s at it again with a radically different approach to managing the AFC Richmond team. They don’t have to function the same way as the team with the most wins.

Ted helps the team discover what’s best for them.

Wait a minute…I thought the coach had the final say?

Let’s dig into that a bit more.

Red Flag #3: Your Agile Coach always has an opinion…and they are always right

What are some other words for “coach?”

Trainer, instructor, teacher, mentor, educator.

I don’t see manager, executive, supervisor, director, or administrator on that list.

So why does your coach impose their opinions and ideas on everyone else?

A Faker masquerading as a Coach always has an opinion…and they believe they are right. They tell people what to do and how to do it. They focus on specific outcomes, putting their own goals over those of the customer and team.

What does a good coach do differently?

They ask questions. A lot of them!

To be great, a coach doesn’t need to know everything about how to do the work. I’ve coached four software development teams, and my technical skills stop at very basic SQL and HTML. Don’t even ask me the difference between C# and Python.

In all these situations, my teammates – the developers – knew what they were doing, and I trusted them to do it. The value I added wasn’t technical. It was focused on people.

The same can be said of Ted Lasso. He’s a soccer coach who doesn’t know the definition of “offside.” But the team, assistant coaches, and staff are experts. Ted asks questions, takes input from everyone, and keeps his ego in check.

We all have egos, there’s no denying it. But on a team, what’s more important – “me” or “we?”

Red Flag #4: Your Agile Coach doesn’t understand teamwork

Consider the synonyms for “coach” mentioned earlier – trainer, instructor, teacher, mentor, educator. Think about the mentors, teachers, and leaders who have most impacted your life or career. What made them positive or negative influences on you or your team?

In your worst experiences, did you feel psychologically safe? Was everyone on the team treated with respect? Was it ok to try and fail? Did you, your teammates, and the coach all have clear expectations? Did people work together and support each other?

Probably not.

A great coach makes people feel safe, and knows that failure is simply an opportunity to learn. They make sure all voices are heard. They understand the complexities of team development and dynamics.

Coaches help people work together, learn together, and improve together. They acknowledge the value each person brings. They are highly invested in other people’s success.

Like Coach Lasso says, “…success is not about the wins and losses. It’s about helping [the team] be the best versions of themselves on and off the field.”

So, is your Agile Coach the Real Deal, or are they a Fake?

I bet you already know the answer to that question.

If the red flags described in this post sound familiar, don’t panic! The Internet is full of misinformation, and “copying without knowledge” happens every day. Your coach may not even know they are too involved, too prescriptive, or that they sound like an Agile dictionary. If they do know and are still doing it…you might want to find a new coach.

Anyone who wants to learn can and will! And if they don’t, now you have the tools to spot your very own Ted Lasso in the crowd of mediocre “coaches.”

If you’re interested in learning more about Agile, coaching, or Scrum Mastery, check out our coaching services and upcoming courses here! 

Apple TV+ Ted Lasso

Are You a Credible Agile Leader? Not if you Enable Excuses.

An ongoing blog series about Agile and Leadership

“Whoa! I don’t enable excuses” you may be thinking. “I don’t even accept them” may be your follow up thought. You’ve heard the old saying ‘you reap what you sow’. The organizational structure currently in place is the root cause of the behavior and the results you are experiencing.

Let’s explore one of the more popular examples of this. As a leader you may lack the ability to Focus, one of the Scrum values. Instead of weighing the pros and cons or trusting an empowered Product Owner to make these decisions and order the work, you declare “It’s All Priority!”.

The reality of what you said is there is no priority. Priority means one thing is before something else. Which means people who have this lack of direction now are in a position of having to guess. Can you feel your credibility as a leader diminishing?

Since everything is priority- spread the people doing the work across all these items and don't allow them to Focus and get work to Done. And call them projects or tasks or teams and tell people they are 25% “allocated” to this thing, another 15% to that thing, etc. Decades old data which continues to be upheld proves this isn't effective and won't achieve faster results. In fact, it’s slower because of the context switching that people are experiencing. They need to remember where they left off on one project or task to ramp back up and get back to work on that. Only to get interrupted or told they should be focusing on a different project or task. One of the original data sets is provided here:

How credible do you feel knowing your employees not only have this data, they live it every day in your organization? The reality is you have handed every single person that is time-sliced a built-in excuse.

You ask them for information on project 1 and they tell you “Oh let me get that for you in a minute, I’ve been busy on project 2”. You ask someone for status on project 2 and they tell you they have been busy with projects 3 and 4. Who knows what is happening? With this chaotic approach to doing work there is zero transparency and a bunch of ready made excuses.

Understand why your credibility as an “Agile Leader” is pretty low and ready to fix it? The good news is it takes only 2 things:  dedicate teams and order their work.

That’s it. 

Want No Excuses and higher visibility into results? Never want to use the words Agile or Scrum again? No problem. Bring work to the team in a force-ranked order. That means something is #1. Then something else is next. This way there are NO EXCUSES. Work is either done or it’s not done and we focus on removing/working through the impediments to getting it to done. Yes, Agile approaches such as Scrum enable getting work done but only if used as directed. If you don’t make the structural changes required, the behavior doesn't change and it’s excuse time.

Want to be coached on how to become a credible Agile Leader? Contact us at: info@coleadteam.com

Willing to Pay More for Toilet Paper than Professional Development?

If you answered yes, this article is not for you. If you answered no, read on.

COVID-19. Coronavirus. Pandemic. These words dominate our headlines and have changed all our lives. Everyone's forced to adapt. If you have tried to buy toilet paper or hand sanitizer you know what I’m talking about. Even if you try to buy online, some firms who claim to have stock want prices ranging from $20-$50 and even travel size hand sanitizers are selling in that range. Our lives are turned upside down! Don’t worry…this post is not about politics or supply chains but is one observation about the world of work since stay at home orders began.

Now more than ever organizations need to learn how to work. To change, to adapt, to be “agile”. To continue serving the world of work without lowering quality standards, the Scrum Alliance has pivoted and is allowing Certified Scrum Trainers® (CST®) to lead Certified ScrumMaster® (CSM®) and Certified Scrum Product Owner® (CSPO®) courses virtually. These courses have become industry standard based on the Scrum Alliance reputation and high-quality standards for its trainers.

My profession is guiding business agility. I help individuals and organizations perform work . This requires making structural and behavioral changes. The certifying body I choose to represent is the Scrum Alliance. The Scrum Alliance is a non-profit organization whose mission is to transform the world of work (scrumalliance.org). I could represent for profit organizations who only care about their bottom line. That’s not what gets me out of bed every day. Making real change, positive change, in the organizations I serve is what gets me racing to work every day.

In the last 3 weeks my inbox has been hit hard with advertisements from every FOR profit service corporation that I know of, and many that I didn’t know existed before, offering to sell me 100-120 hours of Scrum “certified” prep training and Agile project training for the low, low price of anywhere between $20-$50 per person. These companies have fooled students and prospective students before the pandemic! I hear stories of wasted time and wasted money from students and companies who wind up with no recognized credential and not knowing where to begin with Scrum or Agile.

These companies have no affiliation with an accredited Scrum or Agile organization, no experience implementing the frameworks they are advertising to teach, no credibility in the Agile or Scrum space, list no trainer name, no biography and no recognized credentials. Now, they are counting on people being at home. They are counting on people suddenly out of work who have an opportunity to re-skill or educate. They are counting on companies needing to educate a distributed workforce. Most of all, with their pricing structure, they are counting on volume.

Please don’t assume I’m sharing this because I feel threatened by these organizations. I don’t. These organizations are chasing anyone and everyone. If companies believe they will be able to educate their workforce on agility and reinvent the way work has been done through these types of organizations, then they probably aren’t serious about making real change anyway. And what does it say about a company who is only willing to invest in their people, their future for the same price they will pay for toilet paper or hand sanitizer right now? Those are not the people who want to make real change.

The hard part is to explain to a student, prospective student, or company that what they spent their time and money on is not the CSM® or the CSPO®. When we start talking about the Scrum framework or Agile, what the student or company learned in the 100-120 hours spent doesn’t resemble Scrum or Agile at all. Now the student or company is even more confused. The FREE, official Scrum Guide is available to anyone at: scrumguides.org The Agile Manifesto is also free and available to anyone at: agilemanifesto.org.

If you're interested in learning about Scrum or Agile, check out the free sites referenced in this post. The Scrum Alliance also shares many free blogs, videos and webinars for anyone to learn more if funds are tight and better spent on toilet paper and hand sanitizer right now. Our website also hosts free podcasts and blogs to provide education. Scrum Alliance credential holders can also earn free Scrum Education Units (SEUs) by taking advantage of the free content on scrumalliance.org or coleadteam.com.

If you're interested in earning the official CSM® or CSPO® credential, and want to avoid click-bait or bait-and-switch ads from imposters, the best source to learn more and to register for a class is: scrumalliance.org. If you have recently lost your job and will be pursuing assistance through the MN Department of Employment and Economic Development, CoLeadTeam is an approved provider: https://apps.deed.state.mn.us/lmi/cpt/EducationResults.

We hope you’ll join us in changing the way the world does work. Stay safe and wash your hands!

More with LeSS: Who's on the Scrum Development Team?

In the first two posts in this series, we explored how to identify the product and how to identify the Product Owner. If you missed these tips, check them out HERE.

Now let’s say you have effectively identified both the Product and the Product Owner. How do you identify the Development Team? Or in the case of BIG products, which this series is focused on, how do you identify multiple Development Teams?

Regardless of the development type - Product Development, Internal Product Development or Project Development - with Scrum, the Development Team characteristics as described in the Scrum Guide remain the same:

• Are self-organizing. No one (not even the Scrum Master) tells the Development Team hot to turn a Product Backlog into increments of potentially releasable functionality

• Are cross-functional, with all the skills as a team necessary to create a product increment

• Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole

If Identifying Product was Skipped:

Scrum adoptions are rarely effective if identifying the Product was skipped and what is happening is an attempt to make Scrum fit into existing structure or the status quo.  Scrum is about changing the status quo. It potentially requires structure change in order to effectively optimize for delivery of working product.

As an example, if the structure of the organization has people segregated by specialized, singular activities such as analysis, building, testing, architecture, etc. those are component teams. The component team structure not only requires hand offs, late integration which increases risk, it structurally does not enable delivery of value to the customer the way a cross-functional feature team can. If the organization is still using project management with component teams, it’s rare that any members of component teams are 100% dedicated to one project. Typically, people are assigned to multiple projects to execute the one, specialized skill so that instead, they appear to be 100% “utilized”. This divides their attention, is less productive due to context-switching between projects and is a cost drain.

Like Scrum, Large Scale Scrum or LeSS, requires the teams to be cross-functional possessing all of the necessary skills to deliver a customer-centric feature or features in any given sprint (analysis, programming, testing, database work, etc.). Team members are 100% dedicated so there is focus on value and no loss of productivity due to time-slicing. Although people may initially have a special skill, Scrum and LeSS teams are multi-learning teams. People are willing to learn other skills and work together to deliver value.  An illustration from https://less.works/ comparing component teams to feature teams:

Because there’s always new features, maintenance or items that come back to the team via feedback loops, these teams are also long-lived. Customer centric features from the Product Backlog are broken down into items on the Sprint Backlog that the cross-functional, self-organizing feature team delivers in a sprint. Identifying Product at the beginning of the adoption makes it pretty simple to identify all of the skills that will be needed in order to achieve this. Each of these feature teams is made up of a minimum of 3 people with a maximum of 9 people per team.

How many cross functional feature teams are needed may be determined based on the needs of the Product itself or budget. In a LeSS adoption, the upper limit for the number of teams is 8. In really BIG product scenarios, LeSS Huge may be adopted which involved more than 8 teams. For more information on LeSS Huge teams please visit:  https://less.works/

To learn more from Large Scale Scrum (LeSS) co-creator, Craig Larman, and to earn a Certified LeSS Practitioner credential register HERE.