Showing posts with label velocity. Show all posts
Showing posts with label velocity. Show all posts

Tuesday, August 21, 2012

Your mouse tastes like yesterday's pasta bar.

How'd you like to reduce your velocity?

When I was an admin assistant we received one hour of vacation for every two hours of sick time we cashed in.  The result was that every so often one of my bosses would show up, lean over my shoulder to look at my computer screen and make sure I was typing up their work or meeting minutes, and then cough so hard they put spit on my glass. As I became less enamored of my job and knew my time was limited to less than a year or two, I'd get up, go find my ultimate boss, and tell her I was going home.  It helped that I was officially half time despite working full time.  No one really argues with you much when there's spit on your computer screen.  Someone should be at home.  Either the sick person.  Or everyone else.

We recently had a developer come in sick and spread some disease.  But I'll give him credit for just being young and not knowing any better.  That doesn't help the team that ended up having developers fall like dominoes, but at least they knew it wasn't about trying to bank vacation at everyone else's expense.

Title: Your mouse tastes like yesterday's pasta bar.
Snarky: How'd you like to reduce your velocity?

Thursday, July 12, 2012

It means the release is next week and we don't want to tell the business what's left.

So fit and finish means the same velocity and attention to functionality we had last week?

This phrase is a personal annoyance of mine.  It implies "it's not much work" or "we're almost done."  It glosses over reality and fact with management speak.  What are stories and work items for if not to give a precise idea of what's left.  How can there be "fit and finish" if we're always providing a working product tailored to business unit expectations based on velocity and capacity?  The last iteration shouldn't be any different than the one before it, or the one before that, or even the first.  And unfortunately, it doesn't seem to be development hiding a bit of last minute work from the business, but a way for the business to try and stuff a lot of extra work into the last iteration that they weren't properly iterating on (and communicating) before.  I use a personal example where on the last day of development for an iteration, the number of high priority items, which had been decreasing consistently as we approached release, shot up by 66 items in the last day.  Over 1000%. There's no "testing party" and "fit and finish" language to cover that up - there was a disconnect between what the business said was important all along, and what they felt was important at the end.  Not unexpected.  But still unpleasant.

Title: It means the release is next week and we don't want to tell the business what's left.
Snarky:  So fit and finish means the same velocity and attention to functionality we had last week?

Thursday, May 24, 2012

And yet our release cycles never change.

Two in a Cube: Our backlog is growing more quickly than our velocity is increasing.
This reminds me of Wirth's Law.  Somehow even though we can never quite seem to stay ahead of the curve, things manage to keep moving forward.  Maybe there is hope after all?