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?
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
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:
- Start by developing the features that bring the most value and entail the most risk (thus, the risk aspect could be put aside quickly…?)
- Then, develop the features that still bring a lot of value, but less risk.
- If the budget and the delay allow it, finish the features that bring little value but entail no risk.
- 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.