I got my Certified ScrumMaster (CSM) certificate back in 2004. To say that the class was influential was an understatement - on the industry level, it provided a common language and set of rhythms for enabling the principles of the Agile Manifesto. For me, it was a way to bridge the fun, integrated team feel of a startup and the needs of a larger company. It also provided a way to structure the communication between a client and a development team based on collaboration. Unfortunately, Scrum has a few weaknesses in an enterprise environment. The main ones we've seen over the years include:
- The "In Progress" status vastly oversimplifies things
- Larger organizations tend to hire specialists, not generalists
- Inexperienced and/or control-oriented project managers abuse the model, turning standups into status reports
- The combination of external team dependencies, burn down charts and sprint commitments turns deadly quickly; the commitments aren't met due to external impediments, destroying morale
- The focus on meeting commitments makes planning much more critical; we have seen several companies that adopted Scrum spending two entire days doing planning.
For the last few years now, we've been experimenting with Scrum combined with Kanban, aka Scrumban as a way to solve these problems; by and large it's been very helpful. Some of the key improvements include:
- Cycle time reports put management focus on process improvement.
- Columns allow for much better tracking of external dependencies - for example, you can track the amount of time lost to a recalcitrant operations team.
- Specialists and part-time work can be managed much easier
- We keep the two week rhythms, but the planning and estimation is baked into the boards - no more multi-day planning meetings.
If you are interested in more information about Scrumban, I highly recommend this (free) eBook by Henrik Kniberg & Mattias Skarin.