“Cutting scope is not necessarily the same as cutting quality,” Linus Birgerstam, CTO of <weavy/>, said.
Scope creep is a common part of business, and is typically considered a negative challenge. But for the tech leader and his team at the white-label full-stack development framework, it can actually have the opposite effect: scope creep can highlight a potential area of improvement and reduce work the team may have to do further in the development process.
“Sometimes we realize the reason we’re seeing scope creep is because some features are redundant or only stealing resources from things that matter more,” Birgerstam said.
To better manage the unanticipated work and the steps needed to see a project through, the product development and project management teams set scope together. This level of collaboration offers the communication and transparency project managers need to work through business challenges and deliver clients the best product possible.
What proactive measures does your team take to limit or prevent scope creep?
We work with fixed deadlines. Right now, we utilize the six-week cycle as proposed by the “Shape Up” method. This practice means we have set cycles but variable scopes, which allows us to cut scope and deliver on time. Our whole team is involved in setting scope to make sure it fits “in the box,” so to speak. But naturally, we have to be in close contact with project managers so that they know what to deliver to the client at the end of a cycle.
The Shape Up method
When scope creep does occur, how does your team handle it?
We pose a couple of questions internally to decide how to cut scope, such as, “Can we ship without this?” or, “What happens if we don’t do this?” Sometimes we realize that the reason we’re seeing scope creep in the first place is because some features are redundant or only stealing resources from things that matter more.
What advice do you have for developers looking to better manage scope creep?
Cutting scope is not necessarily the same as cutting quality. Scope creep is there for a reason: it’s a sign that something is wrong with the project or that it just hasn’t been thought through. We may actually raise the quality of a delivery by cutting scope, while avoiding scope creep at the same time.
