Doing a set of features in the _wrong_ order can increase the time to deliver by 300%.
Things like many-to-many relationships, data versioning, etc are easier to implement if they’re done earlier as opposed to done later, where they have to retrofit.
A non-technical PO having the authority to decide which features are done in which order is one of the biggest problems of scrum. Especially true in the first weeks/months of the project where critical infrastructure and architecture needs to be set up.
A PO can and often does undermine the developers’ ability by mandating them delivering the software in the least efficient way possible.
Good call. I tend to focus on the issues related to Product Owners dictating _what_ to build, but just as much or more damage can be done by messing up the _order_ in which it gets built.
In software engineering, ORDER MATTERS.
Let me say it again four more times:
ORDER MATTERS.
ORDER MATTERS.
ORDER MATTERS.
ORDER MATTERS.
Doing a set of features in the _wrong_ order can increase the time to deliver by 300%.
Things like many-to-many relationships, data versioning, etc are easier to implement if they’re done earlier as opposed to done later, where they have to retrofit.
A non-technical PO having the authority to decide which features are done in which order is one of the biggest problems of scrum. Especially true in the first weeks/months of the project where critical infrastructure and architecture needs to be set up.
A PO can and often does undermine the developers’ ability by mandating them delivering the software in the least efficient way possible.
Good call. I tend to focus on the issues related to Product Owners dictating _what_ to build, but just as much or more damage can be done by messing up the _order_ in which it gets built.