Project Management

Don't focus on frameworks

From the Manifesting Business Agility Blog
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.

About this Blog


Recent Posts

Cause and effect in complex systems

Going after "simple" Is both a red herring and the cause of much Agile adoption failure

Understanding Simple Isn’t Simple

Minimum Business Increments (MBIs)

Empiricism and empirical process control are not the same thing

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, &not 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 &not 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
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.

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

Thanks for sharing

Thanks for sharing

Thanks for sharing

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.


Please Login/Register to leave a comment.


"Why is it that people rejoice at a birth and grieve at a funeral? It is because we are not the people involved."

- Mark Twain