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.
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.
Ann Wong Hi Ann, no I think as mentioned the users just loves 'coin' so gets utility from the very first coin and each coin after. But you raise a good point and you could replay this with an MVP of several coins all stacked followed by a number of increments and see who comes out top. Also this system allows faster user feedback of deliverables, I've played it where halfway through the market shifts and copper coins aren't wanted anymore, try that and play again! Etc. Etc.
He he, yes agile teams defo need to be prepared to pivot/spin/be agile right, and that then affects tool-choice and everything like that. I think that's David who said it, he's pretty clued up chap, and I think he was playing devil's advocate. There is some truth in what he says though, and having stories/spec/requirements change too much can break a team's morale. Hopefully a sensible PO and Scrummaster can give some level of stability. Even if the product is based on fickle Hollywood celebs or something there should be some continuity that can be abstracted. Easier said than done, I've observed and even been in Scrum teams that have let the Sprint Backlog get changed and added to as we thought we were doing a favour. Sometimes with hindsight we'd have pushed the discipline and forced the pain on them until the next Sprint Planning when they'd have hopefully learnt their lesson and refined the backlog well and brought their A-game to sprint planning. What's your experience Carl?
While change is inevitable and often desirable, changes at the iteration boundary are less wasteful. A little disciple and good will by all parties can keep value flowing
Thanks Hugo, I am going to make some more live coaching game videos in the near future... meanwhile I'm just going through some Product Owner perspective videos, team/organisational change, and then a video questioning the evidence of agile/waterfall/other methodologies. Please Subscribe for notifications.
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.
Good setup and description on Agile and the coin game and reasoning for using. Enjoyed the multitasking bike commute too. Thanks.
Easy to follow. I needed a refresher on how to facilitate the game. Thank you
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.
Good job, entertaining and informative.
Thanks for this :) Recently promoted Project Manager here and learning all I can to ensure efficiency in my teams.
Awesome Game!! Congratulations by the approach and thanks for sharing !!!
A fun way to instil the Agile methodology. I can imagine being in a situation at work and remembering back to these workshops.
Hello! very good illustration of the coin game
Awesome representation
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.
Ann Wong Hi Ann, no I think as mentioned the users just loves 'coin' so gets utility from the very first coin and each coin after. But you raise a good point and you could replay this with an MVP of several coins all stacked followed by a number of increments and see who comes out top. Also this system allows faster user feedback of deliverables, I've played it where halfway through the market shifts and copper coins aren't wanted anymore, try that and play again! Etc. Etc.
That guys who likes waterfall because he finds constantly responding to what the customer wants a drag 😂😂😂
He he, yes agile teams defo need to be prepared to pivot/spin/be agile right, and that then affects tool-choice and everything like that. I think that's David who said it, he's pretty clued up chap, and I think he was playing devil's advocate. There is some truth in what he says though, and having stories/spec/requirements change too much can break a team's morale. Hopefully a sensible PO and Scrummaster can give some level of stability. Even if the product is based on fickle Hollywood celebs or something there should be some continuity that can be abstracted. Easier said than done, I've observed and even been in Scrum teams that have let the Sprint Backlog get changed and added to as we thought we were doing a favour. Sometimes with hindsight we'd have pushed the discipline and forced the pain on them until the next Sprint Planning when they'd have hopefully learnt their lesson and refined the backlog well and brought their A-game to sprint planning. What's your experience Carl?
While change is inevitable and often desirable, changes at the iteration boundary are less wasteful. A little disciple and good will by all parties can keep value flowing
Hey, are great videos. Why no more exist videos? 😭
Thanks Hugo, I am going to make some more live coaching game videos in the near future... meanwhile I'm just going through some Product Owner perspective videos, team/organisational change, and then a video questioning the evidence of agile/waterfall/other methodologies. Please Subscribe for notifications.
Need agile games to be played with our customer
Great!!!
I took the 3 minute intro out and put it into another video HTH!
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.