MT247 Unit 10 Adoption Assessment Example

Scrum for One, Not for All: A Unit 10 Adoption Assessment of Three Kinds of Work at a Property Company

[Student Name]

Purdue University Global

MT247: Agile and Scrum Methodologies

Unit 10 Adoption Assessment

[Instructor Name]

[Date]

Larkspur Residential, its departments, systems and every figure are composite and illustrative; the sources cited are real.

The Question

Larkspur Residential's leadership team asked a simple question after the resident app team's first year of Scrum: should every department adopt it? The app team's results have improved since it fixed the problems documented this term: Sprint Goals are now met more often than not, mid-Sprint additions have nearly stopped, and residents can report emergencies through the app. Leadership has seen the improvement and wants the same for the rest of the company.

This assessment examines three candidates that leadership named: the resident app itself, the migration of the company's accounting system to a new vendor platform, and the process of turning over apartments between residents. It asks, for each, whether Scrum fits the work.

Method

Boehm and Turner (2003), in Balancing Agility and Discipline, identify five factors that indicate whether a project suits agile or plan-driven methods: size, criticality, dynamism, personnel and culture. Small projects with low criticality, frequent change, experienced people and a culture comfortable with autonomy lean agile. Large, critical projects with stable requirements, mixed experience and a culture that values order lean plan-driven. The factors are rated here on evidence from each candidate, not on preference.

Candidate One: The Resident App

Size: small, one team of five Developers with a Product Owner and Scrum Master. Criticality: moderate; failures inconvenience residents and staff, and the emergency routing feature raises the stakes, but there is no financial loss or legal exposure from a single defect. Dynamism: high; residents' needs, regional managers' requests and phone platforms change constantly. Personnel: experienced; after a year, the team has learned its codebase and its process. Culture: ready; the app team and its Product Owner have adapted to Scrum, and leadership has learned to route requests through the Product Owner.

Verdict: Scrum fits. Every factor points toward an agile approach, and the team's improvement this year confirms it.

Candidate Two: The Accounting System Migration

Size: larger, involving finance, IT operations, the vendor and every property's office staff. Criticality: high; the system carries the company's financial records, rent ledgers and owner distributions, and errors could misstate accounts or delay payments to property owners. Dynamism: low; lease accounting rules fix most requirements, and the vendor's platform defines the data structure. Personnel: mixed; the finance staff are experienced in accounting but new to system migration, and the vendor's team controls the configuration. Culture: plan-driven; finance works to close calendars, audits and deadlines.

The migration also has a fixed cutover date of January 1, set by the vendor's contract and by the start of the fiscal year, which neither Larkspur nor the vendor can move.

Verdict: plan-driven delivery fits the migration better, with one agile element. The overall plan should be a phased schedule built backward from January 1, with formal sign-offs at each phase. But testing should be iterative: the team should migrate one region's data at a time, test it against the old system's reports, fix what is wrong and repeat. That gives the migration the fast feedback that Scrum provides, without pretending its requirements are open to change every two weeks. Boehm and Turner (2003) recommend exactly this kind of hybrid where a project is high in criticality but has parts that benefit from short cycles.

Candidate Three: Apartment Turnovers

Size: continuous; turnovers arrive at about 210 a month across the portfolio, each handled by a maintenance crew, a cleaner and a leasing agent. Criticality: moderate; a slow turnover costs rent for each vacant day. Dynamism: high in arrival, low in content; nobody knows which apartments will empty next week, but each turnover follows the same steps of inspection, repairs, paint, cleaning and listing. Personnel: experienced crews who know the work well. Culture: operational, used to work orders and daily schedules.

The decisive point is that turnovers have no product increment. Each is a repeated piece of work, not a step toward a product goal. Sprints would batch work that arrives continuously, forcing a crew to wait for the next Sprint to start an apartment that emptied today. A Sprint Review would have nothing new to inspect.

Apartments do not empty on a two-week schedule.

Verdict: a flow method fits turnovers better than Scrum. Anderson (2010) describes Kanban as a method for managing continuous work: visualize each item's stage on a board, limit how many items are in progress at once and measure how long items take from start to finish. For turnovers, that means a board showing every vacant apartment by stage, a limit on how many each crew works at once, and a measure of days from move-out to ready, which is the number that drives lost rent.

Limits of the Assessment

The five factors are judgments, not measurements, and two people could rate dynamism or culture differently. The assessment reduces that risk by tying each rating to evidence leadership can check: the vendor's contract date, the turnover counts in the property system, the app team's Sprint records. It also looks at only three candidates. Other work, such as the leasing team's marketing campaigns or the annual budget process, may suit yet another approach and should be assessed the same way before any decision is made for them.

What Uniformity Would Cost

Leadership may be tempted to adopt Scrum everywhere for simplicity, with one vocabulary and one set of meetings. That would cost more than it saves. The accounting migration would lose the formal phase gates that auditors and the vendor expect, and its January 1 date would sit inside a process designed to let scope move. The turnover crews would spend time in Sprint Planning and Reviews for work that has no plan to review, and apartments would wait for Sprints to begin. Both departments would likely end up where the app team began, running their old process under Scrum's names. The Scrum Guide itself describes Scrum as a framework for addressing complex problems, not as a method for every kind of work (Schwaber & Sutherland, 2020).

Recommendation

Leadership should keep Scrum on the resident app, run the accounting migration as a phased plan with iterative regional testing, and introduce a Kanban board for turnovers with a work-in-progress limit and a days-to-ready measure. The common thread is not one framework but one principle: choose the method by the kind of work. A year from now, leadership should review each with the same five factors, since the app may grow, the migration will end and turnovers may change.

References

Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Blue Hole Press.

Boehm, B., & Turner, R. (2003). Balancing agility and discipline: A guide for the perplexed. Addison-Wesley.

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