1. When you say "sign of pure incompetence" - on whose part? Architect, project manager, product manager? Team?
2. "Early scope cuts are a sign that you know what you’re doing". - is this really true? we can agree and descope something that represents pretty high value.
I agree with a lot of what you saying here. I would just add that a lot of this is contextual - is this a contractual commitment with a poorly managed customer who will scream "breach" if something is not delivered even if low value or are we building to learn - a new product, a rewrite etc where our goal is to ship something that powers the learning.
1. It depends. Speaking from experience, usually a powerful stakeholder that won't budge on something that represents a lot of work and then they do budge when it's clear it's a massive effort. I also think it's sometimes a mistake of how we set up the milestones we build, e.g. we add something early on that doesn't need to be added.
2. Early scope cuts can also be incompetent that's fair, but usually what's far more common (also curious to hear your experience), is that scope becomes bloated and lots of things become a must have.
Yes, you are right it is contextual, however, delivering as little scope as possible, and as much as necessary is the name of the game.
If we miss something, and manage optionality and reversibility well, we can easily add it later.
If we add many things we don't need that is a massive risk to optionality and reversibility.
And yes, if you have a fixed scope contract different rules apply.
I personally recently descoped a feature relatively early only to find out it really was essential because it helped to build trust in the system. We had to add it back and are actually working on it right now. I understand the scenario you are describing where a wishlist is mistaken for scope and that sets very high expectations if the team and its leadership dont control the promise.
Also, I also know the corporate setting where some parts of larger orgs operate under different approaches and release cycles. It can be changed but requires incredible effort and leadership buyin. The natural tendency then is to ask for the moon that includes even things that are not as important but because the window of opportunity is limited you are asking for everything. Just lived through something like this.
Last, it may be incompetency but it is also a specific form of incompetency. often enough teams will question the requests provided to them but especially in corporate settings with layers of decision making, everyone up the chain has to push back for this to bubble up high enough on the list for some senior stakeholder to consider removing something. The incompetency in this case is that a proper, time sensitive escalation path has not been designed and people do not have trust in the organization to skip organizational hierarchy and say something they want to challenge/cut directly to a decision maker.
All of this is from a point of view of someone working at a large company. Perhaps my experience is biased but this is what i observed first hand
This is a great post. A few questions :)
1. When you say "sign of pure incompetence" - on whose part? Architect, project manager, product manager? Team?
2. "Early scope cuts are a sign that you know what you’re doing". - is this really true? we can agree and descope something that represents pretty high value.
I agree with a lot of what you saying here. I would just add that a lot of this is contextual - is this a contractual commitment with a poorly managed customer who will scream "breach" if something is not delivered even if low value or are we building to learn - a new product, a rewrite etc where our goal is to ship something that powers the learning.
1. It depends. Speaking from experience, usually a powerful stakeholder that won't budge on something that represents a lot of work and then they do budge when it's clear it's a massive effort. I also think it's sometimes a mistake of how we set up the milestones we build, e.g. we add something early on that doesn't need to be added.
2. Early scope cuts can also be incompetent that's fair, but usually what's far more common (also curious to hear your experience), is that scope becomes bloated and lots of things become a must have.
Yes, you are right it is contextual, however, delivering as little scope as possible, and as much as necessary is the name of the game.
If we miss something, and manage optionality and reversibility well, we can easily add it later.
If we add many things we don't need that is a massive risk to optionality and reversibility.
And yes, if you have a fixed scope contract different rules apply.
I personally recently descoped a feature relatively early only to find out it really was essential because it helped to build trust in the system. We had to add it back and are actually working on it right now. I understand the scenario you are describing where a wishlist is mistaken for scope and that sets very high expectations if the team and its leadership dont control the promise.
Also, I also know the corporate setting where some parts of larger orgs operate under different approaches and release cycles. It can be changed but requires incredible effort and leadership buyin. The natural tendency then is to ask for the moon that includes even things that are not as important but because the window of opportunity is limited you are asking for everything. Just lived through something like this.
Last, it may be incompetency but it is also a specific form of incompetency. often enough teams will question the requests provided to them but especially in corporate settings with layers of decision making, everyone up the chain has to push back for this to bubble up high enough on the list for some senior stakeholder to consider removing something. The incompetency in this case is that a proper, time sensitive escalation path has not been designed and people do not have trust in the organization to skip organizational hierarchy and say something they want to challenge/cut directly to a decision maker.
All of this is from a point of view of someone working at a large company. Perhaps my experience is biased but this is what i observed first hand