In part three of this blog series, Brian and Ian review how a team played the Practice Patience game. They had been a Scrum team for over 6 months and were used to holding more traditional open ‘brainstorming’ style of retrospectives. The article reviews their experience with the cards guiding them to improve their application of Scrum, including some quotes from their Scrum Master.
In this blog article, the authors share the first game that can be played using the Scrum Essential Cards. Use Practice Patience as a great way to perform a holistic retrospective on your Scrum adoption.
IJI has recently had the pleasure of working with Jeff Sutherland on a set of Essence cards that faithfully represent the Scrum Guide. As well as acting as a handy physical, and online glossary, the cards can be used to play games and help us all get better Scrum.
In this new blog series, Brian Kerr and Ian Spence present a selection of the games you can play using the Scrum practice cards and, in some cases, other cards from Essence itself or from other complementary practices.
Use-Case adoption is growing again: In this interview ‘Use Cases and its role in Agile Software Development’ by Blueprint Systems, Dr. Ivar Jacobson explains how Use-Case 2.0 includes everything important about user stories, but offer significantly more for larger systems, larger teams, and more complex and demanding development projects than user stories alone. They are as lightweight as user stories but can also scale in a smooth and structured way to incorporate as much detail as needed. Most importantly, they drive and connect many other aspects of software development.
Many teams struggle to let go of their waterfall, silo mentality when they first transition to agile ways-of-working. In particular they shy away from collaboratively working on the definition, evolution and implementation of their backlog items insisting on up-front definition of Features and Stories, and clean handovers between the Product Owners and the Development Teams.
This is an issue that we see with all the various agile methods but which always seems to get compounded whenever teams try to scale. So what are the worst things you can do to compromise the agility of your program when using Features? In Part 4 of this series, Ian Spence provides some practical tips to avoid waterfalling your features.
