Why I'm done with Scrum

Me too. Good thing neither activity has anything to do with sprint planning.

People believe that they can "scale" Scrum to teams of 100s of people, in different locations, across time zones and with people who speak different languages and expect it to work the same. It wont and was not designed to.

Additionally, Scrum is not designed to handle unanticipated work. How many times will a team be working on a sprint when a fire happens, especially at a large company? The team needs to disrupt the sprint and handle whatever unplanned work it is, from a defect a major customer change request or whatever. The whole sprint gets thrown out of wack and what was defined as the ship requirements needs to be redefined on the fly. However, Scrum allows partially done work and if a new work item is injected at the end of sprint, the Q&A team may not be able to meet the new ship requirements of either the new work item or the rest of the sprint work.

With that said, Kanban was designed to not be a prescriptive process. Kanban is all about making small incremental improvements in WHATEVER YOU ARE DOING NOW. By visualizing work you are able to see where you are becoming overloaded and where blockages are occurring. By adding WIP limits and through pull instead of push you are helping to even out the flow of work and ensure that work is getting completed to 100% at a relatively constant speed. There are other aspects of Kanban that help, specifically metrics, the CFD, and swim lanes, but really with these two aspects, you can constantly visualize what is going on and figure out how to improve your work process on demand and in your own way.

While I am a big proponent of Kanban for countless reasons, many organizations cannot simply change overnight. Many organizations cannot grasp the concept of no time box and continuous deployment. Putting faith in the work ethic and self organizing capability of the developers doesn't jive with many companies (even though the studies show teams are much more productive when self-organizing). Other people, like the author, like the idea of iterations. In addition, many teams see great value in doing the retrospective. Lastly, the teams in the organization may have been trained in Scrum and been doing it for years. To all of a sudden change to something new can cause major disruptions in work and full on rejection and revolt.

For these types of organizations, I tell people to try Scrumban or Kanban with Iterations, whatever you want to call it. Teams can use Scrumban as a stepping stone to becoming more Lean or then can just use it going forward to improve and scale Scrum. Using Scrumban, teams can move slowly to self-organization and from estimating to prediction. They can handle injected work more easily and move to continuous deployment. Moreover, they reduce multi-tasking/ task switching and ensure a even flow of work.

For anyone wanting to learn about Scrumban, I send them to this video -> http://www.youtube.com/watch?v=0EIMxyFw9T8 It's an awesome video that is just over 6 min long. I don't know who these guys who made it are and am not promoting them but the video does the job well.