In my journey through the world of product development, I’ve often found myself reflecting on the importance of making informed decisions that truly benefit our users. Recently, I had the opportunity to delve into the Professional Scrum with User Experience (PSU) course, and I can confidently say that it has profoundly shaped my understanding of effective product development.
The Hypothesis-Driven Approach
At the heart of the PSU course is a hypothesis-driven approach to software engineering. This methodology encourages us to ask the critical question: Why are we adding this feature to our product?
Understanding User Needs: It’s not enough to add a feature simply because someone, like Bob from accounting, requests it. While Bob’s needs are important, we must consider the broader user base—what about the 300 other users who might be affected? If we prioritise Bob’s request at the expense of the majority, we risk alienating our core users, leading to a negative perception of our product over time.
Creating Hypotheses: The PSU course emphasises the need to create hypotheses around new features. We should ask ourselves:
- What value will this feature bring to the business?
- How will we measure its success?
By framing our decisions as hypotheses, we can better evaluate the potential impact of our choices.
Running Experiments
Once we have our hypotheses, the next step is to determine the smallest experiment we can run to validate them. This is where the magic happens:
Small Experiments: Instead of committing to a full-scale feature, we should conduct small experiments to test our ideas. This allows us to gather data and insights before making significant changes to our product.
Discovery and Design Channels: We need to differentiate between our delivery channel (what we deliver to customers) and our discovery channel (how we figure out what to create). The PSU course teaches us to run multiple experiments to identify which features should make it to our main backlog.
Bridging the Gap Between Design and Development
One of the most significant insights I gained from the PSU course is the importance of collaboration between design and engineering teams. Often, these groups operate in silos, leading to misalignment and inefficiencies.
Collaboration is Key: We can’t expect every team member to be a UX designer or a coder. Each discipline requires expertise, but everyone should have a basic understanding of design principles. This knowledge helps prevent decisions that undermine the designers’ work.
Micro-Decisions Matter: Every team member makes countless micro-decisions daily that can impact the product’s architecture and overall design. By fostering collaboration, we can ensure that these decisions align with the long-term strategic direction set by the design team.
Integrating Strategy and Continuous Delivery
The PSU course also highlights the need to balance upfront work with continuous delivery.
Unified Strategy: We must integrate our hypothesis-driven engineering into our regular delivery cadence. This means continuously running experiments—perhaps five or six each sprint—to see how our changes affect user behaviour.
Feedback Loops: The data we gather from these experiments should feed back into our product strategy. This iterative process allows us to shape our product in alignment with user needs and long-term goals.
Conclusion
In summary, the Professional Scrum with User Experience course has equipped me with invaluable tools for making more effective product development decisions. By adopting a hypothesis-driven approach, running small experiments, fostering collaboration between design and engineering, and integrating our strategies into a continuous delivery model, we can create products that truly resonate with our users.
If you’re interested in exploring these concepts further or have any questions about agile, scrum, or DevOps, I invite you to book a coffee chat with me through Naked Agility. Let’s continue the conversation and drive meaningful change in our product development practices!
So the question is how does the PSU course help teams make more effective product development decisions?
I think the main value take away from the PSU is this hypothesis driven approach to software engineering, right? To product development. Hypothesis driven approach to product development that in order to know that you want to add something to the product, you need to have a reason for it to be there. Because Bob in accounting asked for it is not necessarily a good reason to add it to the product, right? It might be the right thing for Bob, but what about the 300 other people that use your product? Is it the right thing for them? And Bob might be quite important, but if Bob’s happy and he’s important but 299 people are unhappy with the feature you’ve created, then perhaps you’re going to have a very negative impression build up slowly over time that overrides Bob and then the customer stops using your product, right? That’s that bounce.
So having, um, creating hypotheses, right? Why are you adding this feature to the product? What value is it going to bring to the business? And how are you going to measure that you’ve been successful in the changes that you make? And then even once you’ve got all of that, figuring out what’s the smallest experiment we could run to start validating that hypothesis, right? So that’s effectively what you should build first. You should be running lots of little experiments for these different little features and capabilities that you might add to the product in the future, right? You might add the full thing to the product, but we need to run lots of little experiments to figure out what are the things that should go on to the main part of the backlog that we’re actually delivering, right? That’s that delivery channel to customers. This is this discovery channel, this design channel. Are we figuring out what it is we’re creating?
And the whole team works together on that. The whole team is part of that team that helps facilitate that. And I think that that for me is the big value proposition of the PSU. But it has a kind of additional side proposition in that quite often the design team, like the designers, are separate from the engineers and the designers go design stuff and kind of hand it over to the engineers and then the engineers go build it.
And trying to figure out how do we bring that together, right? I mean, you can’t expect everybody in your scrum team to be a UX designer. That doesn’t make any sense. You’ve got to study your craft. Just like you can’t expect everybody on your team to be a coder, right? You’ve got to study your craft. You’ve got to become good at your craft and then you’re able to provide value and make the right choices and help with the team. So you’re always going to need those expert level skills for these particular skills, but there are also lots of things that everybody on the team needs to understand about design so that they don’t, what’s a good expression? They don’t cut the feet out from under the designers, right?
Because every person on your team is making lots of little micro decisions every day that may impact on architecture, the way things work, all kinds of things. It’s going to impact in the product and perhaps they’ve spent a whole bunch of time going down this route that then the designers come out with a new way of designing that then has a massive cost and impact on the way the product goes together. And that could have been maybe reduced by having these two groups work closely together so that the team better understood the long-term strategic direction of what it is that the designers are trying to do and that they can incorporate some of those things into their continuous decision making, right? That way they make more of the right decisions and less of the wrong ones.
And bringing those two groups together, so that for me is the second part to that story. Not just bringing hypothesis driven engineering in, which should be there anyway, right? But also how do we bring these two groups closer together?
Um, and how do you balance how much of this work you do up front and how you integrate it into the stream of value that you’re actually delivering on a continuous basis? So how do you bring this all together into a unified strategy so you can continue not only in the small scale, continually and repeatedly deliver value to the customers, right? But also in the hypothesis driven engineering, continuously run lots of little experiments, maybe five or six little experiments a sprint. We’re trying to see the numbers change so that we can spend more time in that area. But that data from those hypotheses are then feeding back into the story that the designers, working with the product owner and the whole team, are figuring out like where are we actually going with the product? How are we shaping and changing it? And how do we incorporate those long-term strategic initiatives into this sprint cycle where we have this regular delivery cadence?
So answering all of those questions is for me the main purpose of the professional scrum with user experience class.
Thanks for watching the video. If you enjoyed it, please like, follow and subscribe. I always reply to comments, and if you want to have a chat about this or anything else agile, scrum or DevOps, then please book a coffee with me through Naked Agility.
