I am listening to the audiobook “The subtle art of not giving a fck” from Mark Manson and I am learning awesome things that can relate to our world of “Agile” and “Product Ownership.” The style of the writing doesn’t suit me well, but I can appreciate many points he's making.
The book defends a position on how to choose and prioritize the things we give a fck about. Curiously, I find it connects with Product Owners and Scrum Teams. Here's how.
Entitlement
“When you think you deserve to be treated as special or deserve something special. That happens when you think you are way more awesome than everybody else, or you think that everybody else is way more special than you are.”
This is a common team dysfunction, also seeing across the organization at any level. Have you observed this during an Agile transition? How did that go? How do you help with the situation at hand? Mark explains that's BS, you are not special and I like that idea.
Values
Just like described in the Scrum Guide, the author defines a set of 5 values, helping to guide your decisions on what to give your fck. Here they are: “Radical Form of Responsibility, Uncertainty, Failure, Rejection, Contemplation of One's Mortality.” I find these are appealing for a Product Owner. Let’s see why.
Radical Form of Responsibility
"... Taking responsibility for everything that occurs in your life, regardless of who's at fault...”. For me, this translates to my definition of “professionalism.” Professionals won't be giving much attention to the person who's at fault, they will focus on creating a quality, working software. The 'blame game” doesn't work well in a complex environment when solutions need to emerge from a cross-functional team.
Uncertainty
"... The acknowledgment of your own ignorance and the cultivation of constant doubt in your own beliefs.”
For me, this translates into doing experiments and proving or disproving the hypothesis formulated when deciding what to build. You don't know how much value it will bring. The only thing you know is what happened in the past. Use uncertainty to your advantage, experiment and learn!
Failure
"... The willingness to discover your own flaws and mistakes and that maybe they can be improved upon.”
You now understand that I see Product Owners as scientists. They formulate a hypothesis, deciding what to build in order to have an impact on some customers and therefore fulfill a goal. In that case, embrace the feedback, good and bad. Especially the bad ones, those are the ones that will kick you outside your comfort zone and hopefully will get you more creative than ever.
Rejection
“The ability to both say and hear ‘no’ thus clearly defining what you will or will not accept in your life.”
In the life of a professional, that's a no brainer to translate. Saying yes to everything is lying knowing that you won't be able to fulfill your all your promises. And lying is not being in good standing with your values. We hire professionals, we are professionals because we have the right knowledge to say 'no' in due time. Product Owners will say 'no' when ordering their Product Backlog, they will say 'no' when a detractor asks for something irrelevant.
Contemplation of one's own mortality
"... Paying attention to one's own death is perhaps the only thing capable of helping us keep our other values in proper perspective.”
Whoa, this is a deep one! Take this to the team and ask the question: “How can we ‘be’ to ensure we deliver quality software and keep this software in its best shape? If we get dissolved tomorrow, how would you like to remember us?" Take this to the Product Owner: What will you build if you had only one iteration? What's the “wow” effect?
How would you take this to your organization?
Importance of the right metrics
Mark Manson also talks about metrics and how some of them won't help you much and will give you a false sense of success. In his book, he describes these metrics as “extrinsic.” Better metrics are the ones he calls “intrinsic,” they come from inside you. How do you measure success? The metrics are important. While teaching Professional Scrum Product Owners, we use the Evidence-Based Management to explain what better metrics would be to measure and improve over time.
I am not done listening to the audiobook. I was just so excited while hearing the first few chapters and I wanted to share my observations on how I relate this surprising audiobook to the Agile world. I may be biased having my head in the ‘Agile World ‘constantly, but darn, it just makes sense to me. Just like other stuff, I read around big wall rock climbing and that’s another story!
Scrum On!
Simon