MGT 647 Module 2 Scrum Example

Every Event Has a Purpose: Launching Lakeshore Mutual's First Scrum Team on a Mobile Claims App

Student Name

Master of Business Administration, Aspen University

MGT 647: Project Management Integration Framework

Instructor Name

Month Day, Year

Every Event Has a Purpose: Launching Lakeshore Mutual's First Scrum Team on a Mobile Claims App

Module 1 chose the mobile claims app as the place for Lakeshore Mutual to start with Agile. The app will let policyholders report damage, upload photos and follow their claim, and let adjusters respond from the field. This paper sets up the Scrum team that will build it, explaining each element of Scrum and the purpose it serves, and plans the first three sprints.

Where Scrum Came From

Takeuchi and Nonaka (1986) studied how companies such as Fuji Xerox, Canon, Honda and NEC developed new products quickly and flexibly. They contrasted the traditional relay race, in which each functional group finishes its phase and passes the work to the next, with a rugby approach, in which a small multidisciplinary team works through overlapping phases together. The teams they studied were self-organizing, given broad goals and wide freedom by top management, and learned across functions and from one another. Management exercised subtle control through choosing team members, creating an open environment and tolerating mistakes. Software developers later borrowed the term scrum from this article for their own method.

Scrum's Elements and Their Purposes

Schwaber and Sutherland (2020) define Scrum as a lightweight framework built on empiricism, in which decisions are based on what is observed, and lean thinking. Three pillars, transparency, inspection and adaptation, run through every element.

The First Product Backlog and Product Goal

The product goal sets direction for many sprints: a policyholder can report a home or auto claim, upload photos and see its status from a phone within ten minutes, without calling. The first product backlog, ordered by the product owner after interviews with adjusters and a review of call center logs, starts with reporting a claim with photos, then claim status, then messaging with the adjuster, then scheduling an inspection. Items near the top are broken into pieces small enough to finish in a sprint; items further down stay rough until they rise. The backlog is visible to everyone in claims, so any manager can see what is coming and argue for a change with the product owner rather than going around the team.

Filling the Accountabilities at Lakeshore

The product owner is a claims operations manager released full time from regular duties, since a part-time product owner is a frequent cause of failure. The Scrum Master is a project manager from the technology group who completed training and will coach rather than assign tasks. The seven developers include two mobile engineers, a back-end engineer, a designer, two testers and an engineer from the claims system team. The team works in two-week sprints, short enough that the product owner can change direction quickly after storm season or a regulatory notice, and long enough to finish a usable piece of the app. Every member sits with the team at least four days a week, and none is shared with another project in the first quarter.

What Goes Wrong in New Scrum Teams

Moe et al. (2010) studied a software team adopting Scrum and used a teamwork model to explain its difficulties. Team members were highly specialized and worked on their own tasks, so the team rarely shared responsibility for the sprint's work. Leadership remained with a few people rather than being shared. Team orientation was weak, and the daily scrum became a status report rather than a coordination meeting. Scrum's practices were in place, but the teamwork they assume was not.

The First Three Sprints

The plan addresses those risks directly. In sprint one, developers pair across specialties, so a tester works with a mobile engineer on the photo upload. The product owner attends every daily scrum and the Scrum Master asks each day what the team will do together toward the sprint goal, not what each person did. The definition of done includes testing with two adjusters. Sprint two adds the claim status screen and a first review with six adjusters. Sprint three releases to a pilot group of twenty adjusters. Each sprint review invites claims supervisors and two call center leads, who see the working app rather than slides, and their feedback goes straight into the product backlog. The Scrum Master watches for one warning sign in particular: if the testers are still testing work the developers finished days earlier, the team is running a relay inside a sprint, and work needs to be split smaller so that building and testing happen together.

Knowing Whether Scrum Is Working

The team and its sponsors will judge Scrum by results rather than by whether the events are held. Three measures are tracked from the first sprint: whether each sprint goal is met, how many adjusters and policyholders use the released features and how long it takes from an idea entering the backlog to it reaching users. The retrospective looks at a fourth, the team's own sense of whether it works as a team, using the questions Moe and colleagues' findings suggest: are tasks shared, does leadership rotate and does the daily scrum help coordinate work?

Conclusion

Takeuchi and Nonaka explain the idea behind Scrum, the Scrum Guide defines its elements, and Moe, Dingsøyr and Dybå show why practices alone are not enough. Lakeshore's first team starts with each element's purpose in view.

References

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491. https://doi.org/10.1016/j.infsof.2009.11.004

Schwaber, K., & Sutherland, J. (2020). The Scrum guide. https://scrumguides.org/scrum-guide.html

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137-146.