The agile essentials from Ivar Jacobson International is a starter kit of agile practices, provided as a deck of cards. Teams can play games with these cards to learn agile practices and inspect and adapt their way of working.
InfoQ interviewed Roly Stimson, Principal Consultant at Ivar Jacobson International, about why the agile essentials were created, how they can help teams to implement a practice or improve the way that they are applying a practice, how agile essentials is related to Essence and SEMAT, and about the games that software development professionals can play with agile essentials.
InfoQ: Can you briefly describe the Agile Essentials for the InfoQ readers?
Stimson: It’s a pack of poker-sized playing cards. It contains a set of seven agile practices that together describe what, in our experience, a lot of successful agile teams are practicing.
InfoQ: What made you decide to create the agile essentials?
Stimson: We were repeatedly witnessing that, despite the distracting arguments about this or that branded agile process supposedly being the one true way, good agile teams tend to select and adapt, mix and match, in quite a pragmatic way, and actually often end up with a pretty similar set of practices.
It seemed to us that there would be value in simply making these commonly selected and combined practices available in an approachable and usable form, particularly for novice teams, or teams that are struggling to emerge from the "storming" phase into calmer and more productive waters.
InfoQ: Can you explore one of the agile practices from the agile essentials, and elaborate how the agile essentials can help teams to implement a practice or improve the way that they are applying a practice?
Stimson: We’ll use the Product Ownership practice as one example.
This operates in the crucial connecting space between the customer need and the team producing the solution. It builds on the concept of a Product Owner, but adds advice around this to help teams avoid the most common pitfalls associated with a naïve interpretation or simplistic implementation of this role.
So, we have a Product Ownership card, which stresses not only the need for a strong Product Owner, but also the fact that they can’t be expected to operate on their own. They are part of the team, and need the support of the team, and to be at the centre of a network of stakeholders.
We also have a card that describes how to Build a Stakeholder Network, and another that describes how to achieve clarity and visibility of who the stakeholders are and how we will engage with them.
There are cards that describe the key activities of frequently Demonstrating the Product to get and respond to feedback, and to progressively Achieve Acceptance.
Finally there are cards that stress the need for a shared Product Vision and that we need to Evolve the Product Vision over time in response to feedback and learning.
So, taken together, the practice is a combination of standard explicit advice (the concept of a Product Owner), supported with the kind of essential pragmatic supporting advice that, say, a good Agile Coach or Scrum Master would typically be passing on to their teams verbally. But always compact and concise – so all of the above is described on just seven poker-sized playing cards.
InfoQ: In 2013 InfoQ interviewed Ivar Jacobson about the essence of software engineering. Can you explain how agile essentials is related to Essence and SEMAT?
Stimson: We used the Essence language and kernel when designing the cards, as it gives many advantages.
Firstly, it gives the cards a consistent look and feel, with visual clues, for example, as to which space the practice advice operates in (customer, solution or work), and what kind of advice it is (an activity to be performed, or something of value to be advanced, or something that is produced to make some key aspect of the work visible).
Secondly it provides a natural kind of glue, or connecting mechanism, that enables us to join the cards together. From an activity card, for example, we can follow the trail to the cards that describe its outputs, and maybe from there to an activity that uses these further along the value chain, and so on.
Finally, by building the practices around the simple, standard model of the software development problem space that is provided by the Essence Kernel, we can design practices that can be used stand-alone, but can also be used in combination with other similarly-designed practices.
InfoQ: I’m hearing people who are advocating against recipes for software development. What about the agile essentials, will people see them as recipes?
Stimson: The cards definitely don’t provide a standard recipe to be followed, step-wise, for baking a particular kind of pie, so to speak. They more say "if you"re going to be a chef working in a pie shop, then you’ll probably need to know how to make pastry, how to brown meat, how to make gravy and so forth. It’s still down to the customer and team together to decide what kind of pie they want to bake and, on that basis, what established techniques they expect to use, in among whatever new approaches they may innovate along the way.
The cards are something of a middle way, somewhere between a pre-fabricated framework like Scrum or SAFe, and the opposite extreme of telling every team to "go figure", and build an approach for themselves, from scratch, based on some (hopefully) shared values.
To use a slightly different analogy, the cards are not an Ikea flat-pack, but more like a kit of tools: hammer; nails; glue; screwdrivers and so on.
InfoQ: Can you give some examples of games that software development professionals can play using the card deck from the agile essentials?
Stimson:Most of the games that have been invented so far tend to be based on an agile team working with an agile coach or Scrum Master and a pack of cards to help them either to get started or to inspect and adapt their way of working.
One example would be Practice Assessment Tic-Tac-Toe, where the team lays out cards in a 3-by-3 grid reflecting, on the one hand, how important they see the card as being (critical, not critical, not relevant) versus, on the other hand, whether they do it well, not so well or don’t do it at all right now. On that basis they can make decisions about new things they may want to try doing or doing differently in the future.
A team might, for example, agree that they have strong Product Ownership, but don’t really have a strong enough grasp on who the key stakeholders are and how they should be engaged to ensure that they are getting all the right inputs and feedback.
InfoQ: If people are using the agile essentials, is there a place where they can exchange experiences with the games that they played? Maybe even share new games that they developed.
Stimson: Yes, we have a LinkedIn Group called Agile Essentials where we would like to encourage people to share Q&As, experiences, discoveries and innovations, including new games to play.