Delivering Value Using Scrum with Andrea Floyd Agile Coaches' Corner

This week, Dan is joined by fellow AgileThought colleague and return guest, Andrea Floyd! Andrea is an enterprise agile transformation consultant at AgileThought with over 25 years of experience in software development and management. She is an innovator who has led multiple organization-wide scaled agile implementations, and she has also architected innovative solution strategies and roadmaps across many frameworks (including Scrum, Kanban, and the Scaled Agile Framework).
 
In their conversation today, they discuss delivering value using Scrum — what it looks like, why it is important to focus on, how to introduce the concept of value delivery in the product life cycle, and how to begin measuring the value of what you’re delivering.
 
Key Takeaways
Why is delivering value using Scrum important?
People want to know why they’re doing what they’re doing (and understanding how they are delivering value using Scrum answers that question)
Understanding what value you’re bringing ensures that you’re working on the right thing/s at the right time
In order to make certain business decisions, it is key to measure: “Are we getting the outcomes that we’re seeking?” and, “Are we actually making a difference in the eyes of our customers or users?” Do they see and feel what we’re providing and delivering in terms of capabilities is valuable?
How and when to introduce the concept of value delivery in a product life cycle:
There are a few entry points to consider
At the organizational leadership level, they need to be outlining what they feel is valuable to the organization
If leadership outlines what is valuable to the organization, everybody is able to check in with that
Someone at the top of the organization should be setting the alignment (and allowing it to cascade down through the organization)
At a product or a project level, you should start thinking about delivering value by encapsulating it in features (and having those features be on your product roadmap [which will then inform and drive your product backlog])
At a product or team level, apply your focus to talk about value at the feature level (think about the mechanisms to timebox features)
Tips, tools, and techniques to measure the value of what you’re doing:
Answer the question: “Have we moved the needle in anybody’s world? How so?”
Organizations should be embracing transparency and trust so there is more access to communication (and so people know the context they’re operating in)
Consider looking at how you do your portfolio management and have that work be hand-in-hand with investment decisions (which then will influence how you organize around the work or the product)
Leverage techniques in work management tools (such as Jira, Azure DevOps, etc.) where you can put effort at a feature level (just like you would do at a story level)
Use some form of relative sizing to forecast based on what you know today
If you are able to do feature points, map the features on the product roadmap
Leverage product goals to help your team ensure that the emergence of their product backlog aligns with the product goal
Use product goals to help you focus on the right items (in the right sequence) in your backlog, and refine those features so that your team can communicate to stakeholders and leaders how they are doing as they move forward
Leverage timeboxing — it is critical
You should be able to explain to your team why you are working on something (if you can’t, push it down on your backlog until you can)
How do we know when a feature is ready to be consumed by a team?
It is important to have a definition of “ready” so that the team is on the same page
Ideally, you have fields that indicate the state of readiness a feature needs to be at before it’s eligible for consideration to begin working on
Ask: “What does ready look like for a feature?” and “What information needs to be present?”
Collect data and me