The following is an extract from our book, Scrum: Novice to Ninja, written by M. David Green. Copies are sold in stores worldwide, or you can buy it in ebook form here.
We’ve covered how scrum works, and why it’s a productive way to structure web and mobile product development. At this point, it’s worth taking a moment to recap some of the highlights of how scrum applies in particular to web and mobile product development.
Fundamentally, scrum offers a team-based approach to project work that allows a product development process to benefit from iterative self-reflection, helps a team learn how to estimate their own ability to address unfamiliar tasks, exposes metrics about team effectiveness, encourages dialogue about feature implementation instead of static specifications, and supports rapid response to changing market conditions in a sustainable manner.
All of those advantages can make a real difference when doing web and mobile development. Most work in web or mobile development tends to be very time sensitive, and needs to respond quickly to changes in the marketplace. Whether that means new browsers, new technologies, or new messaging that needs to be communicated immediately, web and mobile teams have to be able to respond quickly.
Scrum provides a framework that allows developers to work toward a vision, and the opportunity to shift direction as the environment changes without feeling torn away from their focus.
When following best development practices, the type of work that’s involved in building and enhancing a web or mobile project tends to break down into discrete pieces that can be worked on independently, with a core of infrastructure stories that support a broad range of independent feature stories. This makes it easier for one part of a web or mobile project to be developed in isolation, and leverage the shared resources of other parts of the same project.
Scrum encourages teams to spell out the work on a new feature so that it can be developed in parallel, without relying on other undeveloped features. By using stories, and making sure each story is properly formatted and estimated, the team sets itself up for a consistent and productive development experience.
Note: Some Scrum Terms Defined
When scrum uses a word, it means just what scrum chooses for it to mean. But unlike Humpty Dumpty in Through the Looking Glass, scrum relies on familiar and easily understood definitions. Learning the language is one of the first steps in acquiring a new skill, and consistent use of language is fundamental to teams trying to work together. The terms below are only some of the ones that will be defined in much more detail later in the book, but a brief glance through these concepts may help as you read on.
- Agile
-
a set of software development practices designed to help engineers work together and adapt to changes quickly and easily.
- Artifact
-
a physical or virtual tool used by a scrum team to facilitate the scrum process
- Blocker
-
anything keeping an engineer from moving forward on a task in progress
- Customer
-
whoever has engaged the team to create a product
- Engineer/Developer
-
a person responsible for creating and maintaining the technology that goes into a product
- Engineering Organization
-
the part of a company where engineers are employed to create and maintain products
- Product
-
what the engineering organization is building or maintaining for a customer
- Product backlog
-
a constantly evolving list of potential features or changes for a product
- Product owner
-
a person who helps define the product for the team, and whose job may be on the line if the customer isn’t satisfied
- Retrospective
-
a regular opportunity for the team to reflect on how they are doing, and what they could do better
- Ritual
-
a group of people coming together as part of the scrum process for a fixed time, with a specified agenda, to achieve a clearly defined outcome
- Scrum Master
-
a person responsible for maintaining the artifacts and overseeing the rituals of scrum
- Sprint
-
a fixed number of days during which the team can work together to produce an agreed upon set of changes to the product
- Sprint backlog
-
a finite and well-defined set of stories the team has agreed they can reasonably complete in the current sprint
- Story
-
a clear and consistent way of chunking, phrasing, and discussing work the team may need to do on the product
- User
-
a person who will be making use of the product
Scrum is also flexible enough to support working styles for product owners who prefer to break down stories that can be completed in one week, two weeks, three weeks, four weeks or longer. While most web and mobile development teams tend to split the work into one- or two-week segments—known in scrum terminology as sprints—whatever the team agrees on should work. As long as the team is keeping track of how they work together, and they’re given the opportunity to reflect on a regular basis about their schedules, scrum can adapt to work on projects ranging from the simplest to the most complex.
Time Sensitivity
Scrum provides opportunities in every sprint to integrate the ideas of designers, engineers, executives, customers, product managers, and customers through real customer data. Because of the cyclical nature of scrum, and the iterative approach that encourages learning as you go, scrum allows mobile and web projects to adapt to changing technologies and changing market expectations quickly.
Modular Development
Scrum supports the ability to develop a project in modules. Because scrum is based on thinking in terms of slices of functionality, it’s perfectly suited for making independent, interoperable features that can be developed atomically and work together harmoniously.
For example, a new section for a website may inherit styling from a shared style guide and CSS structure, and may inherit its functionality from a shared template. The work to build out that section relies on those other components remaining static long enough to complete the work. Scrum provides the stability to support that, without limiting the development of the rest of the site.
At the same time, updating the infrastructure of a product to support a new feature may happen at any time in the process, so a team has to consider up front how to make those changes safely, without breaking the work being done on other features.
As another example, sometimes an API that every feature of the site relies on needs to be changed. Scrum encourages the team to manage the code in a modular, testable way, so that changes can be inherited by other feature stories that might be in progress without undue breakage.
Flexible Scheduling
Companies serving customers in the web and mobile space need to be able to respond quickly to changes. However, engineers need to be confident that what they’re working on isn’t going to change before they can get the feature developed. It can be difficult to balance those two objectives.
Scrum provides windows of opportunity that are long enough to allow a web or mobile feature to be fully developed, while still allowing a product to change directions at the end of each sprint, based on data from the marketplace.
Reflection and Improvement
A scrum team isn’t only looking to improve the product: they’re also looking to improve their own process. Scrum teams get better over time at estimating how much work they can do, and improving their approach to working so that they can be the most productive.
By giving the team the opportunity to look at its own process, and figure out how it works best together, scrum makes maximum use of the limited resources of any organization.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
