#agile

Hate SAFe Machine Update – “Remove references to Scrum…” foolishness

Posted on Updated on

I could do this all day. Easily pick apart the ignorance in the subject article. It seems that hate knows no bounds with some people. Get over yourself already!! An entire collection of thinly veiled insults masquerades as arguments in a petition set against damaging Scrum. Facts be damned in the articles arguments.

So here is just one of many potential dismantling opportunities for the ignorant and arrogant arguments presented in the linked/subject article.

reference link: http://remove-scrum-from-safe.tilda.ws/PO

So, the haters #removescrum argument is that SAFe says “the PO is the only team member empowered to accept stories as done” and this is an anti-pattern.

However, if we navigate over the Scrum Guide and read for 30 seconds… we find this:

The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

Scrum Guide

Now, anyone with basic reading comprehension skills could draw the conclusion here that these two statements are saying exactly the same thing (the SAFe statement is aligned with the Scrum Guide). Especially if you read the entire Scrum Guide. More below.

It is the responsibility of the Dev Team to ensure the delivery of high-quality increments

Anti-SAFe petition

The quote above from the petition actually does not appear in the Scrum Guides. Now, if I wanted (which I wouldn’t ever attack people and a framework like they do; this is called defense) to stoop to the low level of the anti-SAFe folks I could also play twisted word games. The Scrum Guide actually NEVER states that the Development Team is responsible to ensure the delivery of high-quality increments. Wait, what? Yes. The emperor has no clothes!!

There are seven uses of the word responsible in the Scrum Guide and only two of those are referenced to the Development Team and NEITHER is about the statement in the petition. The Scrum Guide says the Development Team is responsible for estimates and conducting the Daily Scrum event.

Now, how many “SAFe zeolots” are out there creating petitions to remove poor understanding of Scrum from Scrum? Zero is the answer. But in their extreme bias and zeal to destroy people and a framework that are massively more successful than they are… judgment and intellect are clouded.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. 

The Development Team is responsible for all estimates. 

Scrum Guide

Further quotes supporting the SAFe translation (that avoids restating the Scrum Guide for obvious reasons) and disproves the “remove scrum people” arguments.

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes: …

also:
The increment must be in useable condition regardless of whether the Product Owner decides to release it.

also:
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

– Scrum Guide

However, the Product Owner remains accountable.

The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

– Scrum Guide

E.g. So, I am a manager of employees and I am accountable and responsible for the employees but I am NOT the person empowered to accept the employees as fit for the job. That is the argument of the Remove Scrum thinkers.

No person would accept that management job nor would leadership be setting the stage for success. That path leads to toxicity and bad culture.

So, in fact the opposite of the claims of the #removescrum -mers is true. If there is no clear leadership function on the team and the Development Team has the ultimate authority to accept work as done then an impasse and problem is created more often than not.

You have to take the entire document into consideration not part of it or just one word. The arguments of the Remove Scrummers lead to a PO that cannot bear enough influence on the backlog because they can only explain not break disagreements. This is why the guide says the PO is a manager of the backlog and is responsible and accountable for the backlog. This is also where the argument of the Remove Scrummers fails. They have self-contradicted from the source they claim supports their fallacious argument.

Now, I get that the goal is for the Development Team to have some independence from the traditional Taylorism and PHB. That is not absolute independence though and the argument of the Remove Scrummers stretches the intent of the Scrum Guide. The PO prioritizes and sets the stage for a set of PBI’s that the Development Team may select from to create a Sprint Backlog. The Sprint Backlog does not exist without the Product Backlog. They are not mutually exclusive.

At the review, “the Scrum Team and stakeholders collaborate about what was done in the Sprint.”

The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;

-The Scrum Guide

This statement uses the word explain because that is the actionable intent. Most cases will go exactly like that on a high-performing Scrum team. But not all. Sometimes there is disagreement about what is done and what is not done. Post-explaining the PO will have the ultimate authority and responsibility to determine what is done and what is not done.

For any rational person not hell bent on disproving and destroying the SAFe — this is a clear purpose and part of the PO role.

“Stories” in the Backlog

This word is one place that we could argue for an adjustment. Except that we are talking about Scrum and Agile behavior at scale. Oops, nevermind.

In the SAFe, we also discuss improvement items that are also in the Backlogs. They are not necessarily stories. Tasks are not recommended, but could also be a PBI in the backlog model. The concept of Stories comes from XP and the Scrum Guide does not use the term. It uses the generic product backlog item concept. Which easily translates to enterprise backlog models as we use in the SAFe.

Now, what is really interesting is that the Scrum apologists will argue for “pure” Scrum and it doesn’t include XP. In the same breathe, they will say that Scrum is Agile. So which is it? Immutable or not? Associated or not?

I have never seen or heard of a successful use of Scrum without good technical practices…like those we learn of in XP. Ruh-roh!! Also, and even more so, I have never, ever heard a Scrum team claim they were not Agile. Bazinga!

So it is ok for Scrum zealots to mutate Scrum and use it is intended, as a framework for managing a complex process but not anyone else? #hypocrisy

Extremists and the hate SAFe machine

Posted on

https://www.linkedin.com/feed/update/urn:li:activity:6532627335068299264

September 2019 trolls update

It seems that hate and jealously knows no bounds with some people. They simply cannot practice what they preach and be respectful, therefore diminishing any rational argument they would make. Here are a few new in the cast of characters that troll the SAFe with misrepresentations and outright hateful comments.

This was a random post from Alex.
Murali responds with this comment to a post from Scaled Agile at the SAFe Summit.
https://www.linkedin.com/feed/update/urn:li:activity:6585263102634311680?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6585263102634311680%2C6585372081599377408%29

The problem with trolls

I updated the title of the article. I have observed a pattern over the past year or so of Scrum Alliance aligned folks like Certified Scrum Trainers (CST) and other certified Scrum folks writing articles and posts of varying degrees of criticism from valid debates over ideas (rare) to mostly disparaging misrepresentations, to openly hostile, to outright extremist comments like the picture above. I changed the article title to properly address not all CST’s. The original title was meant to address the pattern observed by many people in the industry of several unnamed CST’s making hateful comments about SAFe and the people behind the SAFe.

Remember, hate comes in many forms. All of it is bad, and unacceptable. I’ve lost count of the number of people that I have known, loved, and like that have died or suffered from cancer (and parasites). Attributing those words to the good people behind the SAFe is absolutely abhorrent, evil behavior. The picture above is just the latest attack. So, I apologize for the original generalization.

There are also two parts to this article. The first part addresses the hateful opening comment from Alexey. The second challenges the misrepresentations of the SAFe. These are separate discussions. Debating ideas is necessary. We should not ever accept hateful words or behavior.

Why bother?

Let me start by explaining why I even bother debating with hateful people in the first place. Because we must confront evil in the world. Yes, at its root this is evil, misguided behavior. If we want to move ideas forward to innovation they must be challenged in a respectful, professional manner.

Anyone that starts out a conversation by saying you or your thing is a “cancer and parasite” isn’t actually looking for conversation. They are being hateful and are probably ignorant on the topic of debate. If this were a political topic then perhaps the bad behavior could be expected because it has been normalized for millennia. Does it make it right? Emphatically, no.

I find it disturbing that extremists and their ilk who are supposedly exemplars for the Agile Manifesto and values of Scrum openly display behavior that is antithetical to the Agile Manifesto and Scrum. After all, “RESPECT” is a value of Scrum. And the manifesto has a clear purpose, “We are uncovering better ways of developing software by doing it and helping others do it.

Read the rest of this entry »

When Scrum and Agile are not enough

Posted on

One of the more common anti-patterns of Agile adoption is the misconception that simply following methods such as Scrum will lead to development becoming ‘Agile.'”

© Scaled Agile, Inc.


I couldn’t agree more. In nearly every case over my 20+ year career that I’ve been invited to help scale business agility, “to become Agile – in behavior and nature”, in an enterprise the organization was already struggling with achieving agility using just Scrum and Agile. This is the basis of my often repeated statement, “Agile is dead.”

To my dismay, it is also common for the great technical and business practices and concepts from XP to not exist in the lexicon of the organization. Or, only part of XP is used, often incorrectly. It is shameful that Kent Beck’s work is not more prominent in the space. I’m glad to see that he is becoming more active again recently.

A better coaching approach (than simply proposing Scrum and Agile in a CAS) is to understand the market of tools, best practices, frameworks, et cetera and how to apply them appropriately without bias to customer context to drive better outcomes for the business or organization.

As a continuous learner, this is also why I have so much respect Alex Yakyma’s work with OrgMindset. Thinking tools are needed to properly apply and use complex tools in complex organizations.  Alex said something very important and interesting during our last discussion/debate about the topics of “Agile” tools and frameworks. Paraphrasing, he said, “I’m just using everything that I know and all of my skills and experience to help businesses make more money.”

This statement is important because often Agile zealots lose sight of the purpose of business – to create wealth – for the shareholders or beneficiaries of the organization. Agile and Scrum are not the goal.

Furthermore, we often forget that Agile and Scrum start out in a state of death. Agile and Scrum are literally just words on a page. They must be given life.

#scaledagile #scrum #agile #scaledagileframework #business #safe

Welcome to the Scream Guide

Posted on

Scream Guide Google Link

check out this awesome book of anti patterns.

Feature Progress Chart Template

Posted on Updated on

If you are a change agent, SAFe® Program Consultant, SAFe® Product Manager, STE, RTE, or practitioner you may find the Blogagility.com™ Feature Progress Chart Template a useful tool for kick-starting your product management (PM) implementation and Lean-Agile reporting.  Read the rest of this entry »

Learning how to Scrum master in SAFe

Posted on

Awesome experience with a great group of students eager to learn about Scrum mastering within a SAFe portfolio. I really love teaching this course. 28 folks were in the class and thirteen agreed to take the picture to be posted here on LI. Thank you, team! My co-instructor, Giuseppe B. (left), was also amazing, as usual, as expected for such a great guy! The team chose (self-managed) to use the “Build a house” simulation rather than stock context sim so it was great fun to learn about and experience the awesomeness of PI Planning and the enterprise backlog model while planning a $1.5M mansion.

The teams also experienced self-organization and self-management in this course as they aligned to a common mission, vision, and strategy for their “construction company ART.” They learned how to write and decompose great features and stories.

The students also get near constant teaching and reference back to the value systems of the Agile Manifesto, SAFe, Scrum, Lean, and Systems Thinking. We spend lots of time talking about cognitive empathy, Human Factors, CAS, and culture transformation using the AM goal of “We are uncovering better ways of developing software by doing it and helping others do it” as a foundation.

#SAFe #Scrum #Scrummaster

SSM2018SEP6_Guillory

 

Lean-Agile Team Metrics Starter Kit

Posted on

The fourth tool created to date by blogagility.com for the community!

This handy starter kit is for Scrum masters that are using the Shu Ha Ri paradigm for team development. Good coaches help new teams avoid the pitfalls of added complexity involved in “Agile Lifecycle Management Tools” and instead push for good old-fashioned manual BVIR’s, Kanbans, Scrum boards, et cetera. Change is hard enough in a CAS without adding to the problem by also complicating the way of working. Read the rest of this entry »