RE: [scrumdevelopment] Re: Backlog of technical tasks?
. If the PO drives the Ferrari off the cliff, who
is to "blame"?
This is easy – the PO.
I use this analogy in all my CSM classes. The team is the engine, the ScrumMaster is the oil in the engine, the PO is the one providing fuel and setting direction (aka driving).
The Product Owner is the single wringable neck and is responsible to both the customer and the team (who is a stakeholder). If the team raises the issues of increasing technical debt and the PO does not listen, bad PO. If the team does not raise the issues, bad team.
Kane, don’t mix responsibility with accountability. Everyone (PO/Team/SM) is responsible. One person, the PO, is accountable.
On Thu, May 1, 2008 at 3:12 PM, Kane Mar <kane_sfo@...> wrote:
> This is something that I don't agree with because, when projects go bad, IThat's just not true. I like the analogy of the Team as a Ferrari and
> believe it's everyone's responsibility
the PO as a driver. If the PO drives the Ferrari off the cliff, who
is to "blame"? OK, the Team is an animate entity, with members who
can speak up, but the fact remains that the Team can make their point
about technical debt until they are blue in the face, but if the PO
purposely forbids the Team from doing what it takes to reduce the
technical debt, then there is a lot more blame to go to the PO - if
not *all* the blame.
- --- In firstname.lastname@example.org, "Jeppe N. Madsen" <jeppe@...> wrote:
> I've been skeptical about putting technical tasks on the backlog forYes, and there's really no contradiction between these
> many of the same reasons listed in this thread. I think we should
> make "the world a better place" one step at a time, by refactoring the
> code as it's touched due to new requirements.
approaches once we see the Sprint Planning Meeting
as a good faith negotiation.
Normal technical debt should be paid off through
the definition of "done" for product feature stories.
Things like this might include refactoring away
duplicate code, complex conditional logic, long
modules, nested "catch" blocks, poorly named
methods and classes, normal database schema
changes, normal upgrades to third-party
> If there really are technical debt that hindersYes, when progress on multiple fronts is impeded
> progress, this is an impediment.
by severe fundamental underlying debt issues
(often at the infrastructure level, like platform
changes, major database changes, major library
changes) it may be useful for the team to make
it visible in the product backlog as a step toward
breaking the repayment work into manageable
pieces. Anyone can add items to the Product
Of course we still expect some feature delivery