Review of Scrum Basics

Its been a long time, nearly nine months, since my last post. A job and two very active little kids make it very difficult to find time for blogging, but I figure that rare posts are better than none at all. At work I’ve been on a steep learning curve with PHP and Symfony, as well as trying to get a better grip on the “softer” aspects of software development. Since I am a part of a Scrum team, a better undertsanding of the origin and mechanics of the Scrum process would be a good idea. [Scrum Basics: A Very Quick Guide to Agile Project Management] (https://amzn.com/1623155886) is a reasonably short and easy to read book on the basics of the Agile development framework. (The author is listed as “Tycho Press” and not listed as an individual.) I picked it up because, even though I understand the mechanics of agile development from my work on agile teams at Columbia (currently) and at the firehose project (past), I knew that I didn’t have a clear understanding of how the agile framework is different from other development methods because agile is the only software development framework I’ve ever worked with. I was also looking for a broader perspective on software development project management. What are the pros and cons of agile, and what are the other frameworks our there?

This book partially filled this gap in knowledge. The book starts out with a brief history of agile development. It started it as a trend among software companies, where developers noted that assembly line techniques of project management followed by manufacturing companies just don’t work well for software development. The key difference is the greater uncertainty associated with software development. When designing a manufacturing process for, say, a car or a chemical reactor, the set of requirements for the final product tend to be much more reliable. When it comes to software, the chances that a customer will know exactly what they want are slim. If the customer does know what they want, then this requirement is very likely to change over time. As a result, when software development was treated like a manufacturing processes (using the “waterfall” development model), delays tended to follow. Sometimes, massive stress-inducing delays the author calls “death marches”.

The keys to improving this process lay in making two general adaptations to the process. First, don’t commit to a final design at the start of the project. Instead, break up the project into short iterations, where the requirements for each iteration depend on the feedback from the previous one. Second, maintain constant communications between the development team and the customer, and among the development team members. This will minimize any unpleasant surprises. These ideas were embodied by “Agile Manifesto” agreed to at the Snowbird conference of developers, and described further by the 4 agile values.

The driving force behind agile development is that “consistency and predictability in software development is largely an illusion”. Much more of an illusion than for a mature manufacturing process. The concepts that make Agile development possible are:

Agile team: a team made up of developers, a product owner, and a scrum master.

Sprint: a period lasting between 1 day and 1 month when the development team spends working on defined set of tasks. The state of the product is reassessed and feedback is obtained from stakeholders before starring with the next sprint.

MVP: minimum viable product. This can be either done kind of a mock-up, or a rudimentary working version of the product. MVP lets the developers get initial feedback from stakeholders prior to spending a lot of time on the product.

Product backlog: a prioritized list of the product’s features. It guides the efforts of the scrum team.

Grooming: populating and updating the product backlog. This is an activity that the whole Agile team participates in. It is ongoing throughout the development process.

Sprint planning is a meeting of the full development team where the team decides on the tasks to be included in the next sprint. This is done by prioritizing the tasks, estimating how long each task will take, and adding as many tasks to the sprint backlog as the developers believe they can finish during the sprint period.

Planning Poker is a trick used to avoid “Groupthink” when estimating the lengths of development tasks. If all the group mebers announced their guesses aloud, then the first guess uttered and the guess of the most experienced team member would have undue influences on the remaining members’ guesses. This is avoided by giving each team member a deck of cards and having each member lay down a card face down. The value of the card would be the number of hours that they think the task is most likely to take. The cards ranging from 2 to King have the values from 2 to 13 (respectively), and the Ace has the value of 1.

The daily scrum is a brief meeting no longer than 15 minutes where each team member talks about the tasks they’re working on and the obstacles they’re facing.

These are all the scrum tools that the team at my job uses. There are other tools, such as the burn-down graph (a graph of work done over time) and sprint review meetings, that we have not found to be useful for our purposes.