In my previous post, “The Scrum Master”, I spoke about how the Scrum Master recommended the book “The Power of Scrum” by Jeff Sutherland as a must read for anyone that needs an introduction to Scrum. That same day I purchased the book and the Scum Master was correct, it was an easy and absorbing read, and I finished it that same night.
The book is written as a story, almost a novel in form, about a CTO whose software development project is still not done after going over schedule twice. His clients are ready to fire his company and he just barely manages to get a final three-month extension.
The story quick moves on to him meeting a Scrum consultant in a bar and than follows the process of the CTO transforming his traditionally managed software development team into an Agile team using Scrum.
The book format manages to both be engaging and informative because the story format is compelling and easy to envision, but there is also a summary section at the end of each chapter starting in chapter two, that outlines the key learning points from the chapter.
There are a lot of summary points, but you only realize it once you are done. They never seem overwhelming in the context of the book. I cannot outline all of these points but here are a few key ones for me as I either hadn’t picked them up in other reading or they clarified details I was fuzzy one:
1. (#4 Pg 17) Scrum supports a development team by becoming completely flexible regarding the work in the next spring. In return the team needs to be completely inflexible regarding the work in the current spring, thus guaranteeing that they complete each Sprint.
2. (#8 Pg 17) It is the customer’s responsibility to make the developers understand what is needed. That requires frequent and intense contact. If a customer is not willing to make such and investment, then the project apparently does not add enough value for them to take it seriously.
3. (#3 Pg 28) The scrum team should be seven people, plus or minus two.
4. (#2 Pg 41) Using Scrum, the product is always ready. You are able to deliver a version of your product that is at most one Sprint old.
Another development that I found interesting was that the traditional Project Manager in the story had to take on a new role and had to abandon all of the traditional project management tools. The project was driven by the team members performing the work. The argument against traditional project management tools was that the planning process drove the project rather than communication with the customer and that there was an avoidance of true communication because it might jeopardize the carefully crafted project plan and create more work for the Project Manager. The PM was turned into the Product Owner. He was responsible for understanding the customers needs and wants and then for transforming them into the stories in the Product Backlog.
Overall, I got a lot out of this book and I would recommend it. I would like it if the other members of my team read it too, but if nothing else I feel that I can begin to explain the process.
Here is a little bio on Jeff Sutherland from QCon:
Jeff Sutherland, Scrum co-founderDr. Sutherland is a Certified ScrumMaster Practitioner and the inventor of the Scrum development process. He has been VP of Engineering and/or CTO for 9 software product companies, developing Scrum in 4 of them and introducing today’s standard Scrum methodology to 5 of them.As CTO of PatientKeeper and IDX, he used Scrum to capture industry leadership for mobile/wireless/web application platforms in healthcare, enabling physicians to enhance revenue, reduce cost, and improve patient care. Recently, he has evolved automated Scrum tools for real-time management reporting, while reducing Scrum project manager overhead to 10 minutes a day and developer administrative overhead to 1 minute a day. This is an order of magnitude more efficient than traditional approaches to project management.In recent months, Dr. Sutherland has been a Scrum consultant to Microsoft, Yahoo, Ariba, Cadence, Adobe, GE Healthcare, and M3 Media Services bringing PatientKeeper Scrum practices to the broader software industry.
Any other thoughts on the book? Any Project Managers out there who disagree with the way the Project Manager of the piece is portrayed?