

Implementing scrum and missing the mark - Dervall
http://binarysculpting.com/2012/04/26/implementing-scrum-and-missing-the-mark/

======
hansef
I've experienced this in my own 7-year practice as CTO of an agile rails
consulting shop, growing from 2 to 20 people while working with dozens of
clients ranging from government agencies to VC-funded startups and self-funded
single founders. Some of these projects have been extremely successful, while
others have resulted in high-quality software which never saw the light of day
or met real user needs. I would estimate the ratio of success to failure has
been 1:5. It's deeply disheartening for me, and for the outstanding
development teams I've built, to see work we have put months or years of
effort into collapse due to lack of focus and clear, cohesive product
management and vision.

The successful clients all had someone inhouse they could dedicate full-time
to defining a well-structured backlog, grooming stories, balancing feedback
from stakeholders, acceptance testing work, communicating with design and
development, and generally acting as the unary executive voice of the product.

SomeONE. And the problem is that the role here calls for both executive,
rather than committee, function and requires a broad generalist skillset. A
good product owner needs to think analytically, write clearly, communicate
firmly and negotiate competing needs and priorities. They need to be
comfortable discussing technical details, even if they are not themselves
technical. They need taste and understanding for user experience, even if they
are not themselves a designer. They need delegation skills and a keen
editorial instinct.

There are many more people with money to build software than with someone in-
house with a matching set of aptitudes and is available to own a project.

Instead we get a group of department heads, with overfull schedules and
competing needs. We get people who come to us with ideas for apps they are
sure will make them wealthy. We create beautiful software for them, they
"launch" in the App Store, and we never hear from them again. We get VPs of
Product who spend more time in endless fundraising meetings than talking to
their customers and development team.

The real surprise is that the success ratio has been this high.

~~~
hkarthik
I've experienced the same problem, and I attribute it to the culture of "no
accountability" in so many organizations, both large and small.

When I first learned scrum, the product owner was described to me as the
"single, ringable, neck."

The problem is that no one wants to put their neck out there. Decisions can't
be made without committee, and individuals are literally afraid to own
anything for fear of being held accountable if things go wrong.

~~~
heretohelp
>"single, ringable, neck."

You don't "ring" a neck, you _wring_ a neck.

Like one wrings a towel dry.

Take a towel into your hands and wring it dry.

Now imagine a clasping your hands around a neck and doing the same thing.

I've just used a mnemonic trick to prevent you from ever making this mistake
again.

~~~
hkarthik
LOL thanks for the correction and the useful mnemonic trick!

I was fairly certain 'ringable' was not a word so I fudged the quote.
Unfortunately, even 'wringable' isn't a word. I guess it has to be 'wring-
able', which just doesn't look right.

------
ls6
While I appreciate the insight I cannot fully agree with your conlusions. I've
been a PO for the last 16 months (not my first scrum project) in a research
project where it is simply impossible to have a long backlog. I bearly manage
to keep one iteration ahead of the team. But it works. I think it does because
I'm the person actively driving the development, I know the direction we
should go and I do want the results

And that latter part is where, in my opinion, lies the difference. Not in the
artifact but in the person.

~~~
hansef
In my opinion, anything on a product backlog which exceeds a 2-3 iteration
horizon should be spun into a product roadmap document instead - as a general
rule of thumb, if you don't have enough information about a story to sit down
and write a clear set of acceptance criteria for it right now, it probably
doesn't belong in your product backlog.

2-3 iterations is doable - trying to maintain a backlog of stories 2-3
_releases_ ahead usually results in a big sloppy mess of a backlog.

Unfortunately, I've worked with many clients where thinking about priorities
in the future far enough to have 2-3 _days_ worth of stories in place beyond
the current iteration is a struggle. This is where things usually go really
off the tracks, because you build the thing it's easiest to describe right now
to keep everyone working, or run from externally-directed fire to fire,
instead of setting a cadence of development which represents the business'
true near-term priority mix.

~~~
ls6
On big backlog: you have surprised me here. My backlog has all kinds of stuff
in it that I'm not even sure we will ever build (as I said before it is a
research project). As long these vague stories are more than 2 iterations away
they don't distract the team but, at the same time, show them roughly what I
am considering in the long term. I personally find it very important that the
team knows the big picture and where and why we are heading so they can take
more informed decisions. As a bonus once in a while I get unexpected insights
from the team. They are smart guys, after all :)

Regarding the client involvement, what you describe is, in my eyes, not your
problem but your clients' - they clearly have no idea what they want to have.
If the project is important for the client I sometimes add one more (senior)
person to the project from our side and charge him with the task of helping
the client to figure out their needs. This new person takes over the PO role
on the team side but spends most of his time with the client asking questions,
guiding him etc.

------
rpwilcox
I think the daily standup and retrospective meetings are easy to implement
because they can be seen as status meetings for the chicken's benefit. They
aren't, really, but it does seem easy to turn these from "developers
appraising other developers about their problems and status" to "give me, the
chicken, a list of the ticket numbers you plan on working on today and their
status"

Retrospectives of course are seen as meetings (and managers love meetings)
where the team works internally to make itself better. Woh , what a great
idea! Except this also misses the point - sometimes the retrospective
generates feedback for the organization/environment the team works in. "Sales
people should file tickets, instead of cornering us and making us listen/do
their thing". Things like this may be ignored or shoved in a desk drawer
because "it's just developers whining"

------
stcredzero
I think the only way to develop good teams is to develop a number of teams,
then see what they can do. There's no currently popular methodology that will
guarantee developing good ones. Y-Combinator seems to come close, but really,
they are trying to encourage favorable preconditions, then letting groups
succeed.

~~~
Dervall
In all honesty, the best factor to succeed is to have good people _in_ the
team. If you don't have that, you are never really going to get past that
factor.

Provided you have that, I believe the greatest success factors are outside of
the scum team and that the effort to improve working conditions should be
concentrated there.

Though I'd love the idea of a methodology race, where the fittest win. Wonder
if there ever is an organization open minded enough to try this...

~~~
praptak
> Though I'd love the idea of a methodology race, where the fittest win.
> Wonder if there ever is an organization open minded enough to try this...

Every organization does that, to a degree, unknowingly. I know a (secret,
undisclosed) organization where we (er, they!) do Scrum but if you analyzed
what the teams actually do you probably wouldn't guess they follow anything
resembling a single recipe :)

Curiously it seems to support the thesis of the article. I believe that all of
the teams have some sort of a backlog and focus on making it good. The
difference is that while the author strikes "prioritized" we, the devs, are
more focused on "well specified".

