"Scrum Shortcuts Without Cutting Corners" by Ilan Goldstein is a must read book in a sea of Agile texts that delivers real world examples in the form of tactics, tools and tips on how to effectively implement and embed Scrum or Agile in your team or organisation. The book comprises of thirty shortcuts that are written in an easy to read, friendly, conversation style that can be read from cover to cover or as an ad-hoc reference.
Scrum Shortcuts without Cutting Corners is about sharing with you an approach rather than the approach to implementing Scrum.
The chapters and related shortcuts are as follows:
-
Scrum Startup - includes shortcuts on selling Scrum in your organisation, creating a healthy environment and pitfalls to watch for eary in your journey
-
Attitudes and Abilities - includes shortcuts on the seven key abilities that great ScrumMasters posess and selecting and assembling a great team
-
Planning and Protecting - includes shortcuts on setting good foundations, sprint planning and dealing with impediments
-
Requirement Refinement - includes shortcuts on stories, definition of done and conducting walkthroughs
-
Establishing Estimates - includes shortcuts on relative estimation, planning poker and transition from time to relative based estimation
-
Questioning Quality - includes shortcuts on managing defects, testing and automation
-
Monitoring and Metrics - includes shortcuts on effective metrics and hints and tips for useful stand-ups and task boards
-
Retros, Reviews, and Risks - includes shortcuts on sprint reviews, retrospective techniques and safe to fail environments
-
Managing the Managers - includes shortcuts on managing the perceptions of sponsors, the role of the Chief ScrumMaster and dealing with organisation structure and the roles of the project and functional manager
-
Larger Lessons - includes shortcuts on Agile maturity metrics, self organisation and moving forward to transparency, inspection and adaption
Each chapter is concluded with a wrap up that recaps the key points of each shortcut, which serves as a useful quick reference.
By the authors own admission, this book is primarily targetted at those in the ScrumMaster role (although is applicable to anyone interested in approaches to Scrum). In his shortcut entitled the "Masterful ScrumMaster" he offers the following advice for enthusiastic ScrumMasters to bring about change without fear:
When joining a new Scrum team, you should not rush in and change everything at once. Be patient; observe the environment, the current practices, the individuals, the team, the technologies, and the broader organizational landscape. Be a fly on every wall, and talk to as many people as possible. Even if your mandate is to jump in and totally “scrummify” the place, first gauge the readiness of those who need to be involved. You get only one chance to make a first impression, so if you strike before the optimal time, enacting change becomes that much harder.
He follows on with advice of a trap that a number of new ScrumMasters fall into:
ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions... Although not everyone can be a ScrumMaster, a ScrumMaster can be anyone.
One of the highlights of the book is where the author gives specific recommendations based on his own expereience, for example in relation to development team ratios:
When it comes to determining the makeup of the development team, there is certainly no one-size-fits-all rule because every project and team is different. However, if you have no idea where to start, to get you going, I suggest a ratio that I have worked with successfully on multiple occasions (although I highly recommend that you inspect and adapt accordingly: 3 programmers : 1 tester : 0.5 “deep specialist(s)"
A few things to note: You may have multiple deep specialists working on a single Scrum team. By deep specialists I mean those who focus purely on niche areas, such as database administrators, user-experience designers, and subject-matter experts. 0.5 doesn’t mean that I like working with pygmy specialists—it means that these developers split their time across two projects. We discuss this contentious suggestion a little more later in the shortcut. This ratio assumes a high level of test-automation maturity, leaving the tester to focus on the functions detailed in Shortcut 18.
Another example is the practical tips that the author gives for a ScrumMaster, for example when dealing with blocked tasks:
A typical block occurs when a task has a dependency that has been held up for some reason. A short, temporary block is a reasonably common occurrence and nothing to get too concerned about, because in most cases, other work can be taken on while the dependency is being taken care of. The important thing to note is that you want clear visibility of all blocked tasks, irrespective of how temporary the block may be. The way I like to track blocked tasks is to simply spin the corresponding sticky-note 45 degrees so that it looks like a diamond and stands out on the task board. This is a clear signal and allows you to immediately jump into detective mode to ensure that the block is removed as quickly as possible.
The author also gives examples of common traps that teams fall into (and how to avoid them), for example in relation to estimation:
I’m a fan of using the modified Fibonacci sequence because it helps to reflect the greater amount of uncertainty that exists as requirements get larger... while also avoiding the perception of precision (hence the change from 21 to 20, 42 to 40 and so on). That being said, it does come with a potential problem especially with new teams. If you recall from Shortcut 14, the point values should not correlate to a specific time or distance unit. The issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours... To combat this situation, some teams adopt more abstract classifiers, such as T-shirt sizes: XS, S, M, L, XL, XXL. I personally don’t use this extra layer of abstraction because it requires the extra step of mapping to a numeric value to enable forecasting during release planning…
The book also has a gentle sprinkle of humour (often disguised as a common frustration to the reader) backed up with a useful recommendation, like this example in relation to sprint reviews:
If your session is longer than an hour, I suggest taking 5-minute breaks every 45 minutes to maintain focus. But, be aware of the attention-deficit-disordered puppies who will get easily sidetracked and mugged in the corridors: don’t let them stray far. Also, although tough to enforce, try requesting that everyone submit their BlackBerrys (providing that RIM is still around when this is published) at the door. The only problem is that you may need to hire armed guards to pry those smartphones out of stakeholders’ hands! At the very least, you should announce at the start of the meeting, “For the safety of this sprint review, we request that you turn off all electrical devices.” Good luck and at the very least, think up a creative punishment for those whose phones ring during the session
The author is also not afraid to challenge the thinking of the wider community, like this thought in relation to retrospectives:
The broader Scrum community seems to be a little divided regarding the question of whether product owners should attend the sprint retrospective. Personally, I believe that they absolutely should attend because they form an integral part of the Scrum team. That being said, before your team becomes a well-oiled Scrum machine, there may be a few communication breakdowns, especially between the developers and the product owner. If you observe any tension, I recommend that in addition to the “official” retrospective session, the ScrumMaster should also conduct an informal one separately with the product owner.
Overall, this book is an entertaining and informative read that covers the full spectrum of traps and pitfulls that every Agile team and ScrumMaster inevitably find themself in. Whilst some in the Agile community may not necessarily agree with each recommendation in the book, it includes a large array of options that should appeal to the novice and expert ScrumMaster alike.
Recently, Ilan Goldstein spoke to InfoQ about the book.
InfoQ: Congratulations on the book! Where did the idea for Scrum Shortcuts come from?
Ilan: Much appreciated Craig. The book actually started as a blog and the inspiration simply came from my desire to be able to centrally answer real-world Scrum questions. In other words, I was just being lazy as I was frequently getting the same types of questions from friends and colleagues and I just wanted to be able to point them to an answer rather than repeat myself :)
InfoQ: The interesting thing about this book as it is not so much as a reference but more like having a virtual Scrum expert sitting next to you sharing their experience. What was your motivation for sharing these tips?
Ilan: I am clearly a Scrum enthusiast who wants to see this workplace-improving framework become prevalent. The issue that I was encountering was the fact that so many people were getting excited about Scrum as a concept and yet were really struggling with the real-world, day-to-day implementation issues. Unfortunately many of the books/blogs out there at the time weren't delving into this level of detail so I decided that this was an area I could help the community out with.
InfoQ: Who is your intended audience for this book and what is the main message you hope they take away?
Ilan: Originally the book was intended primarily for ScrumMasters who had started their agile journey but were still finding their feet. In other words, it was for those going through the difficulties getting Scrum up and running after an initial introduction. That being said I've received a lot of feedback from Product Owners, Developers and those on the Scrum periphery who have found the book to be of significant value, so I guess that now I would say that it targets anyone involved with a Scrum team who has received some level of fundamental training.
InfoQ: In the book you have some great advise for how teams can deal with impediments. Tell us about that?
Ilan: I've always treated impediments like wounds - they need to be dealt with but they don't all affect us in the same way. As such it is important to process them so as to not feel overwhelmed and considering that the world needs another acronym...I came up with one of my own: ConTROL:
- Confirm (what the impediment is)
- Triage (to decide on the priority based on impact)
- Resolve (either yourself or find someone that can)
- Outline (the impediment impact to the relevant stakeholders)
- Learn (to avoid similar issues in the future)
InfoQ: Many of the shortcuts in the book deal with people rather than process, and you state clearly we should value attitude over aptitude. What are some of the key people issues?
Ilan: One of the biggies is our industry's perceived desire to hire so-called 'Rockstars' and 'Ninjas' etc.; in other words putting all the focus and emphasis on technical brilliance rather than on the ability to be a great team player. I personally advocate for hiring 'studio musicians' instead - technically proficient folk who are able to easily fit into a versatile team and bring out the best in others.
InfoQ: The book has some great tips on learning from metrics as well as the Scrum ceremonies such as retrospectives and Sprint Reviews? These are often the first things Scrum teams shortcuts, how important are they in your opinion?
Ilan: Unless you enjoy the pain and suffering brought about by end-of-project post implementation reviews (aka post-mortems) then this incremental learning is paramount to the successful evolution of any Scrum team.
InfoQ: I admire the fact that you call out the role of management in a Scrum team. What is the role of traditional managers moving forward in an Agile world?
Ilan: To establish an effective Scrum environment, to support the ongoing efforts by being active in systemic impediment removal, ensuring technical consistency across Scrum teams as well as the usual HR related work.
InfoQ: So, is it one ScrumMaster = one team?
Ilan: I suspected you might ask this one :) My thoughts: New team = full-time (and then some...) role for one ScrumMaster. That being said, based on my personal experience, I have found that when dealing with mature Scrum teams in a supportive organisation, a single ScrumMaster can handle 2-3 teams (although 3 is pushing your luck somewhat).
InfoQ: The Agile world moves quickly – looking back is there anything in the book that you would change or wish you had the opportunity to include?
Ilan: Yeah, totally. I would like to talk more about handling production support, more on the Product Owner as well as Product Backlog Refinement. Perhaps I'll get a chance to write '(More) Scrum Shortcuts Without Cutting Corners' sometime soon :)
InfoQ: Which shortcut stands out to you the most as a tip that those on the Agile journey should take heed of?
Ilan: Ah you're looking for a super-shortcut hey? :) I don't know about any single one but my advice would be to remember three words: Transparency, Inspection, Adaptation. We will all start on a bumpy road but if you remember those words, you will uncover and resolve dysfunctions sooner rather than later and this will certainly make for a smoother longer-term journey.
InfoQ also caught up with Colin Tan who was responsible for the illustrations in the book and asked him a few questions.
InfoQ: You were the illustrator in the book?
Colin: Indeed :)
InfoQ: You work closely with Ilan day-to-day. Are the tips in the book closely matched to the messages you both give attendees of your training and coaching sessions?
Colin: Absolutely. In fact we give away free copies of Scrum Shortcuts in our public classes as a natural extension and companion guide for attendees to utilise following the courses.
InfoQ: Which shortcut stands out to you the most as a tip that those on the Agile journey should take heed of?
Colin: I'm going to go with 'Scrum on the Pitch'. The reason being that I think it's critical to be able to promote and understand the benefits of what we're doing rather than just mandating that we're doing this new Scrum thing just because it's the most popular buzz word at the moment.
About The Author
Ilan Goldstein is a globally recognised Scrum trainer and consultant with extensive experience working with start-ups, market leaders, government agencies, universities and public companies, all over the world to help improve their agility through the implementation of Scrum. He is the author of the ‘Mike Cohn Agile Signature Series’ book, ‘Scrum Shortcuts Without Cutting Corners’ (published by Pearson under the Addison-Wesley brand) and is a founder of both AxisAgile (an Agile training and consulting company based in Sydney) as well as Scrum Australia (a national not-for-profit organization focused on growing and enriching the Australian Scrum community). Ilan is a regular conference speaker, contributor to industry publications and blogger. For those interested in the alphabet-soup of certifications, Ilan is a Certified Scrum Trainer (CST), a Certified ScrumMaster (CSM), Certified Scrum Product Owner (CSPO), Certified Scrum Professional (CSP), Project Management Professional (PMP), Agile Certified Practitioner (ACP) and PRINCE2 Practitioner. In his spare time he volunteers for Compeer, the award winning, global mental health program.
About The Illustrator
Colin Tan is a Product Owner specialist who has worked with an array of diverse organizations of all sizes to create memorable user experiences and build products that users fall in love with. He has held the roles of Senior Business Analyst, Product Analyst, Product Manager and User Experience Manager before finally arriving at his true calling and passion, the role of Scrum Product Owner. He is the artist for “Scrum Shortcuts Without Cutting Corners”, a Scrum-focused book in the popular ‘Mike Cohn Agile Signature Series’ being published by Pearson Publishing. Along with being a Certified Scrum Product Owner (CSPO), a Certified ScrumMaster (CSM) and Agile trainer, Colin is also on the board of Scrum Australia, organisers of Australia’s national Scrum conferences.