From a leader in the agile process movement—learn best practices for moving agile development with Scrum from small teams to the enterprise. You get case studies and practical advice for managing change processes for applying Scrum to the enterprise. It's time to extend the benefits of Scrum—greater agility, higher-quality products, and lower costs—from individual teams to your entire enterprise. However, with Scrum's lack of prescribed rules, the friction of change can be challenging as people struggle to break from old project management habits. In this book, agile-process revolution leader Ken Schwaber takes you through change management—for you organizational and interpersonal processes—explaining how to successfully adopt Scrum across your entire organization.A cofounder of Scrum, Ken draws from decades of experience, answering your questions through case studies of proven practices and processes. With them, you'll learn how to adopt—and adapt—Scrum in the enterprise. And gain profound levels of transparency into your development processes.Discover how to: Evaluate the benefits of adopting Scrum in any size organizationInitiate an enterprise transition projectImplement a single, prioritized Product BacklogOrganize effective Scrum teams using a top-down approachAdapt and apply solutions for integrating engineering practices across multiple teamsShorten release times by managing high-value incrementsRefine your Scrum practices and help reduce the length of Sprints
Reviews with the most likes.
Amazingly, one can be considered an expert and still write a book based on the it-worked-for-my-friend's-company type of argument.
Supposedly, there's the following framework: if the company has some issues, we should just switch to Scrum and then follow it strictly. If there's something messing with our switch, we should call it “impediment”, fix it, and be happily sure that these impediments were the main issues in our company. The question of why this is the case is never discussed.
Well, maybe this book isn't supposed to convert me. So it quickly goes to the description of how one should transit to Scrum (create Scrum team that will guide other teams to Scrum; also, it should fix the impediments) and some discussion of possible problems. Then, there are solutions.
Scrum master (spelled as “ScrumMaster”) isn't good enough? Replace him. Product Owner can't cope with the backlog? Replace him. Team still works slowly? Replace everyone.
Legacy code is discussed for several pages in the most obvious possible way. Proposed solution? Fix it or deal with it.
Finally, there's redundancy, more redundancy and some redundancy again. Also, redundancy.
