Sean Landis and the Salt Lake Agile Roundtable created a good list of traps and pitfalls of agile.
"Contrarians reject the majority opinion and often have personal reasons to degrade Agile. These writings often disqualify themselves through bias, thus failing to benefit the community. But non-contrarians - practitioners who tend to support the majority view - may be in the best position to drag the skeletons out of the closet."
1. Agile teams may be prone to rapid accumulation of technical debt. The accrual of technical debt can occur in a variety of ways. In a rush to completion, Iterative development is left out. Pieces get built (Incremental development) but rarely reworked. Design gets left out, possibly as a backlash to BDUF. In a rush to get started building software, sometimes preliminary design work is insufficient. Possibly too much hope is placed in refactoring. Refactoring gets left out. Refactoring is another form of rework that often is ignored in the rush to complete. In summary, the team may move too fast for it's own good.
This is a common problem discussed earlier here. Games can be impacted by design and art debt as well as technical debt.
2. Successful Agile development presupposes that team members will all act like adults. That's a euphemism for being competent and professional. Agile teams are expected to to accept a high level of responsibility and accountability. When they don't, things can fall apart really fast.
Don't expect everyone on the team to have the same level of competency and professionalism though. Teams need to have a mix. Teams will identify leaders that can mentor others on the team. However some teams can lack leadership and get stuck in the "storming stage".
3. Agile methodologies misunderstood may lead to team burnout due to an irrational culture of urgency. We even use the word sprint, a term that is not connotative of sustainability.
I really haven't heard of this or seen it. I suppose that we're a little battle hardened when it comes to crunch, so the constant level of urgency we see on Scrum teams doesn't seem like a big deal.
4. Agile requires more team and individual discipline, commitment and openness than a dysfunctional organization may be able to bear. Yet a dysfunctional organization is likely to place excessive hope in Agile as a silver bullet.
Oh yeah. This is a common one.
5. The high visibility on agile teams causes poor performers to stand out. The benefit is that the organization can take corrective action. In the absence of corrective action, poor performers may try forms of sabotage to avoid detection.
One of the biggest types of mistake I made would be "wishful thinking" about poor performers. These would be the people that team after team would reject. I would hold out hope for them to "turn things around"; maybe because they were smart or passionate about making games. In the end they always left (on their own or finally fired), but it always did more damage than it would have had I acted sooner.
You have to pull the band-aid off quickly to suffer the least pain.
6. Agile teams have a tendency to focus on tactical accomplishments at the expense of strategic goals. Missing the big picture can lead to long-term failure at the expense of sort-term success.
This is a problem for agile teams that think planning is unnecessary or who have a poor product owner. This leads to "incremental and iterative death marches".
7. Agile can be hard on the product owner who has a lot of responsibility. They are often asked to provide real time requirements support, make feature and business decisions, define acceptance criteria, and be constantly available to answer questions. The product owner is often responsible for understanding and communicating the needs of the customer and the company. This role can become a bottleneck because it is unable to "feed" the development team fast enough.
Yes! Large projects need a PO for every Scrum team.
8. Agile is over-hyped, thus leading to unrealistic expectations. People are led to believe agile development will solve all their problems with minimal effort and experience disillusionment when it doesn't meet their expectations.
Backlash from the silver bullet myth. I often hear the phrase "yeah, we tried Scrum on a project and the project failed, so now we....".
Scrum doesn't insure success. At best it creates transparency so you can make better decisions. If you choose the wrong project or the wrong team for a project, Scrum won't insure success; it will point these facts out to you quickly. If you decide that the problems can't be fixed and the project must be canceled early, that's better than waiting until the end.
9. A variation on The Blame Game can arise. A moderately successful agile development team usually will no longer be the bottleneck. Other departments can no longer blame development and this may give rise to a shift in political games.
This is absolutely true. Troubled development projects hide a lot of problems in the rest of the chain. Marketing, licensing, etc. can be caught flatfooted by an agile team that delivers at a far steadier pace.
10. Too much power can be granted to the product owner when it comes to steering the product. If they have an agenda, they can cause a lot of damage. Agile teams often seem to lack sufficient checks and balances.
Yes. A Product Owner who ignores the value of iteration can cause problems. You don't want to replace a plan on paper with a plan in someone's head. A Product Owner has to communicate their vision and react to the emerging game.
11. Agile is too programmer-centric leaving it unclear how to balance work across an organization. There is a need for better documentation and coaching for non-development participants.
This is the purpose of "Agile Game Development" and what I do.
Thanks to Jason Yip for pointing out the original post.