"However, the use of DoR can limit the PO's ability to pivot and make changes that increase value for the organisation"
I don't agree with this. A product team shouldn't be changing focus all the time at the drop of a hat, if you are then that's a pointer to look into why that's happening. There should be enough lead time for a PBI that the PO/PM can create the level of fidelity that the team expects. Of course there are exceptions but there shouldn't be a scenario where the PM/PO is coming to the team with an urgent pivot that has to be worked on immediately.
Blaming an artifact like DoR for this is not right.
I am not saying that a team should change at a drop of a hat in this post because there are issues around focus and context switching. This particular reason as to why it is an anti-pattern is more the team rejecting work in the name of "It is not ready" when it is clearly the highest valued and most important thing for the business.
Dan, I hope you see we are more aligned than not.
There are other anti-patterns as to why DoR, I will post them in the future.
And yet a definition of ready that is pragmatic and fit for purpose will enable good flow.
And good flow increases the confidence to make the decisions you need to make when inspecting and adapting.
But how a DoR is used is the key. Anything that externalises essential goals of the product owner from the development team will impede both flow and effective inspect & adapt action.
I agree with your comment on DoR in this context. Based on only this post, I cannot say anything else except 'you are right'.
This is just one of many reasons DoR is an anti-pattern and I will be posting the others too. A post for you may want to watch out for is around what DoR should be. You will see that what it should be is so simple and obvious for any professional team that writing it down as a formal DoR is wasteful.
"However, the use of DoR can limit the PO's ability to pivot and make changes that increase value for the organisation"
I don't agree with this. A product team shouldn't be changing focus all the time at the drop of a hat, if you are then that's a pointer to look into why that's happening. There should be enough lead time for a PBI that the PO/PM can create the level of fidelity that the team expects. Of course there are exceptions but there shouldn't be a scenario where the PM/PO is coming to the team with an urgent pivot that has to be worked on immediately.
Blaming an artifact like DoR for this is not right.
I am not saying that a team should change at a drop of a hat in this post because there are issues around focus and context switching. This particular reason as to why it is an anti-pattern is more the team rejecting work in the name of "It is not ready" when it is clearly the highest valued and most important thing for the business.
Dan, I hope you see we are more aligned than not.
There are other anti-patterns as to why DoR, I will post them in the future.
And yet a definition of ready that is pragmatic and fit for purpose will enable good flow.
And good flow increases the confidence to make the decisions you need to make when inspecting and adapting.
But how a DoR is used is the key. Anything that externalises essential goals of the product owner from the development team will impede both flow and effective inspect & adapt action.
I agree with your comment on DoR in this context. Based on only this post, I cannot say anything else except 'you are right'.
This is just one of many reasons DoR is an anti-pattern and I will be posting the others too. A post for you may want to watch out for is around what DoR should be. You will see that what it should be is so simple and obvious for any professional team that writing it down as a formal DoR is wasteful.
Watch this space 😅