Dan,
I agree with most of what you say, but as a dev who has worked on a lot of teams, Iâd like to expand a bit on the product owner defining what value is to the company.
Most product owners Iâve worked with operate from a short-term perspective; they are concerned with what features are coming out in the next 3 months or so. From that perspective, it is almost always the right decision to postpone improvement/code quality/developer training activities, because it reduces what you can deliver in that timeframe. So if you have that product owner defining value, you will underinvest in non-feature items, and over time your codebase will deteriorate, you will start generating more bugs, and you will slow down. And developers are very used to working in this sort of environment, and they are good at pushing short-term value out quickly while letting things slide, even if you have a decent definition of âdone doneâ.
Iâve seen a number of different ways of trying to deal with this, and the only one that worked well was to use a budget-based approach, and to get a higher-level agreement on how much to invest in non-feature activities (as a reference, I asked at Agile Open Northwest a few weeks back and the answers I got were in the 30-50% range). And then you trust the team to spend that budget wisely. My experience is that if you have devs who have spent a lot of time in short-term-value-driven environment, your problems are not around overspending the budget, but underspending.
Eric
From: ***@yahoogroups.com [mailto:***@yahoogroups.com]
Sent: Thursday, February 23, 2017 5:52 PM
To: ***@yahoogroups.com
Subject: Re: [SCRUMDEVELOPMENT] PO at retro
Having lack of trust between the PO and the team is a serious organizational dysfunction, that, in traditionally structured organizations (i.e., non-Teal organizations), should be addressed by Higher Powers. Mediation by a shared or mutually trusted manager, or maybe an enterprise-level coach, could be called for.
Solving such problems from below, in a hierarchical organization, requires extraordinary diplomatic skill usually beyond the capabilities of team members. Not that it can't be done, but a great employee could sacrifice their career if they don't have the wiles, power or credibility to negotiate this dangerous jungle. Sometimes the product itself gets sacrificed. Anyway, the outcome can be bad if the team just tries to solve these problems on their own. Or they can go into avoidance behavior, making self-organization decisions behind the PO's back in their protected Retrospective ... which leads to this next dysfunction:
I've often argued it's unreasonable to omit the Product Owner from a Retrospective, simply because Value is an essential metric, and without the Product Owner any experiments or outcomes created by the team in a retrospective are likely to perversely emphasize the other metrics, such as code quality or team happiness, sacrificing the thing that ultimately pays them and produces societal good: value.
No easy answers. My sympathies!
Dan R. Greening â http://dan.greening.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdan.greening.org&data=02%7C01%7CEric.Gunnerson%40microsoft.com%7Cfb699284099345eff8c208d45c57fd6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636234980363992861&sdata=5CtrggpPu6ru1kgoWUwh0v%2BXo7%2FgMo8QES9QithMHsI%3D&reserved=0> http://linkedin.com/in/greening<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flinkedin.com%2Fin%2Fgreening&data=02%7C01%7CEric.Gunnerson%40microsoft.com%7Cfb699284099345eff8c208d45c57fd6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636234980363992861&sdata=rjQ1we5X0UhaVSN6TT2N8lxFMBeT%2FlHbarldkdodofc%3D&reserved=0>
On Thu, Feb 23, 2017 at 3:57 PM, Silvana Wasitova ***@yahoo.com<mailto:***@yahoo.com> [SCRUMDEVELOPMENT] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:
[Attachment(s) from Silvana Wasitova included below]
Hi Jean,
re. Scrum Guide: the term "Scrum Team" is inclusive of PO, so the Scrum Guide is quite explicit about this. In fact, some improvements may need to be owned & done by the PO, so best to have that conversation with the relevant persons, e.g. re-define DoD, or clarify acceptance criteria.
Highly performant teams I worked with have a smooth and trusting relationship with the PO, and include the PO in the Retro. The only times I've seen PO be explicitly excluded is when the PO-Dev Team relationship is strained; even then the aim is to look for ways to improve their relationship over time, and be inclusive in the (near?) future.
Silvana Wasitova
________________________________
From: "'Jean Richardson' ***@azuregate.net<mailto:***@azuregate.net> [SCRUMDEVELOPMENT]" <***@yahoogroups.com<mailto:***@yahoogroups.com>>
To: ***@yahoogroups.com<mailto:***@yahoogroups.com>
Sent: Friday, February 24, 2017 12:13 AM
Subject: [SCRUMDEVELOPMENT] PO at retro
Iâm having the âshould the Product Owner be at the retrospectiveâ conversation again. While, years ago, the Product Owner was optional in this meeting, a fair amount of learning has happened since then and a range of resources has come out advocating that the PO be presentânot optional. The current edition of the Scrum Guide doesnât help much here by referring only to the âScrum Teamâ in the section on the retro, but, then again, maybe thatâs intentional, and the Ken and Jeff now believe, based on feedback and experiments, that the PO should be present at the retro as a matter of course.
In a situation where the relationship is not good between the PO and the Development Team of the PO and the SM, Iâm wondering about the quality of a retro where the PO is not optional, but a required attendee. The guidance I typically give is that the purpose of the review is to inspect the increment and the purpose of the retro is for the team to inspect their work processes. The most intimates changes are often within the team, and those conversations require privacy and confidentiality to those present unless those present determine otherwise. Therefore, I still am reasoning that the PO is optional and included with the agreement of the Development Team.
Thoughts? References?
--- Jean
Error! Filename not specified.
Jean Richardson
Azure Gate Consulting
~ Repatterning the Human Experience of Work
AzureGate.net
(503) 788-8998
***@AzureGate.net