Myths, myths and myths everywhere
During the past few years, as a Scrum.org trainer and DevOps coach I have had many opportunities to interact with some of the best and brightest of the industry. At the same time, I’ve also interacted with some people, teams and organizations which somehow got into the trap of believing some myths of our industry. I’ve listed some of these Scrum, Software Development and Agile myths based on what me and my colleagues at Scrum.org have seen.
Do you recognize some or all? Do you have more to add? Do you disagree with me on any of these? Do let me know in comments.
- Scrum is the silver bullet that can make any project finish on time.
- Scrum can put your project to failure.
- Scrum should be changed to fit your company. (Note: Scrum is a framework, it can be adapted but no changes to it its core essence)
- Product Owner can accept or reject increment.
- Scrum is suitable only for small projects.
- Scrum does not work for remote teams
- Scrum only works for mature team members
- Kanban is more flexible than Scrum
- Scrum does not work for fixed price projects
- Tester does not have any role in Scrum
- Scrum Master is a project manager in Scrum
- Scrum (or any part of it) will never work here
- Our project/product is different. Scrum is no good use here.
- Scrum doesn’t work when there are too many dependencies between teams
- Scrum can’t work if you don’t change performance appraisals, incentives, etc
- Scrum doesn’t work if your software runs on hardware
- One PO cannot possible handle X teams (where x is some number larger than 2-3)
- Scrum can’t/shouldn’t be used for ‘maintenance teams’ / Kanban should be used for maintenance/brownfield/legacy teams
- Scrum is just Waterfall done more often
- Agile teams don’t do any planning
- Agile teams don’t do documentation
- Agile teams are cowboys where you don’t have any control over them
- Pair Programming is someone watching over my shoulder
- If we skip documentation, we are Agile
- Agile ignores risk
- Agile doesn’t believe in any metrics
- Agile requires no management
- Agile requires no experts
- Agile means no deadlines
- Developers can’t talk to customers
- Programmers cant be trusted to test their own software
- Bugs/Production emergencies are always going to happen
- Test Automation is too expensive and too hard to be worthwhile.
- Record and playback is best way to automate your tests.
- We have to be able to fix schedule/scope/cost to keep customers happy
- Adding people to a project that is running late will get it back on schedule
- We don’t have any way of getting customer feedback
- Schedule, Scope, Cost is a great measure of software success
- We’re doing Scrum, so we don’t need to do TDD and Pair programming
- Only the testers do testing. Testing is not my(programmer/analyst/architect) job
- The architecture/design must be done upfront
- Only the BA writes requirements. Requirements are not my(programmer/tester/architect) job
Do you recognize any of these? Agree/ disagree – Do let me know via comments!