Nye’s Digital Lab is a weekly scribble on creativity. After last week’s post, a few trusted folks reached out: “That’s great Nye. Can you explain what you mean by agile?”

So! Here’s my deep dive on agile as an educational opportunity.

Walk into any animation studio and you’ll witness a methodical ballet of specialization. Concept artist to modeler to rigger to animator to lighting to compositor. Each team waits for the handoff. Months later, the shot is complete.

This is the waterfall pipeline[1], named for its one-way flow through sequential stages. It’s elegant, proven—and super catastrophically bad at handling change.

When a director decides halfway through production that the dragon needs to be purple instead of green, every department downstream redoes work. Schedules slip. Budgets go nuclear. The rigidity that makes waterfall predictable makes it fragile.

Now walk into a game studio. You’ll see something radically different: teams huddled around whiteboards covered in sticky notes, organizing work into sprints (focused one or two-week bursts)[2]. Daily standups share progress and blockers. At sprint’s end, there’s a working build—not perfect, not finished, but playable, testable, changeable. The focus is on the MVP, the minimum viable product—the simplest working hypothesis of a moment in development.

This is agile development[3], born from software engineering’s realization that you can’t predict everything upfront.

Repeat after me.

Things will change.

Players might hate your brilliant mechanic. Features might prove impossible. Markets shift. In agile, these aren’t disasters—they’re just what it is.

The philosophical difference matters. Waterfall says “plan perfectly, then execute.” Agile says “learn constantly, adapt quickly.” Waterfall builds concrete bridges. You need to get blueprints right because you can’t move support columns after the fact. Agile explores jungles like Indiana Jones; running from native uprisings by whip-swinging over pits.

For games, this difference is existential. Interactive systems generate emergent, unpredictable fun. You can’t waterfall your way to engaging gameplay any more than you can waterfall a good conversation. The key to a good sprint is rhythm: build, test, learn, adapt[4]. It’s the scientific method at speed, and it matches creative problem-solving’s volatile nature.

The weekly cycle of agile reveals deeper value that higher education has yet to fully embrace.

Traditional education loves depth. There’s a quarter on C#, another on 3D modeling, a third on narrative design. We structure education systems around measurable, sequential outcomes. Works for the spreadsheets, right?

Agile forces something different: cross-functional collaboration under time pressure.

In a game jam or two-week sprint, you can’t be precious about your specialty. Programmers learn enough design to make smart system decisions. Artists pick up basic scripting. Designers understand technical constraints for realistic scoping. You develop conversational fluency across disciplines—real utility, ruthless problem solving.

This is CrossFit for your brain. Traditional strength training isolates muscle groups—leg day, arm day. CrossFit demands coordination across systems through varied functional movements. You’re not building the biggest biceps; you’re building resilience for unexpected challenges.

In agile, you learn to be adaptable.

Each cycle presents new problem constellations requiring different skill combinations: heavy technical work, creative storytelling, UX optimization, teaching teammates. Your brain can’t settle into comfortable expertise. It stays in adaptation mode.

Research from UCLA supports this. Robert and Elizabeth Bjork introduced “desirable difficulties”[5]—their work shows learning is most durable when we must retrieve information from memory, transfer skills to new contexts, and interleave different problems rather than blocking practice in single domains. Agile’s rapid cycling naturally creates these conditions.

Training lightly across multiple disciplines rather than deeply in one doesn’t just accumulate specialized knowledge, it develops learning capacity itself.

You’re getting good at getting good at things. You’re building the meta-skill of rapid skill acquisition, which matters more when specific technical skills have half-lives measured in years, not decades.

Weekly sprints also build psychological resilience: managing scope, negotiating deadlines, handling critique, restarting after failure, shipping imperfect work.

These aren’t bonuses—they’re the reality of building with teams.

Coding assistants already write production code. When we solve our IP crisis, art tools will generate publication-quality imagery. Agents will compose music, edit video, design levels, prototype mechanics. The agents are here, and X announces another radical update daily. Soon (very soon) your personal machine will handle most technical execution we currently spend years mastering.

You describe a game system, it generates working code. You sketch a character, it produces a rigged, game-ready asset. You outline narrative structure, it drafts dialogue trees.

What’s left for humans? The waterfall mindset collapses. Deep specialization in technical execution becomes obsolete (unless something breaks, of course).

This doesn’t make human creators obsolete. It makes agile thinking mandatory. The sprint cycle becomes your operating mode because every tool, every interface, every technical capability constantly evolves.

To steal from Kevin Kelly: we become “forever noob”[6]—permanently in beginner’s mind, always learning new tools, always adapting, never settling into comfortable expertise because the ground keeps shifting. This sounds exhausting. But so is training for marathons or track. Agile already trains this athlete-style mindset. Weekly cycles of new problems, new team configurations, new technical challenges prepare you for perpetual adaptation.

Agile, created to manage software uncertainty, turns out to be training for human uncertainty in an automated world. Those weekly sprints aren’t just building games and apps—they’re building the cognitive and emotional resilience to stay creative and relevant when your expertise regularly becomes obsolete.

Agile isn’t just project management. It’s rehearsal for the rest of your career.

Thanks for reading. I do this every week. If you vibe to the ideas I express, consider subscribing or sharing with friends. For those who like the printed experience, I grabbed a selection of last year’s best and crammed them into a book.

We’ll see you next time.

[1]

Waterfall Methodology in Animation/VFX: The waterfall model, first formally described by Winston W. Royce in 1970, is a sequential design process where project progress flows steadily downwards through several phases. In animation and VFX pipelines, this manifests as concept → modeling → rigging → animation → lighting → compositing, with each phase completing before the next begins. This sequential approach is particularly evident in traditional film production workflows. ∙ Royce, W. W. (1970). “Managing the Development of Large Software Systems” ∙ Wikipedia: “Waterfall model” (https://en.wikipedia.org/wiki/Waterfall_model) ∙ ResearchGate: “A traditional waterfall model of visual effects” (https://www.researchgate.net/figure/A-traditional-waterfall-model-of-visual-effects-as-part-of-a-waterfall_fig1_309242218)

[2]

Agile Sprints in Game Development: Sprints are time-boxed periods (typically one to four weeks, most commonly two weeks) during which teams complete a focused set of work. In game development, sprints enable teams to deliver working builds regularly, adapt to changing requirements, and iterate based on feedback. ∙ Keith, C. (2010). Agile Game Development with Scrum. Addison-Wesley ∙ Codecks Blog: “A Step-by-Step Guide to Planning and Executing a Game Development Sprint” (https://www.codecks.io/blog/a-step-by-step-guide-to-planning-and-executing-a-game-development-sprint/) ∙ Starloop Studios: “Best Agile Practices in Game Development” (https://starloopstudios.com/best-agile-practices-in-game-development/)

[3]

Agile Methodology Origins: Agile software development emerged in the early 2000s as a response to the limitations of waterfall methodologies, emphasizing flexibility, iterative development, and responsiveness to change. The Agile Manifesto (2001) established core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. ∙ Beck, K., et al. (2001). “Manifesto for Agile Software Development” ∙ Mountain Goat Software: “Agile and Scrum for Video Game Development” (https://www.mountaingoatsoftware.com/presentations/agile-and-scrum-for-video-game-development)

[4]

Sprint Rhythm and Iteration: The build-test-learn-adapt cycle is fundamental to agile methodologies, particularly Scrum. Game development sprints incorporate daily standups, sprint planning, sprint reviews, and retrospectives to maintain this rhythm and enable continuous improvement. ∙ Schwaber, K. & Beedle, M. (2001). Agile Software Development with Scrum ∙ ScienceDirect: “The role of Sprint planning and feedback in game development projects” (https://www.sciencedirect.com/science/article/abs/pii/S0164121219300974)

[5]

Desirable Difficulties: Robert A. Bjork first introduced the concept of “desirable difficulties” in 1994, referring to learning conditions that make acquisition more challenging but enhance long-term retention and transfer. Key desirable difficulties include retrieval practice, spacing, interleaving, and variation. The theory distinguishes between short-term performance (which appears better with easier learning conditions) and actual long-term learning (which benefits from challenge). ∙ Bjork, R. A. (1994). “Memory and metamemory considerations in the training of human beings.” In J. Metcalfe & A. Shimamura (Eds.), Metacognition: Knowing about knowing (pp. 185-205) ∙ Bjork, R. A., & Bjork, E. L. (2011). “Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning.” In M. A. Gernsbacher & J. Pomerantz (Eds.), Psychology and the real world: Essays illustrating fundamental contributions to society (2nd ed., pp. 59-68) ∙ Bjork, R. A., & Bjork, E. L. (2020). “Desirable difficulties in theory and practice.” Journal of Applied Research in Memory and Cognition, 9(4), 475-479

[6]

Forever Noob: Kevin Kelly, founding executive editor of Wired magazine, coined the phrase “You will be a newbie forever” as part of his “Techno Life Skills” to describe the permanent state of learning required in an era of rapid technological change. He argues that mastering specific tools matters less than developing the meta-skill of continuously learning new tools, maintaining beginner’s mind, and adapting to constant technological flux. ∙ Kelly, K. (2016). The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future ∙ Kelly, K. “Techno Life Skills” (http://kk.org/thetechnium/) ∙ Fast Company: “Why Being An Eternal Newbie Leads To Awesome Work” (https://www.fastcompany.com/3014443/why-being-an-eternal-newbie-leads-to-awesome-work)

• Childhood's End, May 25, 2025

• Finding Passion in China, November 30, 2025

• The Art of Not Making It, November 16, 2025

Nye’s Digital Lab is a weekly scribble on creativity. After last week’s post, a few trusted folks reached out: “That’s great Nye. Can you explain what you mean by agile?”

So! Here’s my deep dive on agile as an educational opportunity.

Walk into any animation studio and you’ll witness a methodical ballet of specialization. Concept artist to modeler to rigger to animator to lighting to compositor. Each team waits for the handoff. Months later, the shot is complete.

This is the waterfall pipeline[1], named for its one-way flow through sequential stages. It’s elegant, proven—and super catastrophically bad at handling change.

When a director decides halfway through production that the dragon needs to be purple instead of green, every department downstream redoes work. Schedules slip. Budgets go nuclear. The rigidity that makes waterfall predictable makes it fragile.

Now walk into a game studio. You’ll see something radically different: teams huddled around whiteboards covered in sticky notes, organizing work into sprints (focused one or two-week bursts)[2]. Daily standups share progress and blockers. At sprint’s end, there’s a working build—not perfect, not finished, but playable, testable, changeable. The focus is on the MVP, the minimum viable product—the simplest working hypothesis of a moment in development.

This is agile development[3], born from software engineering’s realization that you can’t predict everything upfront.

Repeat after me.

Things will change.

Players might hate your brilliant mechanic. Features might prove impossible. Markets shift. In agile, these aren’t disasters—they’re just what it is.

The philosophical difference matters. Waterfall says “plan perfectly, then execute.” Agile says “learn constantly, adapt quickly.” Waterfall builds concrete bridges. You need to get blueprints right because you can’t move support columns after the fact. Agile explores jungles like Indiana Jones; running from native uprisings by whip-swinging over pits.

For games, this difference is existential. Interactive systems generate emergent, unpredictable fun. You can’t waterfall your way to engaging gameplay any more than you can waterfall a good conversation. The key to a good sprint is rhythm: build, test, learn, adapt[4]. It’s the scientific method at speed, and it matches creative problem-solving’s volatile nature.

The weekly cycle of agile reveals deeper value that higher education has yet to fully embrace.

Traditional education loves depth. There’s a quarter on C#, another on 3D modeling, a third on narrative design. We structure education systems around measurable, sequential outcomes. Works for the spreadsheets, right?

Agile forces something different: cross-functional collaboration under time pressure.

In a game jam or two-week sprint, you can’t be precious about your specialty. Programmers learn enough design to make smart system decisions. Artists pick up basic scripting. Designers understand technical constraints for realistic scoping. You develop conversational fluency across disciplines—real utility, ruthless problem solving.

This is CrossFit for your brain. Traditional strength training isolates muscle groups—leg day, arm day. CrossFit demands coordination across systems through varied functional movements. You’re not building the biggest biceps; you’re building resilience for unexpected challenges.

In agile, you learn to be adaptable.

Each cycle presents new problem constellations requiring different skill combinations: heavy technical work, creative storytelling, UX optimization, teaching teammates. Your brain can’t settle into comfortable expertise. It stays in adaptation mode.

Research from UCLA supports this. Robert and Elizabeth Bjork introduced “desirable difficulties”[5]—their work shows learning is most durable when we must retrieve information from memory, transfer skills to new contexts, and interleave different problems rather than blocking practice in single domains. Agile’s rapid cycling naturally creates these conditions.

Training lightly across multiple disciplines rather than deeply in one doesn’t just accumulate specialized knowledge, it develops learning capacity itself.

You’re getting good at getting good at things. You’re building the meta-skill of rapid skill acquisition, which matters more when specific technical skills have half-lives measured in years, not decades.

Weekly sprints also build psychological resilience: managing scope, negotiating deadlines, handling critique, restarting after failure, shipping imperfect work.

These aren’t bonuses—they’re the reality of building with teams.

Coding assistants already write production code. When we solve our IP crisis, art tools will generate publication-quality imagery. Agents will compose music, edit video, design levels, prototype mechanics. The agents are here, and X announces another radical update daily. Soon (very soon) your personal machine will handle most technical execution we currently spend years mastering.

You describe a game system, it generates working code. You sketch a character, it produces a rigged, game-ready asset. You outline narrative structure, it drafts dialogue trees.

What’s left for humans? The waterfall mindset collapses. Deep specialization in technical execution becomes obsolete (unless something breaks, of course).

This doesn’t make human creators obsolete. It makes agile thinking mandatory. The sprint cycle becomes your operating mode because every tool, every interface, every technical capability constantly evolves.

To steal from Kevin Kelly: we become “forever noob”[6]—permanently in beginner’s mind, always learning new tools, always adapting, never settling into comfortable expertise because the ground keeps shifting. This sounds exhausting. But so is training for marathons or track. Agile already trains this athlete-style mindset. Weekly cycles of new problems, new team configurations, new technical challenges prepare you for perpetual adaptation.

Agile, created to manage software uncertainty, turns out to be training for human uncertainty in an automated world. Those weekly sprints aren’t just building games and apps—they’re building the cognitive and emotional resilience to stay creative and relevant when your expertise regularly becomes obsolete.

Agile isn’t just project management. It’s rehearsal for the rest of your career.

Thanks for reading. I do this every week. If you vibe to the ideas I express, consider subscribing or sharing with friends. For those who like the printed experience, I grabbed a selection of last year’s best and crammed them into a book.

We’ll see you next time.

[1]

Waterfall Methodology in Animation/VFX: The waterfall model, first formally described by Winston W. Royce in 1970, is a sequential design process where project progress flows steadily downwards through several phases. In animation and VFX pipelines, this manifests as concept → modeling → rigging → animation → lighting → compositing, with each phase completing before the next begins. This sequential approach is particularly evident in traditional film production workflows. ∙ Royce, W. W. (1970). “Managing the Development of Large Software Systems” ∙ Wikipedia: “Waterfall model” (https://en.wikipedia.org/wiki/Waterfall_model) ∙ ResearchGate: “A traditional waterfall model of visual effects” (https://www.researchgate.net/figure/A-traditional-waterfall-model-of-visual-effects-as-part-of-a-waterfall_fig1_309242218)

[2]

Agile Sprints in Game Development: Sprints are time-boxed periods (typically one to four weeks, most commonly two weeks) during which teams complete a focused set of work. In game development, sprints enable teams to deliver working builds regularly, adapt to changing requirements, and iterate based on feedback. ∙ Keith, C. (2010). Agile Game Development with Scrum. Addison-Wesley ∙ Codecks Blog: “A Step-by-Step Guide to Planning and Executing a Game Development Sprint” (https://www.codecks.io/blog/a-step-by-step-guide-to-planning-and-executing-a-game-development-sprint/) ∙ Starloop Studios: “Best Agile Practices in Game Development” (https://starloopstudios.com/best-agile-practices-in-game-development/)

[3]

Agile Methodology Origins: Agile software development emerged in the early 2000s as a response to the limitations of waterfall methodologies, emphasizing flexibility, iterative development, and responsiveness to change. The Agile Manifesto (2001) established core values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. ∙ Beck, K., et al. (2001). “Manifesto for Agile Software Development” ∙ Mountain Goat Software: “Agile and Scrum for Video Game Development” (https://www.mountaingoatsoftware.com/presentations/agile-and-scrum-for-video-game-development)

[4]

Sprint Rhythm and Iteration: The build-test-learn-adapt cycle is fundamental to agile methodologies, particularly Scrum. Game development sprints incorporate daily standups, sprint planning, sprint reviews, and retrospectives to maintain this rhythm and enable continuous improvement. ∙ Schwaber, K. & Beedle, M. (2001). Agile Software Development with Scrum ∙ ScienceDirect: “The role of Sprint planning and feedback in game development projects” (https://www.sciencedirect.com/science/article/abs/pii/S0164121219300974)

[5]

Desirable Difficulties: Robert A. Bjork first introduced the concept of “desirable difficulties” in 1994, referring to learning conditions that make acquisition more challenging but enhance long-term retention and transfer. Key desirable difficulties include retrieval practice, spacing, interleaving, and variation. The theory distinguishes between short-term performance (which appears better with easier learning conditions) and actual long-term learning (which benefits from challenge). ∙ Bjork, R. A. (1994). “Memory and metamemory considerations in the training of human beings.” In J. Metcalfe & A. Shimamura (Eds.), Metacognition: Knowing about knowing (pp. 185-205) ∙ Bjork, R. A., & Bjork, E. L. (2011). “Making things hard on yourself, but in a good way: Creating desirable difficulties to enhance learning.” In M. A. Gernsbacher & J. Pomerantz (Eds.), Psychology and the real world: Essays illustrating fundamental contributions to society (2nd ed., pp. 59-68) ∙ Bjork, R. A., & Bjork, E. L. (2020). “Desirable difficulties in theory and practice.” Journal of Applied Research in Memory and Cognition, 9(4), 475-479

[6]

Forever Noob: Kevin Kelly, founding executive editor of Wired magazine, coined the phrase “You will be a newbie forever” as part of his “Techno Life Skills” to describe the permanent state of learning required in an era of rapid technological change. He argues that mastering specific tools matters less than developing the meta-skill of continuously learning new tools, maintaining beginner’s mind, and adapting to constant technological flux. ∙ Kelly, K. (2016). The Inevitable: Understanding the 12 Technological Forces That Will Shape Our Future ∙ Kelly, K. “Techno Life Skills” (http://kk.org/thetechnium/) ∙ Fast Company: “Why Being An Eternal Newbie Leads To Awesome Work” (https://www.fastcompany.com/3014443/why-being-an-eternal-newbie-leads-to-awesome-work)

• Childhood's End, May 25, 2025

• Finding Passion in China, November 30, 2025

• The Art of Not Making It, November 16, 2025