One of my favorite, old-time rock groups is Emerson Lake and Palmer. And their song From the Beginning seemed appropriate for this article.
One of my new favorite voices in our agile community is Sandy Mamoli out of New Zealand. I’ve read oodles and oodles of her work, but I have yet to see her in person. Fingers crossed, I get that chance soon.
One of the more interesting things that Sandy is focusing on is team self-selection when it comes to how to organize around projects and work. Recently Sandy wrote a piece entitled: Giving Teams the Best Start.
In it she emphasizes the work that Ainsley Nies and Diana Larson have done in their book Liftoff, which just released its second edition.
In his latest newsletter, Len Lagestee wrote about Even Happier Product Owners. The piece shared 9 conditions of happiness for the Product Owner. Here’s a link to the blog post.
And here’s the list:
- They are immersed with their customers;
- They have the time and space to be visionary and creative;
- They have true ownership over their product;
- They are receiving meaningful feedback about the performance of their products;
- They have a positive working relationship with their Scrum Master;
- They have an even better relationship with technical leads and designers;
- They are proud of what the team is delivering;
- They have embraced their constraints;
- And, they are keeping themselves healthy.
I really like Len’s list as a baseline for the happiness and performance of the Product Owner role. I’d like to compare the list against my 4-Quadrants of the Product Owner role model.
Mike Cohn in a recent newsletter entitled: The Dangers of Definition of Ready made some solid points that have had me “thinking” ever since I read it.
You see, I’ve been a proponent of DoR for at least the past five years or longer in my coaching. I often “couple” the discussion with two areas:
- Definition of Done
- And as an “exit criteria” for Backlog Refinement
I actually consider DoR to be one of the healthier agile practices and I often recommend it to my clients. So I read Mike’s cautionary article with some trepidation. Hoping that I haven’t been misleading my clients in some way.
I’ve captured Mike’s exception to DoR in the below snippet from his post:
I just read a truly interesting HBR article that focused on the role of management versus team members themselves in fostering an environment of creativity and innovation.
Most of the discussions today in this space, at least in my experience, are focused towards leadership or management being responsible for innovation. That is – in setting up the environment
Very little of the focus is team ward. In that, the team bears some responsibility for its own behavior, energy, and focus towards innovation.
The HBR article had some survey data that puts “the blame” squarely on both shoulders – that of “management” and the “team” in establishing the right climate.
In my view, that’s the right focus since we all play a part in creating an environment of experimentation, innovation, and creativity.
In my previous post I shared about experience I’ve had in “connecting” UX activity into Scrum development teams. I tried to explain a pattern of collaborative partnering over either embedded UX in the teams or independent UX outside of the teams.
I thought I’d share another story that illustrates an aspect of these ideas.
A Story
Not that long ago I was working with a client helping them understand and practice release-level planning across their Scrum teams. Some of the challenges they were having revolved around incorporating UX design work and cross-team dependencies in their projects.
Matt Kortering of Universal Mind, wrote a blog post about How UX Fits Within a SAFe Environment. Lately I’ve been thinking about and writing about the scaling models, so a part of this fits well with current themes.
But I don’t want you to get stuck on the SAFe bits here. I truly want this to be a generic blog post about handling UX concerns and x-team integration within any agile method or approach.
Here’s what Matt had to say towards the end of his post:
In order to successfully engage UX within SAFe, there are a few other things to remember…
A few years ago I quantified the 4 Quadrants of the Product Owner role as a means of communicating the depth and breadth of the role.
My intention at the time was to provide guidance to agile teams about the level of difficulty in performing within the role. I also had the intent to provide enough nuance so that Product Owners would realize that they typically would need help. That even though Scrum emphasizes a singular Product Owner per team (backlog), that more than one person might be needed to help fill all of the requisite skills and daily chores.
As part of the 4 Quadrants, I bundled the activities of a Business Analyst under the Product Owner role. It doesn’t mean that the Product Owner needs to be a Business Analyst. It just means that they have to either (1) have these skills themselves, or (2) have access to these skills within their team in order to effectively perform their job.
Scrum is all about rhythms. Teams that are successful with Scrum establish a sustainable cadence for collaborating with each other. Each of the sprint ceremonies help us move toward our goal, and remind us what’s coming next.
Scrum is pretty straightforward about how to establish the right rhythms for the team, but organizing your work as a product owner is a little murkier. You know that sprint planning happens every two weeks, but what do you need to do to prepare? Your team does backlog refinement for an hour every week, but how far in advance do you need to start working on stories to make that meeting worthwhile?
In this article, I’ll share the rhythms that have worked well for me as a product owner. The Scrum ceremonies act as a trigger – a reminder that there’s something I need to do. I’ll organize this article by those triggers, and we’ll work our way backward to see what we need to do to prepare.
For years and years, I’ve been talking about the importance of Sprint Goals in the fabric of Scrum team execution. They:
- Help to guide the focus and conversations at the daily standup and the team’s daily activity;
- Help to focus the team’s sprint planning towards an outcome;
- Help to identify the purpose and focus of the sprint demo;
- Help the Product Owner and the team in making sprint content trade-offs if the run into difficulties;
- Ultimately help the team define what “success looks like” for each and every sprint.
Given that definition, my clients usually start looking at Sprint Goals in a different way. I see them as being very powerful mechanisms for focusing the team’s efforts and I hope you start to as well.
Until they realize that:
They have to sometimes say NO to some stakeholders;
They have to make decisions; short term vs. long term; tactical vs. strategic; now vs. later;
They have to peer into the future and anticipate customer needs;
They have to aggregate opinions from multiple, sometimes very powerful and unique, voices;
They have to trust their teams;
