Agile Project Management with Scrum

Author:          Ken Schwaber

Published:    2004

Publisher:     Microsoft Press

Paperback: 192 pages

Buy from Flipkart

Scrum is a widely used agile project management framework created by the author of this book Ken Schwaber in collaboration with Jeff Sutherland.  It is  used to manage complex development projects where the  requirements are frequently changing and there is a dire need to deliver good quality product within a short period of time. Scrum framework is simple  but appearances can be deceptive !  Implementing Scrum in an organization is not a trivial exercise. The  mindset of managing and executing projects in a traditional manner poses major challenges in effective implementation of Scrum.

This book contains over 20 real-world case studies drawn from author's  wide experience in implementing Scrum in the organizations he consulted. The problems described in these case studies are the ones which are typically encountered by the organizations who are in initial stages of Scrum adoption.

Hence I highly recommend this book for such the organizations since it can provide very useful insights and guidance to avoid the common pitfalls in their Scrum journey.

Key Insights and Lessons  from the Case Studies:

• Scrum Master has to balance the needs of both marketing and development departments.
• Product Owner by prioritizing the Product Backlog based on requirements with the  highest business value will be in a position to call for releases of functionality when the business benefit more than offsets the costs of implementation.
• A  team can successfully self re-organize itself  to deliver value if clearly told that it is responsible for managing itself and has full authority to do whatever it takes to meet the Sprint goal within the guidelines, standards, and conventions of the organization.
•  People tend to interpret Scrum within the context of their current project management methodologies without fully understanding - the underlying principles of self-organization, emergence, and visibility and the inspection/adaptation cycle; the paradigm shift from control to empowerment, from contracts to collaboration, and from documentation to code;  the subtle but critical shift from controlling to facilitating, from bossing to coaching.
• Hence It is important to have a well-qualified ScrumMaster to coach the team.
• While the ScrumMaster’s job is to protect the team from impediments during the Sprint, it is necessary  for him to operate within the culture of the organization. The ScrumMaster has to walk a fine line between the organization’s need to make changes as quickly as possible and its limited tolerance for change. When some changes are culturally impossible the ScrumMaster must accept the situation and focus on the things that can be changed rather than getting frustrated about things that cannot be changed.  
• Out-of-the-box Scrum doesn’t have practices that address the complexities of every project. Therefore  ScrumMasters should have an in-depth understanding of  the Scrum theory in order to  develop new /modified practices appropriate for the prevailing situation and also consistent with the theory. 
• ScrumMaster has to teach the Team to talk in terms of business needs and objectives, a language which a Product Owner can understand.
• While Scrum provides many opportunities to inspect a project and make the necessary adaptations to optimize the benefits, those responsible for making the adaptation must have adequate information on cost/benefit and assumptions data to make the best decisions.
• Scrum works only if everything is kept visible for frequent inspection and adaptation through Sprint review meeting, the Daily Scrum, the Sprint Backlog, and the Product Backlog. 
• Find a way to make Scrum understandable to everyone in his or her vocabulary. Some people want to understand Scrum and will track a projects’ progress in Scrum terms. Other people want to understand the project only in the traditional context. Adapting Scrum to their vocabulary eases the change from traditional processes to the Scrum process.
• The increase in productivity continues until a Team reaches seven people, give or take two. At that point, the shared work, vision, and concepts start to require additional support, such as documentation. Regardless of the scaling mechanism, above a modest number like seven, the productivity of a Team starts to decline, the miscommunications increase, the mistakes proliferate, and frustration grows. 
• Scrum relies on self-organization as well as simple, guiding rules. Depending on the situation either can be used as scaling up mechanism. When the complexity is so great that self-organization doesn’t occur quickly enough, simple rules help the organization reach a timely resolution. If self-organization occurs in a timely manner, it is preferable  to rely on it rather than forming rules. Sometimes the ScrumMaster can aid self-organization by devising a few simple rules, but it is easier for the ScrumMaster to overdo it than not do enough.