Essential Agile and Scrum books

Essential reading

'Coaching Agile Teams' by Lyssa Adkins (link)


'Agile Retrospectives' by Esther Derby (link)

'A Scrum Book: The Spirit of the Game' by Jeff Sutherland, James O. Coplien et al (link)

'The Scrum Princess' by Kyle Aretae (link)


'The Lean Startup' by Eric Ries (link)

'The Phoenix Project' by Gene Kim,  Kevin Behr, George Spafford (link)

'Scrum: The Art of Doing Twice the Work in Half the Time' by Jeff Sutherland (link)

'Scrum: A Pocket Guide' by Gunther Verheyen (link)

'Agile Testing' by Lisa Crispin, Janet Gregory,  (link)

'Agile Estimating and Planning' by Mike Cohn (link)

Honourable mentions

'The Five Dysfunctions of a Team' (Manga Edition) by Patrick Lencioni (link)

'Scrum Product Ownership' by Bob Galen (link)

'Making Work Visible' by Dominica Degrandis (link)

'It Doesn't Have to Be Crazy at Work' by Jason Fried, David Heinemeier Hansson (link)

'Scrum and XP from the Trenches' by Henrik Kniberg (link)

'The Scrum Field Guide' by Mitch Lacey (link)

'Scrum Mastery' by Geoff Watts (link)

'The Coach's Casebook' by Geoff Watts (link)

'The Way of the Web Tester' by Jonathan Rasmusson (link)

'Training from the Back of the Room!' by Sharon L. Bowman (link)

Dedicated Scrum Masters

The SMs I've worked with who've had the most positive effect on a team (performance, safety, empowerment, etc) were dedicated to the SM role. Everyone I have spoken to who has worked with a competent dedicated Scrum Master agrees. 

Every 'Developer as Scrum Master' (DSM) I've worked with has been far less effective. They can keep things ticking over but in my experience the DSMs put much more into the Dev role.

The real test is when a crisis happens: 

• Do they go into SM role? Do they focus on facilitating the urgent re-planning and discussions? Do they work to ensure safety so that the Developer's don't work silly hours?
• Or do they go into Developer role? Are they active in tech discussions and drawing on the whiteboard? Do they put in extra hours coding?

The DSMs I know would go completely into Developer role in a crisis and drop most Scrum Master duties in the process!

But it is more than this. DSMs are more likely to look at Stack Overflow for a coding issue rather than read a Scrum.org blog post about a team issue. They do code show-and-tells more often than run workshops teaching Agile supporting practices. They more often step in to the role of the expert telling the team rather than the active listener asking powerful questions.

The Head-of-department Scrum Masters I've know have had some success on tactical issues (impediment identification, not over-~committing~forecasting in Planning, etc) but have not really been really effective as regards kaizen and taking the team to the next level.

Un-Done work at Sprint end

Having un-Done work (items pulled into the Sprint but not Definition of Done at Sprint end) can be demoralising and prevent the team achieving a stable velocity. Many Scrummers ask, how do we account for this un-Done work, should it be re-estimated based on what is left to do or based on its new larger size?

If this happens only occasionally, go with the Development Team members' gut feel (e.g. spend five minutes per item estimating the impact in Story Points using poker) and move on. It will merely be a blip and the average velocity will balance things out. No biggie.

But if having un-Done work at the end of a Sprint occurs regularly, rather than merely treating the symptoms ("How to we account for carry-over of un-Done items?"), look to cure the disease ("How do we prevent un-Done work arising?") .

Symptoms to look for:

• No Sprint Goal. One the most effective patterns I can offer Scrum Teams it to start planning Sprints around Sprint Goals.
• The Sprint Goal contains connectives. For example: "Make services run on SQL Server and make the website open nicely in Chrome on Android and support features necessary for population genetics analysis." Clearly the two 'and' connectives strongly indicates there are three goals in this case.
• The presence of many items in the Sprint Backlog that do not relate directly to the Sprint Goal. What percentage of the items in the Sprint Backlog should directly relate to the Sprint Goal? While I think the value should be high, 100% may be idealistic and not practical.
• The team doesn't spend much/any time on 'Topic Two' during Sprint Planning. Take a look at the Sprint Guide section on 'Sprint Planning'. In my experience, the average Scrum team spends very little time on Topic Two.

Actions to cure the disease:

• Shorten the Sprint cadence. This suggestion might seem counterintuitive but I've personally had success with it. Shorter periods of time are easier to plan, which is why we do Sprints in the first place. It also reduces work in process (WIP) which helps teams focus on getting items to Done.
• Coach the team (or perhaps just the PO) on effective Sprint Goals.
• Teach the team to leave Planning with a plan. Yes, we favour responding to change over following a plan but we still value having a plan! Topic Two of the Scrum Guide outlines what such a plan should be.
• Coach the Development Team members on protecting the Sprint Goal by renegotiating the items on the Sprint Backlog mid-Sprint (reduce a PBI's scope, swap it for an alternative/smaller item, remove it from the Sprint Backlog, etc). Teach the team to refer to the Sprint Goal when they speak at the Daily Scrum. Make clear that a Sprint Goal without connectives is easier to protect.
• Ensure the Devs are making transparent which items are at risk of remaining un-Done and doing so early enough in the Sprint to allow renegotiation. A few of days before the Sprint end, the Scrum Master can take a confidence poll to identify items that are at risk of being un-Done. The team should discuss these items at Daily Scrum and adapt the Sprint plan accordingly.

Participation at Scrum Events

The best Sprint Retrospectives I have been part of have involved all team members bringing data (key occurrences, reactions, feelings ideas to try, etc), participating in analysis of the data to gain insights and agreeing actions to which all team members can share (and hold each other to account when agreed action is not taken).

The best Sprint Reviews I've attended have involved all team members taking pride in the increment they have delivered, telling the story of each item to stakeholders, taking note of feedback and standing together as a team when things haven't gone according to plan.

The best Sprint Planning I've experienced has involved everyone in the team playing their roles: listening to the PO's Sprint Goal, pulling in items from the Product Backlog that would best fulfil the Goal, possibly negotiating with the PO to possibly revise and split items, then formulating a plan on how each items will be turn from idea into Definition of Done as regards the various functions within the team's direct control (analysis / design / code, verify, database / API / UI, unit / integration / acceptance tests, etc).

The best Daily Scrums I've seen are mini planning sessions, where the plan agreed in Sprint Planning is reviewed and either continued progress is agreed or a change to the plan is immediately (immediately after Daily Scrum).

I think all Scrum team members has the potential to contribute to all Scrum Events in a way that increases their value.

For example, testers you have a particular role to play in representing the customer e.g. in Sprint Planning, ensuring the acceptance criteria is sufficient to clearly define the solution space without going as far as specifying an actual solution and checking that we are planning to deliver the smallest 'vertical slice' of functionality that provides the end user with the PO's desired capability. One way of doing this is to ask a well-timed, salient and considered open question. I testers doing this at Scrum Events to powerful effect.

It is my expectation that all team members attend all Scrum Events. It is my expectation that all team members actively participate. If there are impediments to team members actively participating then is my challenge (as SM) for issues to be identified and resolved where possible and desirable to all parties.

Personal approach

One of my areas of expertise is test automation and test driven develop as applied to Agile (acceptance testing, domain driven development, CI and automated builds). As a former developer-in-test myself, I can teach hands-on test automation at all levels (unit tests, integration and UI tests). My current teams' work to an impressive code coverage of 95% or more. I can mentor developers on the core of true “test first” test driven development (the smallest code for a failing test, the smallest production code to make that test part, refactoring all the way) plus the supporting principles (as the tests get more specific, the code gets more generic) and supporting practices (recognising when TDD has taken a wrong turn and how to correct it).

I've worked on projects to add test automation to legacy systems that previously relied on manual testing and greenfield projects that eliminated manual testing from day one. I can also ‘pair programme’ with developers and testers to teach good practice in the early stages of adoption or when on-boarding a new team member.

One of my biggest wins at a recent client was coaching teams to craft encompassing and meaningful Sprint Goals and to work to create potentially-releasable increments of product each Sprint (when I arrived there, Sprints were mere shopping lists of user stories!). I had been with one of the teams from inception of product vision to the release of the Minimum Viable Product (MVP) offering. I've worked with junior and experienced Product Owners on how to order the Product Backlog Items to maximise value and mitigate risks.

I also provide all services to the team expected of a Scrum Master. I coach teams to ensure they understand the purpose of the Daily Scrum: to inspect progress towards the Sprint Goal, adapting tasks and approach and owning impediments. The Sprint Reviews I oversee presenting working software to stakeholders for discussion and feedback. I facilitate Retrospectives that make team issues visible in a safe and engaging environment, running games and activities, and teaching about Agile principles and supporting practices.

Mary Poppins as Scrum Master

Having recently watched Disney's Mary Poppins Returns, I been wondering whether the titular character might be a Scrum Master.

While she could probably solve problems herself, she instead creates opportunities for others to take the required action, as happens when she takes the children to the bank so they can sneak off to confront the bank president's office.

She provides a vision of a better future outcome and helps everyone work towards it but does not hand out platitudes nor is fake optimistic (her default settings is to be smiling, though sometimes only to herself). In the film, this goes as far as setting impossible goals!

She supplies a model for a possible course of action but allows the team to 'join the dots' and agree the action, does not spell it out directly. For example, a whole sequence based around a song 'A Cover is not the Book' leads to the children realising by themselves that a certain character isn't all they seem.

There is the understanding that at some knowable stage she will no longer be needed, therefore she teaches the Banks family to self-organise. As one song from the film says: “When the world is getting scary, be your own luminary.” 

She has courage to speak out, is prepared to risk get herself and her charges into trouble and is certainly not a 'people pleaser' who requires praise (though she is beloved by nearly everyone for being herself).

She give a lot of latitude to her charges and actively encourages imaginative solutions but she is always prepared to step in to save the situation if necessary, thus providing 'guardrails' for those she looks after.

She doesn't have a specific job in the household (unlike, say, Ellen the cook), does not report directly to the head of the household, was not chosen by him but rather some 'higher' process. Similarly the children did not select Mary but know she is one of them and that she is representing their interests.

She allows pause for discussion but there is a sense of 'time-boxing': she has a low tolerance for frivolity and has a strong preference for just getting on with trying something. More actions than words, she leads by example.

She brings a supply of tools (in her carpetbag) and strategies for known situations she has experienced before e.g. how to have a fun and effective bath time.

...And there are other parallels to be drawn: Jack the lamp-lighter as a subject matter expert the the team sometimes needs to complete their tasks (such as getting home through the London smog); "responding to change" by turning upside down when the world does so.

Of course, there are many aspects to the Mary Poppins character that do not fit so well to the Scrum Master role. A Scrum Master needs to be practical but expect 'high performance' rather than 'perfection'. Mary Poppins herself discourages questions and never explains, doesn't seek alignment with senior stakeholders, likes to perform and be the centre of attention and therefore would not last long in a Scrum Master role!