Agile Coin Game - Smaller batches win every time - Lean - Continuous Deployment

preview_player
Показать описание
Detailing Agile Manifesto principles around early and frequent delivery and welcoming changes in requirements.
Breaking up monolithic requirements, delivering early and frequently can help iterative and incremental delivery patterns produce faster, better products and services

I'm on LinkedIn if you want to hire me for your team's agility
Рекомендации по теме
Комментарии
Автор

This is the first in a series of videos I did to teach agile principles through games. It highlights how breaking product delivery up leads to early and frequent delivery and allows for adaptability.

theagilecoach
Автор

Easy to follow. I needed a refresher on how to facilitate the game. Thank you

WorthItToYou
Автор

Good setup and description on Agile and the coin game and reasoning for using. Enjoyed the multitasking bike commute too. Thanks.

woobie
Автор

Thanks for this :) Recently promoted Project Manager here and learning all I can to ensure efficiency in my teams.

heididewhirst
Автор

A fun way to instil the Agile methodology.  I can imagine being in a situation at work and remembering back to these workshops.

DavidClementHorton
Автор

Awesome Game!! Congratulations by the approach and thanks for sharing !!!

andremavericks
Автор

Good job, entertaining and informative.

taykratzer
Автор

Hello! very good illustration of the coin game

Автор

Did the agile team also need deliver a stacked set of coins? If not then the two teams were not asked to deliver the same thing rendering the comparison unequal.

annwong
Автор

That guys who likes waterfall because he finds constantly responding to what the customer wants a drag 😂😂😂

MrHubbers
Автор

Need agile games to be played with our customer

charuhgupta
Автор

Hey, are great videos. Why no more exist videos? 😭

hugokmlourenco
Автор

I took the 3 minute intro out and put it into another video HTH!

theagilecoach
Автор

I'm sorry, but this doesn't make any sense at all. So you're asking one team to do an entirely different thing, which has nothing to do with the different methodologies of business or development. By the same logic, you could also remove persons 2 and 3 and conclude that we shouldn't be doing quality control and marketing as all it did in this example is delay the handing over of the coins to the user. I'm all for making simple principles visual and clear, but this has nothing to do with anything other than giving two different sets of people two different tasks.

ralphschraven