Following the 2015 success of ‘Agile Project Management in easy steps‘, I was asked to write a book on Scrum. Two years later it has now been published and will be available through most booksellers and websites, as well as electronically. However it was not a certainty that I would do this.
Firstly, when I was asked, I was still working on my masters research project on ‘The Paradox of Agile Transformation‘ (the subject of some earlier posts), and I knew that I would not have capacity until 2016. Thankfully, I completed the research on time and graduated with honours.
Secondly, and more importantly, there have been many many books written on Scrum. What would I have to offer that would add to what has already been written? Was it suitable for the ‘in easy steps’ format? In some ways, the second question was answered easily. There was already a ‘Scrum for Dummies‘ so there was no danger I would be accused of dumbing it down.
The more I thought about the ‘in easy steps’ format, the more I realised that there was a great opportunity to take readers gently by the hand and guide them from their very first step all the way through to facing the challenges of scaling and transforming their whole organization, without boring them with a bunch of theoretical musings first.
Introducing Scrum
I make it very clear that the best way to learn Scrum is to be in a Scrum Team and to experience it for yourself. If you are not in a Scrum Team, the next best way is to observe another team. The book guides the reader through forming their first team, and then taking that team through the whole product development life-cycle.
So that is it is not too dry, this is illustrated with a fictitious organization, Dante’s pizzeria, who want to start taking orders online. Chapter one very briefly explains why product development is so hard and why Scrum can be a good fit for novel products in emerging markets.
Forming your first Scrum Team
People talk about adopting Scrum (or any agile framework) as being first and foremost about changing mindsets and values. Often, the hardest aspect of this is changing how people work together and the impact this has on their role. Chapter two looks at how best to approach this. The rest of the book then breaks the work down around the three core roles of the Scrum Team: the Product Owner, the Delivery Team, and the Scrum Master.
Note: I chose to break with normal tradition, by calling the team that builds the product increments the Delivery Team. Most teams I have coached have struggled with being called a Development Team. Usually, it is only the programmers on the team who think of themselves as Developers. Others on the team (e.g., testers and analysts) tend to feel that they are excluded. However, everyone pulls together to deliver the product, so Delivery Team seems a better term to use. It is also the term we use here at Fiserv — and fits whether the team follows Scrum, Kanban, or some other framework or method.
Discovery and definition
The Product Owner is primarily responsible for the business value of the product, selecting what gets done and explaining why. They enable success by preparing a good breakdown of the work required. Product Owners work with others to discover, define, and plan delivery of the product through the Product Backlog. This is often dealt with too lightly in many books on Scrum, or missed completely. The three chapters that cover this are:
- Discovering what customers need
- Defining the Product Backlog
- Prioritizing and sizing the Backlog
Development and delivery
The Delivery Team is primarily responsible for deciding how the work gets done and doing it. They develop and deliver the product increments. The book steps through what happens during the Sprint (the repeating cycle which forms the engine at the heart of Scrum), covering the events, artefacts, and techniques used. The three chapters that cover this are:
- Preparing for the Sprint
- A day in the life of a Sprint
- Delivering the Product Increment
Continually improving and scaling
The Scrum Master is primarily responsible for ensuring the team is motivated, productive, and following their working agreements. They work with the Delivery Team and Product Owner to get better at Scrum, and with the whole organization to continually improve, to operate more successfully at scale, and to achieve greater strategic agility. The two chapters that cover this are:
- Continual improvement in Scrum
- Scaling Scrum beyond one team
Scrum reference
Finally, for anyone just wanting a quick reference, the last chapter summarises the Scrum framework, the roles, the artefacts, the events, and the rules that make them work together. It also talks to how Ken Schwaber and Jeff Sutherland created Scrum and continue to collaborate on the Scrum Guide.
Conclusions?
I feel that I have added something useful, while also paying homage to those that laid the groundwork. I have also been very careful to make clear what is core Scrum and what is supporting, The 101 techniques included provide a range of options — nothing is described as mandatory that is not mentioned in the Scrum Guide itself.
I would be interested in what you think? Please feel free to comment below.
Available from: Amazon, Book Depository, In Easy Steps, and many others.
