Product Owner explained in 15 minutes

Lately, I’ve seen more and more comments that Scrum doesn’t support Product Management to well. I’m not sure why. Product Management is not that difficult to understand, although it can be very hard work.

I’m not a big fan anymore of Scrum as a holistic collaboration framework. The first version of the scrum guide is a good collaboration guide for complex software development. And as the name suggests, it is a guide, not a law.

That being said, the following video by Henrik Kniberg at least explains the basics of Product Ownership very, very well, especially when it relates to the development team and what a PO or PM for that matter does and does not do.

Watch and learn!

Stop hiring Agile Coaches

You don’t need them on a permanent basis.

First, I’m all for the values and principles in the Manifesto for Agile Software Development. And I believe these same values and most of the principles apply beyond the realm of software development.

Second, I’m all for collaboration within and between teams. If the Scrum Framework is a set of instrumental rules that helps use them. As a means, not as an end in itself though.

Third, I’m all for outside help with these values/principles and collaboration rules if needed. 

But

If a team/department or even an entire organisation needs permanent help with this, there’s something wrong within your team/department/organisation that has nothing to do with Agile/Scrum. There might be something wrong with any or all of these things (and the list is not exhaustive):

  • Leadership, especially with leading by example
  • Basic work ethics, such as showing up for meetings on time
  • Meaningful work as a team (ticking of to do’s, instead of solving problems)
  • The right person for the right job at the right time
  • Team dynamics on a more personal level

In any of the above things, leadership needs to step in!

Of course Agile coaches can help to teach and coach on the Agile values and principles and with the chose Agile collaboration framework of choice (except SAFe or LeSS, they are just evil). But it is a temporary thing, not a permanent thing. Here are some examples and a timeframe.

New Team > 3 months max

If you have a bright new team, with people that have never worked together an Agile Coach can help to set up the right rhythm of feedback loops and meetings, helping to crate a safe working environment and the “rituals” the team needs. So no by the book Scrum implementation please. If in 3 months the team hasn’t found their rhythm, something else is wrong. By the way, this is not full time work for 1 Agile Coach, so if you don’t have an Agile Coach that coaches several teams (5-10) hire a freelancer.

Existing team with “challenges” > 1-2 months max

If an existing team faces challenges, an outside coach can help to sort things out. Emphasis on outside coach, a person not in the team and preferably not in the organisation that reflects with the team on what’s going on and helps them out. When deeper shit surfaces and/or the problem cannot be solved in 1-2 months, there something else going on an normal management needs to step in.

Large organisation with 10 teams or more

Preferably, have a network of a couple of freelance Agile coaches that can help out. If that’s not possible, hire 1 or 2 Agile Coaches on a permanent basis to help out teams when they need them. These Agile coaches need to be fully independent and self-starters, their only job is to help solve a problem and then leave the team again. Or if new teams are formed, get them started and then leave.

Leadership that isn’t Agile > 3 months max

Now you definitely need an outsider. Never, ever use an inside Agile Coach to teach you the simple values and principles. Leadership needs to live it, action it and not just know it. If you as leadership cannot do that, look in the mirror! And for a max of 3 months you need that mirror to come from outside your organisation.

By the way: Same applies for Scrum Masters…

When frameworks and manifestos start dying

Manifestos and frameworks (Agile, Scrum, PrinceII, ITIL, <insert example here>) start dying the moment they become “ends”, goals in themselves.

Usually they start as a means to an end, or a set of values and principles. Of course, it could be that people don’t immediately understand them and some learning and coaching is needed. That’s a means to spread the idea/framework/manifesto.

All still fine.

But then some people think they are better in it than others and start selling trainings and certifications. At that moment the framework changes from a “means to and end” to “the end”.

At this point we could still resuscitate the framework.

That moment passes the moment frameworks of frameworks emerge, for example scaling frameworks such as SAFe, ITIL4 , LESS etc.

You know something is really dead when the manifesto or framework becomes religious. That happens when the first person declares him/herself as …-ist, for example “Agilist”.

Could be a nice article, the 3 stages of a dying framework…