Your reading of the situation is spot on. There are a number of
complex people issues at play.
I've been here before, so I'll be applying my usual charms in an
attempt to influence the team in a positive direction.
Thanks for the advice.
--- In firstname.lastname@example.org
, "Petri Heiramo"
> Hi Paul,
> Sounds to me the problem isn't in the PO or in the technical stories.
> I mean, sure, those areas may need improvement, but they are not the
> core problem. I think you addressed the core problem yourself: not
> releasing things.
> If you don't release, you don't do workable iterative and incremental
> software development. You don't get feedback, you don't get customer
> ownership, you don't get tested working milestones. I don't know if
> the team releases "potentially shippable increments of functionality",
> but if they don't you don't have incremental development, either. It's
> just waterfall with a different management framework, with pretty much
> all the problems of waterfall development.
> So the first thing I would do is check how the team's operation fits
> in with the goals of iterative and incremental development & the
> values and principles of Agile development. Then coach the team to
> change they work to match them. Only _then_ I think it makes sense to
> go to coach the PO (as you stated yourself).
> The typical problem with technical stories is that they tend to be
> horizontal. That is, they don't address end user functionality
> directly. It is difficult to do effective iterative and incremental
> development when you can only deliver partial functionality at a time.
> So if you see that kind of problems in the product backlog, it would
> make sense to rework those issues with the team.
> Now, if the lead architect is used to running the show, you might have
> problems turning the ship about. He is the person you need to
> convince. He is either your best friend or your strongest opponent.
> The PO seems detached and sounds unlikely to impose requirements on
> the project. He already doesn't demand milestones, so why would he
> oppose improvements to his position? [I don't mean that the milestones
> would be good to require, but it just shows he doesn't require
> specific issues even if he thinks they would be good in his opinion.]
> Wishing you good luck,
> Petri Heiramo
> Senior Process Improvement Manager, CSP
> Digia Plc., Finland
> > Hi All,
> > I have recently started working as a coach with a team that has
> > primarily been using Scrum. They have an established backlog which
> > includes a number of technical features. I believe that this is
> > ligitimate in Scrum. The problem we are having is getting firm
> > ownership of the backlog. From the customers point of view, the
> > backlog is a "to do list" for the development team. If I say that the
> > team have been going for 18 months and is planning on delivering it's
> > first release in the next two months then you'll get the picture :)
> > So the customer doesn't feel that he owns the backlog. He is just
> > waiting for his realse, waterfall style. This feeling is reinforced by
> > technical features in the backlog that are created by the lead
> > architect, and assigned priority based on his advice, and which
> > clearly do not belong to the customer.
> > How does this work in a Scrum team.? My experience is XP.
> > Regards,
> > Paul.