Scrum/Agile-English Dictionary.

[reddragdiva]

The free E-meter at every desk is a valuable job perk! The Kool-Aid tasted a bit funny, though.

sprint: artificial crisis

end of sprint: abandonware

Scrum Master: CV credit for my planned escape to a new company

stakeholder: someone you can't get away with externalising your costs onto, because they can hammer a wooden spike through your heart

Project Manager: a job that no longer needs to exist in the astounding new world of Scrum! (Pay no attention to the project owners, product owners, story-writing users above you in the org chart or Scrum Masters behind the curtain.)

simplified: doesn't implement the actual business requirements

lightweight: doesn't implement the actual business requirements, but does so much more elegantly than the version that works

easy: project was born circling the drain (and doesn't implement the actual business requirements)

legacy: the version that works and implements the actual business requirements, though no sane human wants to touch it

Minimum Viable Product: doesn't actually work, but claims to tick at least some of the list of business requirements. Schedule another sprint if you want additional features like "functionality."

user story: a valiant attempt to extract coherent requirements and bug reports; ends up being precise specifications for the wing feathers of the desired magical flying unicorn pony

velocity: a speed with a direction: skittering about following marketing's random hairpin turns

retrospective: blamestorm incoming!

stand-up: establishing blamestorm targets early

Inspect and Adapt: perhaps bong hits will fix my makefile

We'll put that on the backlog: lol GFY

doing Agile wrong: noticing any of the above.

I do enjoy some of the jargon. empowered: do your own fucking job. "Could you just copy down these log files from these fifteen servers for me and put them on the shared drive? Thanks." "I'm sorry, I'm afraid you're empowered to do that."

Every good idea is turned into a bad one by the relentless management quest to Taylorise clue.

HT the Monastery

Comments

[tcpip]

The basic thing that worries me about Agile is not that it's inherently wrong (it is, in fact, the right project management method in some cases), but rather there is a whole range of clueless IT managers all around the world who think that it is the answer because it is the fashion when in reality they don't even know what it is or when to use it.

[tomfosdick.com]

I entirely agree - I can bring some experience too. I've been involved in quite a few successful Agile projects. The key is in the management of the process. The target is to provide the system that the customer needs, regardless of what they think they want. One of my projects is 7 years old and still has unmet original requirements because there are always higher priority things that the customer wants us to do that weren't original requirements (and no I don't mean "fix the bugs").
A more traditional engineering process would have delivered a markedly different system, one that was not as useful to the customer. I once watched £100k of my work go in the bin because of a requirements error. Implemented properly, Agile methods stop that kind of thing from happening.

On the flip side, even with the best management, new features are always going to be a weakness and as 100% automated test coverage is a myth there is always an increased regression bug risk. This is obviously going to be felt most in ops and it's really important that a) this is understood by everyone and that b) ops have a priority line back into development so they can kick arse when people drop the ball.

[reddragdiva]

As ops, this is frequently my job. Or at least "yes I know this issue is five months old, but I've just upped it to P1 because it is actually breaking stuff, we do actually have a handle on it now and want it fixed before the business yells at ops again" ;-)

[oloryn]

In other words, Agile is one tool (among many). When you have many tools, you have to pay attention to using the proper tool for the job.

Many IT managers don't like the idea of tools - they like *solutions* - particularly solutions that can in some way be cast as 'one size fits all', that they can then mandate from on high as the solution for everything.

(The marketing departments of) tool vendors know this. Tools tend to be marketed as 'solutions', rather than as good tools, as they're aware of this managerial bias.

[reddragdiva]

But with our new Silver-Bullet Development Methodology™, it's a completely new world where none of your decades of experience apply! This changes the nature of development forever!

p.s.: we sell certifications!

(repeat for a new Silver Bullet roughly each decade)