Dec. 2, 2011

Tips and Tricks for the beginner Product Owner

Embrace to fail fast! Product Owner @riskmanagement Most people are afraid to fail. Shame, is the core of the fear of failure, as psychology resear...

Embrace failing fast!

Product Owner @riskmanagement

Most people are afraid to fail. Shame is at the core of the fear of failure, psychologists say (see Dr. Brené Brown @TED). The problem with fearing failure, though, is that it does nothing but help you fail.

In our western culture, shame is a driver to get others to do things. By using shame and guilt as tools, we do not only burden us with an emotional baggage that is wearing us down emotionally, but we also create a lot of dysfunctions as we hide mistakes in order not to be blamed.

Transparency and courage are values shared by most of the agile approaches, Scrum in particular, the opposite of shame and guilt. We can choose to try to live our lives on our own terms: either by trying, failing and learning or by remaining in the swamp of shame and guilt and not improving. When you feel guilty and ashamed, you behave accordingly. Your mind will keep thinking about what happened and will not allow you to change anything as this would mean acceptance of the failure.

If all went well the first time we tried, we would never ever get any better. As we strive for perfection, we should embrace failures as they give us the chance to grow. Inspection and adaptation require reflection on things that could have gone better. From my experience, once people accept that they basically constantly „fail“ in the way of retrospectively not having chosen the best approach for what they wanted to achieve, they harness the incredible power of creativity and courage and gain the intrinsic motivation to do better at every future step (see Drive).

Shame is a tricky concept and a very useless one too. It has been rooted deeply in our society for maybe longer than a millennium, and that is by far too long a time. As eastern (buddhist and hindi) cultures show us, there is no need for that concept. So stop seeing yourself as a bad person because you did something wrong. Consider yourself lucky that you were given the opportunity to change your future behavior.

So accept that you could have done better, every second of your life, If you had had your current knowledge. You did the best you could, and given the situation at hand, that‘s all you could have done anyway. Wouldn’t it be awesome if we recognized a few of these „failure moments“? Wouldn’t they be an evidence that we have learned something and we can harness the power of learning to improve?

Throwing the concept of guilt and shame overboard is the first step in the direction of good agile risk management. We know that all of us could have done better constantly. So after we accept that fact, we can think about ways to make the biggest mistakes transparent.

So why should we embrace to fail fast? When diving into a new project, I am often confronted with a situation where the management fixed the time and release date, the scope of what should be released and also the quality in terms of SLAs. The first question that I ask under such conditions is: „When do you want to know how badly you are going to fail?“

While the question might be a bit confrontational, the discussion thereafter is awakening most of the time. If the „iron triangle“ (scope, time and quality) is fixed, than it is better to know as fast as possible if the plan is off or not, so that we can react and soften the damage.

As a manager, the worst thing that can happen are surprises for which expectations management is key. Agile methods are the best tool I know to get the most trustable and fast results. Worse than having bad results is having bad results late.

From my practice as a Product Owner, you need a tool to manage releases, not only Sprints. So what I do is to set up a release map and give the developers some overview about the planned high level requirements. In return, I ask them to give me a rough relative estimation about the effort of each of those requirements. Once the first requirements get broken down to little pieces, and the little pieces get estimated, I start knowing more and can do recalculations. With every completed Sprint, I gain knowledge about the progress and even in very large projects, it does not take long to get a good idea about: when it will be finished, or if we need to tighten the scope. This helps  significantly when dealing with multiple stakeholders. Particularly, conversations tend to get way more concrete when I am approached to enlarge the scope. It is easier and faster to forecast the impact of any given change.

So embrace failing fast and don’t fear to be ashamed! Every failure is a new learning opportunity if you accept it as such. Once it is there, you cannot change it anyway, but you have the chance to make the best out of it—learn something from it.

Image of fivancsich

Franz Ivancsich

blog comments powered by Disqus
Image of fivancsich

Franz Ivancsich

Latest Posts

Jan Barnes joining agile42

Jan Barnes joining agile42 as an Agile coach in the Canada team

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.