I was priviliged to be an early reviewer for Ilan Goldstein’s book “Scrum Shortcuts Without Cutting Corners” and to also count him as a colleague and a friend. The Agile community in Australia is relatively small, so it is always exciting to see a book come out the community, particularly one that is part of one of the leading Agile Series by Mike Cohn. I was also honoured to be asked to provide a quote for the book. The following is my brief review and notes from the book.

Review

The following is my quote from the front of the book:

“If Scrum and Agile were easy, everybody would be doing it! Now that so many are, this book is the virtual Agile coach I wish I had when I was on the early steps of my Scrum journey. Ilan is a world-class coach, and he has packed this book full of ideas and approaches to all of the common questions and issues that are bound to come up as you transform your world of work to Scrum.”

–Craig Smith, Agile coach and editor at InfoQ

The book is broken into 10 chapters, each with 3 shortcuts each. It is written in a very easy to read and laid back style and feels like you are having a conversation with Ilan. It’s organisation means you can read the book from cover to cover of ad-hoc as a reference. It is clearly written with the Scrum Master / Iteration Manager as the primary audience, although it is suitable for anyone on the Agile team.

The key concept I really liked in the book was the notion of a Chief Scrum Master. As organisations begin to scale, it is a necessary role that is not always taken seriously. The book also covers the notion of One Scrum Master = One Team and deals with the ramifications and alternatives to this setup in a reasonable amount of pragmatic detail.

There were a couple of areas I disagreed with, mainly from an hybrid Agile approach as opposed to Scrum

• protected sprint – Scrum talks about the idea of a protected sprint so that the team can focus. I can see some merit for new teams, but in this day and age of constant change I much prefer working on the next highest priority and the kanban approach to focussing on one-piece flow
• sprint lengths – Ilan mentions that “1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks”. I have had a lot of success with 1 week sprints, particularly in business teams. Also, with teams adopting kanban, I have found 1 week sprints a good starting point. I have had some mainframe teams argue that they need 3 week sprints, but I personally find them too long.
• creating and estimating tasks – Ilan writes “break the PBIs into more granular technical tasks and to estimate each task to the nearest hour”. I find this a complete overkill and much prefer to have nicely sized cards of no more than 3 days. That said. Ilan has some good strategies for splitting stories in the book that I completely agree with.
• tracking time – further in the book, it is written “before going home each day, everyone on the development team should adjust the remaining time for any tasks they had been working on that day to ensure that up-to-date data is being fed into the sprint burndown chart.” As per the above point, I find this to be in most cases a useless metric, particularly if you cannot get the estimates from everyone in the team. In this age of #noestimates, I personally see this as an administrative overkill.

Overall, this is a book that belongs on any Agile pratitioners bookshelf as a trusted advisor or useful reference. As you become more experienced, this is the book you will definitely hand-on and recommend to your more novice colleagues as they take on the Scrum Master role.

My full book review and interview with Ilan and Colin is available on InfoQ.

Summary

Here are my key notes from the book:

Shortcut 1: Scrum On The Pitch

• protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session
• the idea of personal achievement is overshadowed by team achievement
• ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.
• Scrum promotes transparency as a core tenet

Shortcut 2: Fragile Agile

• Scrum is a framework not a method – Scrum is a framework of practices tied together by a small set of clearly defined rules
• a requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done
• sprint zero – artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint. The issue is inappropriate work is bundled into it that delays the starting of real sprints
• poor ScrumMaster selection – unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant

Shortcut 3: Creative Comfort

• important to ensure that everyone is feeling energized and excited about coming to work
• teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.
• when our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value
• basics for the environment: plentiful whiteboard and wall space, plenty of light, open desk space for each team, ample chair space, small round discussion table, readily available large meeting rooms, do-not-disturb zones, private areas, buffering from the noisier elements of the organisation
• developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit – keeping developers happy but also improving overall productivity!
• jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.
• the more passionate people are about their projects, the more likely they are to fully engage in them each day
• include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.
• a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Shortcut 4: Masterful ScrumMaster

• begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead
• 7 abilities: leading without authority, bring about change without fear, be diplomatic without being political, behave selflessly without downplaying the role, protect without being overprotective, maintain technical knowledge without being an expert, be comfortable never finishing, next generation leadership
• 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

Shortcut 5: Rock Stars or Studio Musicians

• we prefer attitude over aptitude
• teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield
• constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion
• the effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Shortcut 6: Picking Your Team Line-Up

• consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics
• everyone is a developer – Scrum views all development team members as equals and labels them accordingly with the collective title “developer.” – it is like being a medical specialist; irrespective of specialty, all specialists are still doctors
• Scrum team size – 5-7
• development team ratios – 3 programmers : 1 tester : 0.5 “deep specialist(s)”
• preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs
• in your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally
• have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team – treat the as consultants and trainers for the rest of the team
• one team = one ScrumMaster

Shortcut 7: Setting the Scrum Stage

• keep the team together for the duration of the project
• a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire
• work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration
• sitting together is the most effective way I know to build empathy
• overtime should be the exception, not the rule – symptom of a serious problem on the project,” not simply business as usual
• big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse
• as an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations

Shortcut 8: Plan the Sprint, Sprint the Plan

• by collectively resetting the goals for the upcoming sprint every few weeks, the team can start afresh rather than remain stuck on a seemingly endless treadmill of ongoing work
• ensure that the product owner (with relevant assistance) not only has determined the next priority requirements for the upcoming sprint but also has fleshed them out in just enough detail to allow the developers to get started
• 1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks
• don’t fall into the trap of believing that those who are dedicated full time to the sprint will be able to spend their entire working day on sprint-related tasks
• 7 Ps – proper planning and preparation prevents piss-poor performance

Shortcut 9: Incriminating Impediments

• anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle
• impediments – meetings of large magnitude, illness, broken builds, issues with the tools of the trade, unreliable supplier, unrefined product backlog, absent or unempowered Product Owner, incentive schemes focussed on the individual
• impediment ConTROL – Confirm, Triage, Remove, Outline, Learn
• an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment)
• you want clear visibility of all blocked tasks, irrespective of how temporary the block may be – spin the corresponding sticky-note 45 degrees

Shortcut 10: Structuring Stories

• an epic story is a user story that will take more than one or two sprints to develop and test
• not necessary to have detailed user stories for every requirement only the top-priority items that are going to be worked on in the next one or two sprints
• key is that stories should be written so that the customer can value them
• if you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks
• technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.

Shortcut 11: Developing the Definition of Done

• DoD becomes the governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as “done”
• we should be regularly inspecting and adapting the DoD
• acceptance criteria or DoD – comes down to whether the requirement is applicable to every user story or to a smaller subset of stories
• be realistic and get the ball rolling with a minimally acceptable DoD that everyone can live with

Shortcut 12: Progressive Revelations

• inspect and adapt the user stories under development on a day-to-day basis throughout the sprint
• typically a hands-on demonstration of the work requiring verification/validation, it usually occurs at the desk of the applicable developer

Shortcut 13: Relating to Estimating

• estimate to make trade-off decisions and help set goals
• relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing
• determine the effort required to complete a PBI using three factors: complexity, repetition, and risk

Shortcut 14: Planning Poker at Pace

• the issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example
• some teams adopt more abstract classifiers, such as T-shirt sizes – requires the extra step of mapping to a numeric value to enable forecasting during release planning
• ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation
• Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger
• important to circulate a small number of reference PBIs that correspond to the point levels in the card deck
• typically advocate removing the big cards (20, 40, 100, infinity) as well as the ½ card from the Planning Poker deck – fewer options equals less analysis paralysis
• group of PBIs will inevitably rely on some of the same important research or technical plumbing – underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them

Shortcut 15: Transitioning Relatively

• identify the smallest user story in the product backlog and designate it to be the initial ½-point story – this approach can certainly work, and it seems straightforward on the surface, but the reality is that it can end up taking considerably more time than you might expect
• map historical work to the new point scale system – identify, sort and stack, sizing up, subclassify, final filter

Shortcut 16: Bah! Scrum Bug!

• an issue is a problem that occurs during the sprint and is tightly coupled to a user story – not a product backlog item
• bug is a bug only if it is identified after a user story has been completed and accepted by the product owner – type of product backlog item
• unless a user story meets the definition of done, it might as well not exist as far as the customer is concerned

Shortcut 17: We Still Love The Testers!

• loss of identity fear – lose QA identity, lack of skills, won’t get support they need
• testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think
• pair testing (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer
• there will always be the need for manual exploratory testing that no level of automation is able to replicate

Shortcut 18: Automation Nation

• if your programmers are using TDD as a mechanism to write their tests, then they are not only creating a great regression suite, but they are using them to design high-quality, robust code
• functional testing is also often called acceptance testing. Perhaps one day we will call it user story testing, as the idea is to be able to test and automate the full end-to-end functionality of a particular user story
• integration testing is all about ensuring that new functionality is able to play nicely with the broader ecosystem and not just in isolation
• performance testing is to measure the operation of the product when under pressure, typically brought about by increasing the number of users and/or increasing the amount of data processing required
• recommend running a secondary build in the development environment (traditionally known as the nightly build) that is triggered manually and less frequently. The difference between the CI build and the secondary build is that the latter should be given the luxury of time, and therefore, it can include the full set of tests (including all of the heavier functional and UI tests that take significantly longer to run
• should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention
• while continuous delivery makes every build releasable to users, continuous deployment actually releases every change to users (sometimes multiple times a day)
• Scrum does not say that you must release at the end of every sprint, but it does say that you should do everything possible to have something releasable at the end of a sprint
• just start somewhere –  recommend that if you are new to automation, you allocate a percentage of your sprint capacity to chipping away at it

Shortcut 19: Metrics That Matter

• use them only for good, not for evil
• good metric – used as a signal to help the team identify roughly where things are at and, more importantly, as a guide to help the team inspect and adapt its processes to improve over time
• evil metric – used as an inflexible indicator for micromanaging an individual’s performance over time and, more importantly, for beating people up and killing morale
• meaningful metrics – sprint burndown, enhanced release burndown, sprint intereference, remedial focus

Shortcut 20: Outstanding Stand-Ups

• GIFTS – good start, improvement, focus, team, status
• stand-up ambassadors – act as observers in the other groups to pick up on any potential contention and/or lessons
• if you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling
• daily scrum is a simple concept, but without care it can quickly turn into a daily mess

Shortcut 21: Taming the Task Board

• colorful, sticky-note-adorned board has almost become the symbol of Scrum
• visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed

Shortcut 22: To-Dos for your Sprint Reviews

• sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate
• nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins
• demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team
• team should demonstrate only stories that meet the definition of done
• acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards

Shortcut 23: Retrospective Irrespective

• irony is that this session is most valuable when the pressure is on and/or when things aren’t running as expected
• without an atmosphere of openness, you will never get to the heart of issues; without courage, the team won’t be willing to confront problems head on; without respect, the team won’t present criticism in a constructive fashion; and without focus and commitment, the team won’t care enough to resolve the issues
• recommend a relaxed setting such as a coffee shop, a break room (if you have one), or even the kitchen area
• focus areas – communication, processes, scope, quality, environment, skills
• ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues
• circles technique employs an affinity mapping variation, bubbles technique requires each person to document on paper the three most urgent issues that he or she feels should be focused on pair and keep bubbling up the top 3 issues

Shortcut 24: Risk Takers and Mistake Makers

• to successfully implement Scrum, we must overcome a range of fears
• spend your time and effort helping those who are already enthusiastic
• the few bad eggs are often the ones who are most afraid of exposure
• Scrum turns software development into an open book where mistakes are clearly visible
• when openly discussing mistakes and vulnerabilities is the forging of closer bonds between team members

Shoprtcut 25: Perception is Reality

• you have a role as the ScrumMaster to keep the sponsor from blowing a gasket
• reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going
• sponsors become less upset when confronted with problems if they are involved in the resolution
• take the sponsor on a “Tour of the Task Boards” now and again
• never say no is a lesson that I have learned over time

Shortcut 26: Our Lords and Masters

• Chief ScrumMaster – facilitator of the ScrumMaster Community of Practice – training and coaching, challenge existing behaviours, provide and maintain tools, define and refine metrics, help establish communities of practice, ensure consistency, coordinate teams, ongoing Scrum promotion, developing the approach, company-level education, aligning the teams DoD, continual process improvement via Collective Retrospectives, impediment escalation, HR for the ScrumMasters, creating a physical environment conducive to Scrum
• ScrumMaster – process improvement, impediment management, diplomacy, coaching, managing change, maintaining the DoD, maintainin effective communication, updating artifacts, faciliating workshops, faciliating Scrum activities

Shortcut 27: Morphing Managers in the Matrix

• requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics
• intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager
• the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform

Shortcut 28: Scrum Rollout Reckoning

• you are either doing Scrum or not – it is binary
• Scrum is not a mechanical process… it is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival
• Benefield and Deemer used a simple survey based on the following six criteria: How much the team got done in 30 days; Clarity of goals—what the team was supposed to deliver; Collaboration and cooperation within the team; Business value of what the team produced in 30 days; Amount of time wasted, work thrown out, cycles misused; Overall quality and “rightness” of what the team produced
• Comparative Agility – teamwork, requirements, planning, technical practices, quality, culture, knowledge creation
• 3 questions – are your clients happier, are your team members happier, are your stakeholders happier

Shortcut 29: Eyes on the Prize

• development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done
• self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control
• ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one
• ScrumMasters should not become obsolete – impediments are never predictable, perfection is impossible

Shortcut 30: Shortcut to the Final Level

• if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle
• three words to remember from the book: transparency, inspection, adaption
• A Scrum adoption should be seen as a big collection of small experiments, wrapped up in a big experiment
• convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do