Posts Tagged ‘Business Value’

Being Agile when Designing and Playing Agile Games

Friday, July 30th, 2010

By Mary Gorman

In my Stickyminds.com column “Playing at Work: Agile Games Deliver Value” I share game ideas and experiences – the benefits games can provide, selecting an appropriate game, facilitating a game, and designing a winning game.

Designing and Facilitating Agile Games

When writing the column I got to thinking how agile principles could provide a basis for good game design and facilitation. I reflected on a recent experience I had at Deep Agile 2010: Empowering Teams with Agile Games. Working in a small group we created a new game, tested it, and retrospected both the game and our design process in less than half a day. We consciously (and some times unconsciously!) were being agile! (To see and learn more about our game, read Michael Sahota’s summary at The Backlog Is in the Eye of the Beholder.)

Games and The Agile Manifesto

To clearly communicate the agile-ness of our work and what we learned I did a quick mapping to the Manifesto for Agile Software Development. Continue reading

    Share/Bookmark

The 4L’s: A Retrospective Technique

Thursday, June 24th, 2010

by Mary Gorman and Ellen Gottesdiener

We liked it when a good thing took on a life of its own.
We learned that it really resonated with many folks.
We lacked sharing the full understanding of the technique.
We longed for more sharing.

Liked Learned Lacked Longed For

At the recent Deep Agile event, Mary briefly mentioned a 3Ls’ technique she used in a recent  retrospective (Liked, Lacked, Longed For).  A few folks tweeted about it, and it took off in the web’o’sphere

To fulfill our longing to share and provide some background, keep reading to learn how we use this technique.

Many moons ago… Continue reading | 2 Comments

    Share/Bookmark

Agile Requirements: Not an Oxymoron

Friday, June 18th, 2010

Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.

Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?

Once More into the Breach

Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation.

In contrast, agile practices—leanLean, Sscrum, XP, FDD, crystalCrystal, and so on—involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software. Continue reading | 1 Comment

    Share/Bookmark