Blog

Game Play with Practice Patience

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.

Introduction to the Scrum Essentials

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.

Blueprint Software Systems Interviews Dr. Ivar Jacobson

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.

Part 4: Some practical tips to avoid waterfalling features

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.

Part 3: What Does it Mean for a Feature to be Ready?

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 3 of this series, Ian Spence provides guidance on what it means for a Feature to be Ready.

Subscribe to Blog