PM 591 Week 3 Tailoring Agile Approaches Example

Find the Fun in Sprints, Build the Forest in Flow: Tailoring Agile Approaches Across a Game's Production Phases

[Student Name]

University of Phoenix

PM/591: Agile Project Management

Week 3 Assignment

[Instructor Name]

[Date]

Bluebonnet Forge Games, its phases, practices and figures are composites written for a model paper.

Bluebonnet Forge Games, the composite Austin studio followed in this course, has formed twelve feature teams for its new action role-playing game, along with platform, tools and content production teams. Week 1 chose Scrum, Kanban and Extreme Programming practices as the studio's foundation. Applying them unchanged for three years would ignore a basic fact about game development: the work itself changes as the game moves from discovery to production to release. This paper tailors the approach to each phase.

Why Tailor

The current standard describes tailoring as adapting the approach, governance and processes to fit the project and its environment (Project Management Institute [PMI], 2021). Campanelli and Parreiras (2015) conducted a systematic review of agile method tailoring and found that organizations commonly adapt agile methods, often by combining practices from several methods, and that tailoring was driven by factors such as project size, team distribution and organizational culture, though rigorous guidance on how to tailor remained limited. Fitzgerald et al. (2006) described how one large software organization combined practices from two agile methods, adding planning practices where its environment required them, and found that the tailored approach worked better than either method applied rigidly. These findings support deliberate tailoring, but they also warn that tailoring without principles can drift.

Three Phases, Three Kinds of Work

Preproduction, about nine months, is discovery. Small teams prototype combat, movement and companion systems to find what is fun. Most prototypes will be thrown away. Uncertainty is very high.

Production, about eighteen months, mixes feature building with very large volumes of content: environments, characters, quests, animations and dialogue. Features still evolve, but content work becomes predictable once its standards are set.

Release, about six to nine months, is stabilization: fixing thousands of bugs, meeting performance targets on each console and passing platform certification.

Tailoring Preproduction

Sprints are one week long, so teams can test an idea, play it and decide quickly. The definition of done is loose: a prototype is done when it is playable enough for the creative director and two external playtesters to judge it, not when it is polished or performant. Reviews happen in front of a screen with controllers in hand. Backlogs are short, and product owners expect to discard most items. The engineering practices from Extreme Programming are relaxed for throwaway prototypes but enforced for any code that will survive into production.

Tailoring Production

Feature teams move to two-week sprints, giving time to build features to production quality. The definition of done tightens: a feature is done when it meets the creative director's fun bar, runs within its performance budget on the lowest-specification console, has automated tests for core logic, has passed quality assurance and is translated into the game's launch languages. A dual-track arrangement keeps discovery alive: each product owner and one designer spend part of every sprint prototyping the next quarter's features with paper and quick builds, so that delivery teams always start from validated ideas.

Content production moves out of sprints into flow. Once a quest or environment type is approved, producing forty more of them is predictable work best managed on a Kanban board with work-in-progress limits per artist and a service level for each content type. External art vendors join the same board.

Discovering what is fun needs short cycles; building the fortieth village needs a steady pipeline.

Tailoring Release

In release, new features stop. Teams reorganize around bug triage on a Kanban system, with severity-based classes of service: a crash on any platform jumps the queue, while cosmetic issues wait. Builds are produced daily and tested automatically overnight. A platform certification checklist, based on each console maker's requirements, becomes part of the definition of done for the release candidate. Sprint reviews are replaced by a daily build review with the creative director and the quality assurance lead.

Tailoring for the Platform and Tools Teams

The platform and tools teams follow a different rhythm from feature teams. Their customers are the other teams, and much of their work is requested at short notice: an engine fix blocking a combat feature, a pipeline change for a new type of asset. In preproduction and production they run Kanban with two classes of service, an expedite lane for blocking issues limited to one item at a time and a standard lane for planned improvements. They join the feature teams' planning day so that upcoming needs are known two weeks ahead, which keeps the expedite lane small. In release, the platform team's performance and memory work becomes the most critical in the studio, and it shifts to daily stand-ups with the release manager.

Tailoring for People, Not Only Work

Tailoring also responds to people. Some artists found one-week sprints in preproduction exhausting, since every review demanded something new to show. Their teams agreed that art would contribute to reviews every second week, showing sketches or block-outs in between. Several engineers wanted more uninterrupted time; teams agreed to keep two mornings a week free of meetings. These adjustments were recorded like any other tailoring decision and reviewed after two months.

Fitting the Publisher's Milestones

The publisher's contract still has milestones and payments. Rather than lists of features, they become playable checkpoints with agreed quality criteria: a vertical slice at the end of preproduction, an alpha with all features playable in rough form, a beta with all content and a release candidate. Scope within each checkpoint flexes by agreement between the studio's product leadership and the publisher's producer, who attends sprint reviews monthly. This preserves the publisher's control over payment while giving the teams room to adapt.

What Stays Fixed

Some practices are not tailored in any phase: a playable build reviewed at least every two weeks, a retrospective at the end of every iteration, an ordered backlog with one product owner per team and transparency of progress to the whole studio. These are the feedback loops that make agile work; removing them under schedule pressure would repeat the last project's problems.

Rules for Changing the Tailoring

Teams may propose changes to their practices at retrospectives. Changes that affect only one team are approved by its product owner and scrum master; changes that affect other teams or the definition of done go to a monthly practices meeting of product owners and discipline leads. Every change is recorded with its reason and reviewed after two months, and any change that weakens one of the fixed feedback loops above needs the creative director's and the production director's agreement.

Conclusion

Tailoring agile at Bluebonnet Forge means recognizing that discovery, production and release are different kinds of work. Short sprints and loose completion rules serve preproduction; two-week sprints, a strict definition of done, dual-track discovery and a flow-based content pipeline serve production; and Kanban triage with daily builds and certification checks serve release. Publisher milestones become playable checkpoints. Core feedback loops stay fixed, and tailoring itself is governed so that it improves the process rather than eroding it.

References

Campanelli, A. S., & Parreiras, F. S. (2015). Agile methods tailoring: A systematic literature review. Journal of Systems and Software, 110, 85-100. https://doi.org/10.1016/j.jss.2015.08.035

Fitzgerald, B., Hartnett, G., & Conboy, K. (2006). Customising agile methods to software practices at Intel Shannon. European Journal of Information Systems, 15(2), 200-213. https://doi.org/10.1057/palgrave.ejis.3000605

Project Management Institute. (2021). A guide to the project management body of knowledge (PMBOK guide) (7th ed.). Project Management Institute.