Factual Scrum Friday- No roles in Scrum!

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/

Scrum Master Accountabilities- just what are they?

Just what are the accountabilities of the Scrum Master? Angela Johnson and Christian Antoine break it down!

What is the Point of the Daily Scrum? (Updated for 2020)

What is the Point of the Daily Scrum?

In Marvel’s popular movie, Guardians of the Galaxy, Peter Quill is trying to come up with a plan to stop the villain and save the day and confesses that he only has 12% of a plan put together. As he engages support from his teammates, they each stand as they commit to the goal. As the final member, Rocket, stands he says “Well now I’m standing. Happy? We’re all standing now. Bunch of jackasses, standing in a circle.”

Does that remind you of your Daily Scrum? That scene struck a chord with me. I hear so many students and clients complain about the Daily Scrum. Yet the things they claim not to like, only reveal that they don’t understand the point of the Daily Scrum. They believe the myths and create anti-patterns that degenerate Daily Scrum into a waste of time.  

The original copy of this post appeared in 2019. It’s time to update it since the official, free Scrum Guide was revised in November 2020. It’s also an opportunity to further clarify a few more facts:

1.     What Does a Scrum Master do Every Day? It’s certainly not conducting the Daily Scrum. That’s right. That wasn’t a typo. It’s a myth that the Scrum Master shows up to the Daily Scrum and call on each person. The Scrum Master is not an adult daycare provider. An empowered team of Developers conduct their own Daily Scrum. A Scrum Master teaches them the intent of the Daily Scrum and ensures it occurs as intended. What if the Scrum Master is out on vacation? Does the Daily Scrum get cancelled?  No! If they have taught the Developers well, the Daily Scrum can go on without them. It’s an opportunity for the Developers to talk to each other about the Sprint Goal and to make a plan for the day.

2.     What’s the Point of the Daily Scrum? The Daily Scrum is intended for the Developers to provide Transparency about the Sprint Goal on a Daily basis so that they can Inspect and Adapt. Why let 10 days, 15 days, 20 days go by to learn that there’s an error message holding someone up or an impediment in getting an item done? Isn’t it better to have a quick check in and find out potentially every day what’s holding up work or the product increment from being complete? Of course, that means people actually have to be transparent but that’s for the Scrum Master to teach. That doesn’t make this a status report to the Scrum Master or to the Product Owner either. The Developers conduct the Daily Scrum - they talk to each other to make a plan for the day. If a person needs assistance and another team member hears the issue they may chime in and say “I can help with that. Can you hang on the line or stay after so we can chat?” If that works for them, great. If staying doesn’t work, they can plan a time that works better. They aren’t holding everyone else hostage while they step through all the details about the item in question.

3.     Do we Have to Stand? No! That’s another myth we often have to bust in CSM® workshops. The Developers conduct the Daily Scrum so they get to decide what time the event occurs and whether there’s an agreement about standing or not standing. And no, it doesn’t have to be in a circle either. Some believe standing keeps the event short and sweet but standing is not “required” nor is that listed in the Scrum Guide as any sort of rule.

4.     Why is the Daily Scrum at the same time each day? This helps reduce complexity and cuts down on needless administrivia with calendars. If it’s at the same time and same place every day, there’s no need to constantly update that information. It’s known.

5.     How Long is the Daily Scrum? The Daily Scrum is 15 minutes or less.  The intent is not to hash through an error message raised or an impediment raised in that short amount of time, the point is to give transparency into what is happening. That way a plan can be made for who needs to be involved, and more importantly who is not needed, after Daily Scrum is over. People also forget the “or less” part of the suggested timebox. It’s intended to take 15 minutes to provide transparency on the Sprint Goal and make a plan to address those items. If that takes less than 15 minutes, get on with your day.

6.     Do we have to Answer the 3 Questions: What 3 questions??? They have thankfully been completely removed from the official Scrum Guide. Why? Because they were ignored or creatively edited over the years. It was never “here’s what I did yesterday, here’s what I’ll do today, no blockers”. Those weren’t the actual suggested questions. It’s no wonder the Daily Scrum is useless if those are the questions that your team is using. It probably has them rattling off a laundry list of tasks including what they ate for lunch and bunch of other things that add no value in learning where we’re at on the Sprint Goal. The questions used to be:

·       What did I do yesterday that HELPED the Development Team MEET THE SPRINT GOAL?

·       What will I do today to help the Development Team MEET THE SPRINT GOAL?

·       Do I see any impediment that prevents me or the Development Team from MEETING THE SPRINT GOAL?

It seems over the years people have just eliminated the sprint goal – which is the whole point of the Daily Scrum: transparency, inspect and adapt on the Sprint Goal. If you’re wondering ‘what the heck is a Sprint Goal’ it may be time to check out that free, official Scrum Guide which can be found here: https://scrumguides.org/Or maybe we’ll do a post dedicated to the topic of the Sprint Goal or feature it on an upcoming Ignite-Agility®podcast.

Hopefully this helps clear up any myths about what a Scrum Master does every day in regards to the Daily Scrum. Come to think of it, maybe we’ll do another post all about how the Scrum Master spends their time effectively. In the meantime, use this dose of reality about the Daily Scrum to get daily planning back on track, revealing impediments quickly and focusing the Developers on working together to accomplish the Sprint Goal. 

Collaborative Leadership Team Hosts Sixth Annual Scrum Day Minnesota

Sharing of real-world experiences and networking highlight Scrum focused event

MINNEAPOLIS – October 4, 2018 – Collaborative Leadership Team (CoLead Team), an industry leader in providing Scrum and Agile coaching and training, hosted its sixth annual Scrum Day Minnesota on October 4, 2018 at the University of Minnesota – St. Paul campus. The sold-out not-for-profit event brought together more than 300 individuals from around the region to share their stories and network as a community.

“Scrum is all about people,” said Collaborative Leadership Team founder and CEO Angela Johnson. “We (CoLead Team) created Scrum Day Minnesota so that people leading Scrum implementations could come together to learn from each other about how Scrum is working for them. Instead of just hearing from experts on the subject, this event fosters relationships and knowledge sharing that will help others achieve success with their Scrum and Agile journeys.”

This year’s keynote was Andy Worshek, co-author of “The Turn This Ship Around! Workbook.” Drawing from David Marquet’s ground-breaking leadership book, “Turn this Ship Around” Worshek shared practical advice on applying intent-based leadership principles. As Sonar Chief and Chief of the Boat under Marquet on the USS Santa Fe, Worshek gained unique perspective on the challenges of implementing intent-based leadership from all levels as well as the results.

Following the keynote presentation, attendees had the opportunity to hear from a number of Minnesota-based organizations implementing Scrum and Agile programs including: Allen Interactions, American Equity, Andersen Windows, Cogency Global, Hennepin County, Minneapolis Institute of Art, Nova-Tech Engineering, Power Objects, Thrivent Financial and Thomson Reuters.

"Scrum Day is an excellent opportunity for us to refresh our understanding of Agile and Scrum,” said Ben Ark, senior vice president of Software R&D at Cogency Global Inc. “It's also a great way to meet, collaborate and network with other Agile and Scrum practitioners and other Information Technology professionals in the Twin Cities community and learn from them. It helps us share ideas with them but also helps us learn from others to improve our processes." 

Profits from the event will be donated to Solid Ground, an award-winning nonprofit organization whose proven, holistic approach helps families build the strong foundations they need to emerge from homelessness into a brighter future. Past donation recipients have included Second Harvest and hurricane relief charities.

About Collaborative Leadership Team

Founded in 2010, Collaborative Leadership Team is an industry leader in providing Scrum and Agile coaching and training to companies in a variety of industries including: software, hardware, services, marketing and more. Practicing what they teach, the employees of the Twin Cities-based company use Scrum to manage their services organization. The breadth and depth of Collaborative Leadership Team's experience extends beyond Scrum and includes Kanban, eXtreme Programming, Facilitation and Organizational Change for business agility.

###