Scaled Agile Framework
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.
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 incrementsAnti-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.Scrum Guide
The Development Team is responsible for all estimates.
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:– Scrum Guide
The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
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
Economic thinking and principles
In the popular Scaled Agile Framework for Lean Enterprises (SAFe) we strive to “apply a comprehensive economic framework” through Principle #1: Take an Economic View. Certainly, part of how we deliver on this framework is through the natural decentralized decision making process that occurs when real Agile teams hypothesize their way through optimizing batch sizes, building quality in, and relentlessly improving. Breaking down work into slices of working software/deliverables/efforts that are potentially shippable (i.e. features) each iteration.
I believe that the dominant paradigm for managing product development is fundamentally wrong. Not just a little wrong, but wrong to its very core. It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing. I believe that a new paradigm is emerging, one that challenges the current orthodoxy of product development.Reinertsen, Donald G.. The Principles of Product Development Flow: Second Generation Lean Product Development (p. 1). Celeritas Publishing. Kindle Edition.
At scale, we apply the same core thinking to how we invest in Epics and Features. Run experiments.Read the rest of this entry »
There are a few Formula1 videos around the web that we use to teach about the economics of batch sizes, particularly in the SAFe, where the teachings of Don Reinertsen are embedded in the body of knowledge. I found this new video on LinkedIn today and thought I would share them with the community.
Remember, we are trying to reduce the transaction cost of a batch. In these videos the older pit stop people, process and tooling resulted in a much higher transaction cost compared to the modern pit stop with automated tools and swarming. This can be done through automation, architecture, tools, kaizen of process, and through new ways of thinking and working, and even new ways of feeling. We must pay particular attention to the relationship between tools, people, and process as optimizing one without tuning the others may not improve anything (systems thinking).Read the rest of this entry »
There is a bunch of Apple hype recently coming out of the most recent WWDC event, or perhaps all of them?. Like the new $6,000 cheese grater (super, sigh). I’m a bit of an Apple ecosystem fan so I noticed something in an article that we can use as an example for that common question SPC’s get from teams and Product Managers. How do I write a SMART PI Objective?Read the rest of this entry »
A coach shared this with me and I thought is was pretty good stuff. Here ye go in PDF format. Not from Cliff, but…
What is an acceptable pace of change for your organization? The root of all improvement lies in change. Should we go all out with unmanaged chaos, or manage change as part of a strategy through extensive controls? How does your enterprise identify and engage what the appropriate pace of change is? How do you balance change to affect positive business outcomes?
How fast does your company need to innovate to stay competitive?
Remember the wisdom of Jack Welch, “If the rate of change on the outside exceeds the rate of change on the inside, the end is near.”
The answer lies in the balance of new and/or improved thinking tools, ways of working, and even ways of feeling as an organization. Every organization is unique and therefore requires a unique approach to managing change. We can always start with existing ideas and tooling and fit to purpose. Choose wisely, and actively engage and match the pace of change to the needs of innovation.
I am particularly fascinated by Rimac and their explosive growth and ability to continuously and relentlessly improve and match the external markets demand for innovation.
“We need to change everything. The whole company changes pretty much every year. – Mate Rimac”
Company founder and CEO Mate Rimac takes you deeper behind the scenes than most journalists have ever been. And this is only the first episode of the four they’ve produced.
Someone who claims expertise in and loves to play the agile game of thrones recently posted an article on Forbes.com about the Scaled Agile Framework for Lean Enterprises (SAFe). Of particular interest the author took the time to denigrate the SAFe by knocking it for not having a focus on the customer. In fact, the author, Denning, specifically states that he is worried because, “the customer is almost absent.” Denning even went through the effort to point out that the SAFe “only” has the customer represented by this little icon in the Large Solution space.Read the rest of this entry »