PM 591 Week 1 Agile Foundations Example

Sprints Without Crunch? Evaluating Agile Foundations for an Independent Game Studio's Next Title

[Student Name]

University of Phoenix

PM/591: Agile Project Management

Week 1 Assignment

[Instructor Name]

[Date]

Bluebonnet Forge Games, its titles, teams and figures are composites written for a model paper.

Bluebonnet Forge Games is a composite independent studio in Austin, Texas, with about 240 employees. It runs two live online games that release content every six weeks and has begun production on a new action role-playing game planned for release on consoles and PC in about three years. Its last major title shipped seven months late. Production followed a milestone plan negotiated with the publisher; when features proved less fun than expected, the team redesigned them late, and the final four months were spent in crunch, with many developers working 60 or more hours a week. Turnover in the year after launch reached 26 percent. The studio's leadership wants to adopt agile methods for the new title and has asked whether that will help. This paper evaluates the foundations of agile and their fit for the studio.

The Foundations of Agile

Agile approaches share a set of ideas rather than a single method. Seventeen practitioners who met in 2001 wrote down four values and twelve principles that favor individuals and interactions, working software, customer collaboration and responding to change (Beck et al., 2001). Underneath them sits empirical process control: in complex work where outcomes cannot be predicted, teams make progress transparent, inspect results frequently and adapt. Work is delivered iteratively, refining a product through repeated cycles, and incrementally, adding usable pieces. Highsmith and Cockburn (2001) argued that agile methods suit work where change is constant and that their main contribution is recognizing people and their interactions as the primary drivers of project success, with processes serving them.

What the Evidence Shows

Dybå and Dingsøyr (2008) conducted a systematic review of empirical studies of agile software development and found evidence of benefits in areas such as customer collaboration, work processes for handling defects and job satisfaction, but judged the overall strength of evidence to be low and noted that many studies examined single teams or Extreme Programming alone. Later research has broadened the evidence but kept the same message: agile tends to help when teams adopt its values as well as its practices and when the organization around them supports frequent delivery and feedback. For the studio, the lesson is that adopting agile ceremonies without changing how the publisher milestones, design decisions and workload are managed would likely disappoint.

Comparing Four Approaches

Scrum: time-boxed sprints of one to four weeks; three accountabilities held by the person who orders the backlog, the person who coaches the process and the people who build; and planning, daily coordination, review and retrospective. Strength: regular inspection of a working build. Needs: a stable team and an engaged product owner.

Kanban: visualized work flow, limits on work in progress and continuous delivery. Strength: handling unpredictable streams of work. Needs: discipline about limits and policies.

Extreme Programming: engineering practices such as continuous integration, automated testing, pair programming and small releases. Strength: technical quality that keeps change cheap. Needs: investment in tooling and skills.

Lean thinking: focus on value, flow and eliminating waste across the whole system. Strength: improving how work moves between disciplines. Needs: a view across the organization rather than one team.

Fit With Game Development

Game development has features that favor agile and features that limit it. Whether a mechanic is fun can only be learned by playing it, which strongly favors short iterations with playable builds. Live operations, with bug fixes, balance changes and seasonal content, arrive as a stream better suited to flow-based work. But console platforms require certification against fixed technical requirements before release, publishers expect dated milestones and large art and audio pipelines involve long production tasks that do not fit neatly into two-week sprints. Content production for a game of this size, hundreds of characters, environments and animations, behaves more like manufacturing than discovery once designs are settled.

You cannot schedule the moment a mechanic becomes fun; you can only schedule the next chance to find out.

The Crunch Question

Agile principles call for a sustainable pace, but agile does not prevent crunch by itself. Crunch at the studio came from fixed scope against fixed dates and from late discovery that features did not work. Agile addresses the second cause directly by surfacing problems in playable builds every few weeks. The first cause requires a different agreement with the publisher: scope must flex against dates, with the publisher sharing in decisions about what to cut. Without that change, sprints would simply become shorter routes to the same crunch.

A Recommended Foundation

The studio should build on four elements. Scrum for the new title's feature teams, with two-week sprints and a playable build reviewed by the creative director and a publisher producer at every sprint review. Kanban for the live games' operations teams, with limits on work in progress and a weekly replenishment meeting. Extreme Programming practices, continuous integration, automated tests for core systems and frequent small merges, adopted across engineering to keep the codebase changeable. And a sustainable pace commitment backed by measures: overtime hours per person tracked monthly and reviewed by leadership, with a ceiling that triggers a scope discussion rather than more hours.

What the Teams Themselves Said

Before recommending anything, the studio's production director held listening sessions with each discipline. Designers said they wanted to see features in the game sooner, not in documents. Engineers said late design changes were less painful when they knew about them early and when tests caught regressions. Artists were the most skeptical: in their experience, agile had meant being asked to produce final-quality assets every two weeks for features that were later cut. The recommendation responds to that concern by allowing art to work at lower fidelity until a feature passes a fun review, with final assets produced only after the feature is locked. Quality assurance testers asked to join sprint teams rather than receive builds at the end, which the Scrum structure provides.

Measuring Whether It Helps

The studio will judge the change by a few measures over the first year: the share of sprint reviews with a playable build, the number of features cut or redesigned after the fun review rather than late in production, average overtime hours per person, voluntary turnover and the live games' release reliability. These measures are set now, before the change, so that the comparison with the last project is honest.

Conditions for Success

The foundation will work only if the publisher agreement moves from fixed feature lists to playable milestones with flexible scope, if the studio trains product owners from its design leads and if leaders model the values, especially by accepting bad news from sprint reviews early.

Conclusion

Agile's foundations, empirical control, iterative and incremental delivery and values that put people and working results first, fit much of a game studio's work, especially the search for fun and the stream of live operations. Research supports agile's benefits but warns that they depend on context and on adopting values, not just practices. A combination of Scrum, Kanban and Extreme Programming practices, with a measured commitment to sustainable pace and a changed publisher agreement, gives Bluebonnet Forge a foundation that addresses the causes of its last troubled launch.

References

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for agile software development. https://agilemanifesto.org/

Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. https://doi.org/10.1016/j.infsof.2008.01.006

Highsmith, J., & Cockburn, A. (2001). Agile software development: The business of innovation. Computer, 34(9), 120-127. https://doi.org/10.1109/2.947100