14 Signs you’re working in a Scrum Feature Factory
This article was inspired by John Cutler’s ’12 Signs you’re working in a Feature Factory’.
The biggest problem with most Scrum implementations is not Zombie Scrum or Cargo Cult Scrum. The biggest problem plaguing Scrum is Product Owners lacking Product Management expertise.
Weak Product Ownership can only lead to very efficient Feature Factories powered by Scrum. Even if everyone understands Scrum really well. Product Management is the foundation upon which Scrum rests to deliver products of the highest possible value:
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment. — Scrum Guide
Scrum doesn’t provide Product Management expertise as part of the framework. It’s up to you to figure out. If Product Management principles aren’t applied, then there are no Product Management techniques to polish and improve through Scrum’s inspection and adaptation.
If you are not yet convinced, a more detailed argument to why Product Management is essential to delivering valuable products with Scrum is available here: Scrum sucks without solid Product Management.
How do you know you’re working in a Scrum Feature Factory?
- Sprint Reviews are just demos. Teams just show off what features they have completed, instead of showing how the released features are moving the needle on important user or business metrics. Nobody discusses during the Sprint Review how they can improve these features.
- Velocity worship. A higher velocity is always better, doesn’t matter what you actually delivered. Teams with a higher velocity are celebrated, teams with a lower velocity are punished.
- Teams work without Sprint Goals. Who needs Sprint Goals if the goal is to deliver everything that was planned in the Sprint?
- Scrum Teams are inflexible towards each other. Every team has committed to completing all features in the Sprint, so there is no room to help each other. Meeting the Sprint Backlog commitment of your team is more important than helping another team. Nobody goes into a room to discuss whether helping another team out would be more valuable for the company than completing your own Sprint Backlog.
- During retrospectives nobody ever talks about the customer or value delivered to the business. The main topic of the retrospective is ‘Did we deliver everything we promised?’. And if we didn’t, what can we do better to be more predictable? We’re in the feature shipment business and we get punished or rewarded based on feature timelines we meet. As a result nobody really cares if we actually are delivering value or not.
- Refinement is focused on building the thing right. Scrum Teams exert a lot of rigor to make sure Backlog Items are clear, well-described and estimated accurately. This means that they can verify what has been built to meet specs. Same rigor isn’t extended to make sure we are building the right thing.
- Eternal time spent in Sprint Planning. Accurate timeline of features is vital. More time spent in planning gives everybody a warm and fuzzy feeling of increased confidence to deliver what’s in the Sprint on time.
- Development Teams do not understand what value they are contributing to the customer or the business. Developers are just there to churn out features. Leave the thinking about our customers and business to others who are outside of the team.
- Product Backlog is refined and estimated many months ahead of time. Everybody wants to have estimates for their feature many months before you actually start working on it, so everybody can become giddy when they look at the big Feature Factory masterplan.
- Feature-based roadmap with specific timelines and a horizon greater than 6 months. Since we’re only operate in the realm of features without trying to understand our customers and their problems, all features get decided up-front without research or experimentation. We already know what we will need to be working on in 6 months from now.
- Development Teams are excluded from Discovery work. Developers need to code and should not waste their time on frivolous matters like doing experiments and research to understand our customer or business better.
- Technical debt gets swept under the rug. Stakeholders don’t see the technical debt and only see whether their feature is released on time. As a result, if estimates are off, which they invariably are, teams are forced to cut corners to meet timelines. By the time the feature is done, a new feature needs to be delivered on-time and there is no more time to refactor what was delivered before. The feature factory has to keep on churning!
- No room for learning. Everything gets planned ahead of time, which basically means there is no room to learn and adjust your plans based on what you’ve learned. Follow the list, you’re not paid to think!
- Features never get removed and polish rarely gets added afterwards. Once a feature is live, everybody takes a deep breath and jumps on the next big thing someone wants to have. There is no time to revisit and do rework to make something great instead of bad, mediocre or good.
The problems that are surfaced by the above may not have an immediate fix. For some of these issues, I’ve written articles before that might help you to solve them:
Do you want to write for Serious Scrum or seriously discuss Scrum?
