For nearly three months now, I have been part of the Pyxis Technologies’ team in Montreal, as Scrum Master and team coach. Since I got here, I have had the opportunity to observe several coaches in their day-to-day work and attend several training courses (I consider sharing these experiences in detail in a next post).

What I wish to share here is two tools that I have discovered and especially appreciated, because of their practical and easily reusable nature.

1. Organization: Which Agile approach should we use and for which context?

team_value

When we want to optimize the framework of one or several complex products or projects, Agile approaches appear to be good solutions. But with Scrum, Kanban, Scrumban, XP, SAFe, LeSS, Nexus, etc., there is a plethora of models and tools and it is sometimes difficult to find your way or to identify the framework that would be best suited to the context and the needs.

This graph is a mnemonic way to easily identify which methodology could be appropriate, according to the “Product(s)/Team(s)” axes.

  • One team works on one product: experiment with Scrum.
  • One team works on several products: a Kanban approach could be more adapted.
  • Several teams work on the same product: turn toward a framework that would allow the adoption of an Agile approach on a larger scale.
  • Several teams work on several products: ouch, there it might be more complicated… 😉

2. Prioritization Help: “Value vs Risk” Graph

value_risk

This second tool seemed very useful for Product Owners and at the same time very simple. It allows positioning the product backlog items according to two axes: Value and Risk.

  • Value Scale:
  • Which features could bring the most satisfaction to users?
  • Which ones would be the most interesting from a return on investment point of view?
  • […]
  • Risk Scale:
  • Which features involve dependencies with other teams or applications?
  • Which are the ones whose complexity is unknown?

Download our White Paper : Managing project portfolios with the business value

In short, this graph allows to visualize the backlog items according to two variables in order to have a global and relative view between all the items (we could replace the “Risk” axis by “Effort” if it makes more sense…)

Once all the elements of the product backlog are positioned, it is easier to prioritize them. For example:

  1. Start by developing the features that bring the most value and entail the most risk (thus, the risk aspect could be put aside quickly…?)
  2. Then, develop the features that still bring a lot of value, but less risk.
  3. If the budget and the delay allow it, finish the features that bring little value but entail no risk.
  4. The features that bring little value and entail a lot of risk should not be developed (the return on investment would be close to zero, or even negative).

In conclusion, these are two simple visual tools that everybody is free to appropriate and adapt to their context.

They are not meant to dictate a way to do things, but rather to bring support to the reflection about the organization of a team or the prioritization of a product’s features.

Previous post

Coaching: the sometimes forgotten element in Agile coaching

Next post

Why the rush? Interview with Steffan Surdek, co-creative leadership consultant

Lucie Lesage

After an experience in Marketing, Lucie initially chose to revisit Product Management to put her creativity at the service of Agility. With a significant experience as a Product Owner, she likes to be close to development in order to bring users' needs, business expertise and technical aspects together.

Throughout her experiences, Lucie has always naturally facilitated exchanges and collaboration between the different profiles that make an organization. Joining Pyxis as an Agile Team Coach was therefore the logical next step, where she now has the opportunity to put her energy and listening ability at the service of continuous improvement and the pursuit of excellence.

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *