Don't focus on frameworks
From the Manifesting Business Agility Blog
by Al Shalloway
This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.
Recent Posts
What is a Lean-Agile Coach?
My Approach to Sensemaking in Knowledge Work
Why if you are a PMP who understands the value of Agile your next workshop should be the Disciplined Agile Value Stream Consultant
My views (past posts) on cause and effect in complex systems
Transcend the thinking that scope, time and cost are in opposition to each other with Lean-Thinking
Categories
lean,
value streams
Date
SG20 says-If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration
Besides being prescriptive, pedantic, ¬ always the right thing to do, it illustrates how Scrum has us follow it instead of Lean principles
Almost all the Linkedin comments on this topic referenced Scrum, waterfall, the AM, even Lean. But none mentioned any established theory that might be useful. This is a behavior forming characteristic of frameworks- they tend to have ppl focus on the framework ¬ the theory on which the framework is based.
While Ken & Jeff finally acknowledge Scrum is a (partial) implementation of lean, they provide no Lean theory. These would help here:
1) delays in workflow and feedback cause waste
2) releasing something before it's ready causes waste
3) small batches are good.
What does this tell us?
1) don't release a PBI to production if it doesn't meet the DoD
2) if feedback would be useful, show it, but make sure the observers know that it's not done
3) strive for smaller items so you don't have any items partially done at the end of the sprint.
You may disagree, of course, but now we can talk about the real issues.
Posted on: November 23, 2020 03:28 PM |
Permalink
Comments (8)
Please login or join to subscribe to this item
Aaron Porter
Community Champion
IT Director| Blade HQ
Payson, UT, United States
I don't disagree with your final three points, but I do disagree with your argument; it looks at one point of the new guide and ignores the context of the whole guide. I wont pretend to know exactly what Schwaber and Sutherland meant or interpret the statement for them, but consider the following its a Scrum Guide, not THE ScrumBOK. Its roughly 10 pages of content that guides a lightweight framework for delivering value. It shares attributes with Lean, but is the guiding purpose of Scrum to be Lean? Do the authors need to provide theory on a separate methodology that is not fully embraced and can be found elsewhere?
Im laughing as I write the following if it was the ScrumBOK, it would be sleep inducing, hundreds of pages long, there would be debates about what the committee of authors meant, most people would not follow it 100%, and it would be accepted as the publishing organizations definition of Scrum, but not the only definition. Im okay with the Scrum Guide NOT being sleep inducing or hundreds of pages long. Am I going to follow the guide exactly? In spirit, yes. In practice, it depends. Ill guide the team (Product Owner and Developers), well inspect, adapt, and adjust to make sure we deliver value as best we can. If they decide theyre okay with demos for incomplete PBIs in order to get feedback, thats what well do. If the team establishes a minimum standard for Definition of Done and the PO doesnt want to see anything that doesnt meet the standard, thats what well do.
Your final points have merit and, Im sure, are and will be used by many companies. And I understand that, at some point, you have to stop debating and act. But I also believe that most companies would benefit from further discussion on the best ways they can deliver value, that this is an issue that merits further discussion.
Al Shalloway
Founder and CEO| Success Engineering
Edmonds, Wa, United States
i did not write this because of anything the SG20 says. It was just a furthering example.
I have beent ralking about the problems with frameworks for years.
I find it interesting that it seems 98% of the Agile community believe the options are either super light (aka simplistic) or overly heavy. There is a third option - some practices based on theory with a way to continuously improve.
I have long stated that frameworks are inherently flawed. See
Frameworks contrasted with Disciplined Agiles toolkit approach https://www.linkedin.com/posts/alshalloway_frameworks-contrasted-with-disciplined-agile-activity-6652238398411145216-dQ-r/
I'm in complete agreement with the authors rebuttal and the point made. We need to be cautious, proactive (case to case basis) in the scenario we are facing instead of blindly following the frameworks.
#saaa
Please Login/Register to leave a comment.
|
"I love deadlines. I love the whooshing sound they make as they fly by."
- Douglas Adams
|
