Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips Book Review

The first thought that came to mind when I saw this book was, "Uhg, another Scrum book, you've got to be kidding me." Then the title of Scrum Shortcuts really gave me a sickening feeling. The majority of the Scrum teams I have watched work do nothing but take shortcuts. They sure as heck don't need a book on how to take more of them!!! Luckily, throughout the book, the rest of the title holds true - without Cutting Corners. Personally I would have titled the book "Agile Tactics, Tools, & Tips for Real Scrum Teams - No Poseurs Allowed". One of the first things the author covers is the Scrum sales pitch. He points out that it is a pretty simple sale to make. I have witnessed that personally several times. I was sitting in a meeting some time ago with a company that was embracing Scrum like a ten year old being offered a warm plate of chocolate chip cookies. They were grabbing at it as fast as they're little hands could reach out and grab the goodies. Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time within budget. In past years they refused every single proposed process improvement recommendation made by dozens of consultants. They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. What I like most about this book is that it is really down to earth. The author does not pull punches when it comes to pointing out that it might be easy to sell Scrum, backing up your pitch with a highly effective Scrum implementation is a very different story. The team I mentioned above crashed and burned after a few months. They were still using Scrum vocabulary, but were the farthest thing from an effective Scrum team as you could get. The author hits it on the head with shortcut 2 when he says -- one of the most frustrating comments that I hear when speaking to novice software teams is, “We do Scrum—we work in sprints, we have a daily scrum, and we even have a product backlog.” In addition, although they may not explicitly say it, you can often add, “We don’t write any documentation, we release haphazardly, we plan on the fly, and we don’t care about buggy code because we’ll just fix it up with a bug iteration.” ARGH! These people give Scrum a terrible name, and worse still, when their projects inevitably fail, it is very difficult, if not impossible, to win back the senior stakeholders who have been burnt by a badly warped Scrum implementation. The author packs a ton of wisdom into this fairly short book. I have listed the chapters below with the shortcuts they contain. Chapter 1. Scrum Startup Shortcut 1: Scrum on the Pitch Shortcut 2: Fragile Agile Shortcut 3: Creative Comfort Chapter 2. Attitudes and Abilities Shortcut 4: Masterful ScrumMaster Shortcut 5: Rock Stars or Studio Musicians? Shortcut 6: Picking Your Team Line-Up Chapter 3. Planning and Protecting Shortcut 7: Setting the Scrum Stage Shortcut 8: Plan the Sprint, Sprint the Plan Shortcut 9: Incriminating Impediments Chapter 4. Requirement Refinement Shortcut 10: Structuring Stories Shortcut 11: Developing the Definition of Done Shortcut 12: Progressive Revelations Chapter 5. Establishing Estimates Shortcut 13: Relating to Estimating Shortcut 14: Planning Poker at Pace Shortcut 15: Transitioning Relatively Chapter 6. Questioning Quality Shortcut 16: Bah! Scrum Bug! Shortcut 17: We Still Love the Testers! Shortcut 18: Automation Nation Chapter 7. Monitoring and Metrics Shortcut 19: Metrics That Matter Shortcut 20: Outstanding Stand-Ups Shortcut 21: Taming the Task Board Chapter 8. Retros, Reviews, and Risks Shortcut 22: To-Dos for Your Sprint Reviews Shortcut 23: Retrospective Irrespective Shortcut 24: Risk Takers and Mistake Makers Chapter 9. Managing the Managers Shortcut 25: Perception Is Reality Shortcut 26: Our Lords and Masters Shortcut 27: Morphing Managers in the Matrix Chapter 10. Larger Lessons Shortcut 28: Scrum Rollout Reckoning Shortcut 29: Eyes on the Prize Shortcut 30: Shortcut to the Final Level The author's realistic view of Scrum is a refreshing one. He is not one of the many Scrum zealots, mindlessly regurgitating Scrum mantras and bashing every other process that came before Scrum hit the mainstream. He presents a realistic view on how difficult Scrum is. Scrum is not easy and the author makes that very clear. Shortcut 5 was the only one I felt was a bit off. He made his point, but I have had a different experience with people. Maybe because I have family members that are Rock Stars and I know the best musicians are those that can handle being a rock star on tour, but also make excellent studio musicians. They put on the show for the live fans, but also lay down the tracks for their producers. In order to be successful in both roles they need to have the confidence to play live and be humble enough to let someone else guide them through the creation of a record. They are also team players in both roles. I think shortcut 5 would have been better explained as the No A-hole Rule. I personally have met many more unskilled arrogant people, than I have highly skilled arrogant people. The unskilled people are usually insecure in their abilities, so they attempt to camouflage it, which comes off as defensive or arrogant. Chapter 3 touches on team stability and working environments. Since I left the electronic engineering field I have not had an office with a door except at my home office. I have sat at tables where all the printers were for the office. The printing noise wasn't bad, but the people standing around talking, waiting for the slow printers, was a problem. At work I am currently in a cube that is noisy 25% to 75% of a given day. I share it with one of the main application support guys on our team, and he often has a line waiting to see him. While they wait I am an open target for them to kill the wait time talking to me. Another thing about the office is they keep it hot in the winter and hot in the summer. I have to keep a fan blowing on me and by the end of every week my eyes are wind burnt and bloodshot. My chair I have at work has me going to the chiropractor. They were going to buy us new chairs, but discovered they were too expensive, and we aren't allowed to bring our own chair in. I work from home on Mondays. My home desk provides me twice the area I have at work. I have the room at a cool 68F. I have a great ergonomic chair. If I get a call I can put it on speaker phone, instead of having to hold it to my ear with my shoulder. Context switching is always a big problem. The book refers to it in the context of fractional assignment. I work from home on Mondays and I would estimate I get 20 - 80% more work done on Mondays than any other day of the week because I have the isolated environment I need to think. To get hold of me people IM, email, or call if needed, but I can queue them until I am done with what I am working on. At the office if you don't answer right away they come to your cube and interrupt your thoughts. Once you start context switching like a pinball you become ineffective at everything. Some days are just fire days. I would have literally been a day ahead of where my day ended if I would have just called off. I thought that every chapter in this book contained wisdom worth reading and learning. Two chapters that stand out are Requirement Refinement and Establishing Estimates. Of all the problems I see with Scrum teams these two things are always a big problem. They are never properly address because the misconception that requirements change all the time in agile environments, and therefore the timelines change too, seems to be a mantra of immature teams. Scrum is not a one size fits all process. The author does a great job of pointing out that it is a framework. Scrum would be a fine team level project management process for one of the projects I am currently on, because the developers on the team are awesome. We are actually not using any defined process. The reason for that is the primary developer builds everything with modifiability in mind and we have very solid requirements. The architecture make use of some very well-known patterns and open source libraries that including MVC, DI with Unity, repository, unit of work, using Entity Framework 5. Architecture done right allows for agile practices to happen without effort. The developers code the project and I document it by creating a Developer's Builders Guide. As a team of 3 that has worked together often, and with solid requirements in place, we just build it. Other projects I have seen that do not qualify for Scrum alone, are some of the large COTS and development projects that have requirements that are not just fluid, but are like a Class VI rapid. They need the structure of Disciplined Agile Delivery or the Scaled Agile Framework (SAF). These processes can use Scrum as the development management process, but they supplement it with architectural and enterprise level activities. Over all this is a great read. The author’s writing style makes this a pleasure to read and he crams a lot of wisdom into 200 pages. I would recommend this book to anyone involved with Scrum in anyway. Do not be lured in by the desire to find a silver bullet process, there is none. Books like this can give insight into what you are up against before you have to learn the lesson the hard way, by going through it yourself.

Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips