Have you noticed that your Scrum teams are running Sprints and doing reviews, but are still not seeing the kinds of improvement in product quality, value, and team productivity that you were hoping for? One of the reasons for this could be that the members of the team do not completely understand their roles. In particular, it has been my experience that Product Owners are frequently not indoctrinated into the Agile way of developing products and are not taught how to actually be a Product Owner. In fact, my experience with teaching the Certified Scrum Product Owner (CSPO) training over several years tends to indicate that, while there has been an increase in CSPO classes, most real-life Product Owners have no idea how to do their jobs in an Agile environment.
If you don’t have the time to invest in formal training, let me suggest one thing your Product Owners (or you) could do to improve the productivity of your Scrum teams, and improve the quality and value of your products: communicate!
Product managers are used to getting the product requirements documented and, while still answering questions every now and then, letting the development teams do the job of building what was documented. Product Owners must change the paradigm from answering questions when asked to being a team member with the rest of the developers and taking an active interest in what is being built, how it operates, and whether or not you like what you’re seeing come to life. As a Product Owner, you must come to see your job as creating a product, not simply managing its development.
For Scrum teams, collaboration and communication are paramount. As communication decreases, risk and cost and waste increase. You should plan to be with your team for a little while (1-2 hours) every day. As they build, you should try to see what’s coming to life. If you like it, great! If not, it’ll be easier and less expensive to fix now than to wait for the Sprint Review or, worse, live use of the product.
Requirements change — more than that, even when understood, reality is often different than what was desired. In other words, even if the developers on the Scrum team understand the requirements, what gets built may still not be what you, the product owner, want. Talk with your team, help them build the right product the first time. You’ll definitely see a big difference!
More About #TransitioningToScrum
Agile Transformations – Is It All-Or-Nothing?
Wondering where to start with agile transformation? Do you pick a single project? Or a specific team? Train everyone and run with it? Here's some guidance.
Leading the Way to Organizational Change
As a ScrumMaster and organizational change advocate, here's 7 things you can do to help your organization embrace change as a normal way of life.
What Causes Conflict on a Team?
Change usually creates conflict, but a good ScrumMaster knows what types of conflict to expect and is prepared to handle it with correct conflict responses.
It’s All About Value
One small change can make a BIG difference to your Product Owner success. Before worrying about putting value on backlog items, here's some simple tips.
What Does it Mean to BE Agile?
With the Agility mindset, it's critical to understand the concept of "being" Agile. Some people want "to do Agile", but you don't DO Agile, you must BE Agile.
Should Scrum Teams be Dedicated to a Single Product?
Should Scrum teams be dedicated to a single product? The truth is, there's times when you want a dedicated team and times when you don't. Let me explain!
Creating the Skills You Need for Agility
When beginning the transformation to Agile Development, it's hard to know exactly what skills the organization needs to adapt to the new way of working.
What is the Role of the ScrumMaster?
Although the Scrum Guide defines the ScrumMaster at length, here we're going to dissect that description and take a much closer look at what a ScrumMaster is.
What Do Testers REALLY Do On a Scrum Team?
Analysis, design, coding, and testing are done constantly rather than in phases, meaning testing ISN'T just a phase but an ongoing part of Agile Development.
Leave A Comment