Agile – Agile Mindset

Debunking more SAFe® misconceptions 10x – The Scrum master

Posted on Updated on

In this short article we will prove the poorly crafted argument about the Scrum master role in SAFe incorrect as posited in the “Remove Scrum from SAFe” petition. I’m not really writing this to defeat the arguments presented in the petition because any rational person who looks into the details will come to the conclusion that the petition is 1.) wrong 2.) inconsistent 3.) factually incorrect. My goal here is more to take the opportunity to educate folks on the SAFe so that they will have more knowledge of how to use the #1 scaling framework in industry to improve business results and outcomes.

Read the rest of this entry »

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

Posted on Updated on

Remove Scrum supporters get Scrum wrong.

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

Tim Meyers: You’re too “by the Book!”

Posted on

Interesting article from a coworker.

You’re too “by the Book!”

Learning from the deep ocean of failure

Posted on

Well it’s Friday! Thank God! I get to go home to my family today!

Let’s talk about and share our failures. Not all of them, we don’t have that much time. BUT, everybody’s doing it! The ocean of failure is deep. I do more than my share to keep in full.

Yeah, I know some people never fail and will never admit it when they do. They will also likely not improve at a fast enough rate to stay competitive. My wife has helped me see this in myself over the past fifteen years. She is an amazing partner and mother to my four kids.

I’ll go first of course. The key here is to learn and improve. You don’t need to get personal, just enough to learn. And remember, praise in public, and critique in private. Let’s practice…

Recently I missed an important meeting because I didn’t pay enough attention to the time zone change (during my near constant travels). I feel horrible about it. It was an epic failure too. I was at the Verizon store transferring my phone service (crap — another story). I was distracted and thought I had two hours till the meeting. I completely bombed and forgot about the time change and dissed my VIP attendee.

Since then, I have improved and organized my various accounts and calendars to avoid this in the future. I also apologized profusely to my victim and offered repentance.

See that wasn’t so hard. I was lying. That was really, really hard. But we must learn in a world that shuns constructive feedback.

Now, how do you approach building this valuable pattern of openness, improvement, and empathy into and entire organization? Professional sports teams do it. Why are many enterprises stuck in perfection and failure is damaging to a career?

It all starts with individuals and interactions. At the tip of the spear we can begin to shape and build new behaviors. These new behaviors can be replicated in your team. Your team of teams (ART!), your division, group, and organization.

Start with a 1:1 working agreement with one of your coworkers to provide each other with completely transparent (a SAFe core value) feedback in the form of constructive criticism on a regular cadence. Choose someone that you interact with regularly. Agree to be respectful and honest. Create improvement items. Agree to keep your interactions completely discrete.

Grow from there to sharing your experience and growth with others on your team or organization. From there you can influence others to learn how to take criticism and feedback in a positive way.

Agile Online Summit 2019

Posted on

For those of you that are not aware of this great virtual conference, be in the know! It is that time again where Tom Henricksen is organizing speakers on all topics Agile, including transformation, scaling, tooling, and of course the Scaled Agile Framework for Lean Enterprises.

Yours truly and blogagility.com have supported the summit since 2017 and it has been a joy to work with Tom.

So, check out the schedule to be released soon and be sure to join all of the presenters in learning and growing your agile knowledge and skills.

Agile Online Summit 2019

#scaledagileframework #SAFe #agile #scrum #lean #systemsthinking #kanban #tps #leanthinking

Are You Asking the Right Questions? | LinkedIn

Posted on

I personally like to ask #3 in a slightly different way as a powerful question, “What are you willing to put on the table?” Which leads to interesting discussions with leaders.

Source: Are You Asking the Right Questions? | LinkedIn

How do you know if your Consultant/Coach has an Agile mindset? | LinkedIn

Posted on

Interesting topic. What do you do with “Agile” coaches who are incapable of displaying the values of Agile?

Source: How do you know if your Consultant/Coach has an Agile mindset? | LinkedIn