Pat Pagano is a publishing professional with many years’ experience in content and media. He earned his bachelor of science degree in communication/journalism from Syracuse University and started his career as a type designer at Linotype. His work experience includes production and technology positions on magazines (Rolling Stone, US, Elle, W, New York Magazine), newspapers (Village Voice, Women’s Wear Daily, The Daily Deal), and print and digital books at Harper Collins. His latest engagement was at barnesandnoble.com working on digital operations for NOOK, maintaining their e-book library.
There is an increasing interest among publishers of how agile methodologies, and specifically Scrum, can be used to create or improve products and services. This overview aims to give publishers a better understanding of Scrum and to identify areas within their companies that can benefit from this approach.
Scrum was originated by Ken Schwaber and Jeff Sutherland in 1995 with their publication The Scrum Guide. This is their definition:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
- Simple to understand
- Difficult to master
So, what exactly is it? Scrum is a series of short development cycles completed by a small team to deliver a working feature known as a “shippable product.” It starts with a defined list of features collected in the product backlog. The product backlog is a living entity. As existing items are brought into the development cycle, new items are added as they are discovered. The cycles, known as sprints, are anywhere from a week to a month long during which time the team works on items selected from the product backlog.
The Scrum Team is composed of:
- Scrum master: Not to be confused with a project manager, the Scrum master manages the Scrum process and provides checks and balances between the product owner and the development team. Scrum masters are servant leaders, meaning they enable the team by eliminating distractions and removing obstacles, and evangelists for Scrum values throughout the organization.
- Product owner: The product owner is responsible for representing the business stakeholders. The PO is an individual, not a committee, and is solely responsible for identifying the product being built. The PO owns and prioritizes the product backlog.
- Development team: Consisting of 3 to 9 people, the development team (or “Dev”) has all of the skills necessary to complete the sprint. The team is self-organized and produces the shippable product.
The Scrum Events are:
- Sprint planning: This is the meeting where the development team decides which backlog items will be included in the upcoming sprint, and the Scrum Team then decides what will be the sprint goal. Essentially the team decides on the what and the how. A sprint always produces a shippable product that meets the “definition of done.” This definition is an unambiguous checklist of steps (coding, testing, acceptance testing, documentation) required for completing the sprint.
- Daily Scrum: The development team meets every day at the same time for a 15-minute meeting where they individually discuss what was accomplished the previous day, what will be accomplished today, and any obstacles they have encountered.
- Sprint review: At the end of the sprint the Scrum team meets with key stakeholders to discuss the goal of that sprint. There is a demonstration of the product increment and feedback is given to the team.
- Sprint retrospective: The sprint concludes with a meeting of the Scrum team to discuss what went well and what didn’t. It is an opportunity to review and improve the process for the next sprint.
The three pillars of Scrum are transparency, inspection, and adaptation. Transparency occurs in the sprint review when there is a demonstration of the shippable product that has met the “definition of done.” Inspection and adaptation occur throughout the sprint, especially in the sprint planning meeting, the daily Scrums, and the sprint retrospective. Examples of adaptation are continuing the momentum for processes that work, creating alternative solutions for processes that do not work, refining the product backlog, and possibly evolving the definition of “done” (i.e., initial estimations of the sprint efforts might be overreaching and the definition is then pared back by the team).
To continue reading the article, please fill the below form
Disclaimer: This is to inform readers that the views, thoughts, and opinions expressed in the article belong solely to the author, and do not reflect the views of Amnet.
Copyright © 2018 Amnet. All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other non-commercial uses permitted by copyright law. For permission requests, write to John Purcell, Executive Editor- Amnet, addressed “Attention: Permissions” and email it to: firstname.lastname@example.org