found drama

get oblique

Tag Archives: Scrum

“…they will go off and work in the integrated development environments…”

by !undefined

What Is Code? If You Don’t Know, You Need to Read This:

They will do their standups. And after the standups, they will go off and work in the integrated development environments and write their server-side JavaScript and their client-side JavaScript. Then they will run some tests and check their code into the source code repository, and the continuous integration server will perform tests and checks, and if all goes well, it will deploy the code—perhaps even in August, in some cloud or another. They insist that they’ll do this every day, continuous releases.

Read every word. Every one of those 38,000 goddamn words. Even if it takes you 6000 hours.

A Framework for Modern User Stories

by !undefined

A framework for modern User Stories:

My inner Scrum Master got a little bit excited about this.

What I liked about it is the attention it gives to the language of a User Story — right down to the specific words that are used to make the statements. Granted, the other thing that I liked about this piece was how it both embraces the traditional User Story format, while updating/expanding it a bit to allow for more information to get “built in”.

You could argue that what’s added should have been encompassed by Acceptance Criteria anyway, but using BDD statements here seems more constructive. (…because they easily convert into acceptance tests.)

re: “Why Scrum Should Basically Just Die In A Fire”

by !undefined

Why Scrum Should Basically Just Die In A Fire:

By Giles Bowkett.

I was resisting the urge to post anything beyond my remarks on Prismatic, but this made enough of the rounds among my circle that I felt compelled to chime in with a couple of follow-up thoughts.

First: we know that Bowkett is smart; we also know that has a tendency toward writing in a deliberately inflammatory or provocative fashion. Given the latter point, I would just chalk this post up to being another “conversation starter” (at best) or else (at worst) the tech-worker equivalent of clickbait.

Unfortunately, what we have here is “Agile” (in general) and Scrum (in particular) playing scapegoat for the bad behavior and cascading ill effects of what is usually just a handful of unfortunately influential but highly poisonous people within a given organization. Scrum, much like democracy, is just a system that can be used, misused, abused, well- or poorly understood, applied genuinely or cynically, etc.

That is a long-winded way of saying that, to the extent that Bowkett is saying that Scrum is flawed… Well, Scrum has problems that make it corruptible. And in that respect, he’s right.

But there’s something that seems a bit self-aggrandizing and disingenuous in his post. The gist: he has an apparently never-ending parade of examples of how Scrum is broken, and how every organization screws it up, and how some poisonous person (usually a manager) is responsible for screwing it up for everyone. But then he has this anecdote about how he got some poisonous CTO fired.

Wow. Now imagine if that situation had played out for all those other poisonous directors, project managers, etc. that he cited. And I pause to ask: why didn’t that happen? Lack of influence? Lack of courage? Inability to recruit allies? Simple lack of effort? It’s a mystery to me because clearly you don’t take on a CTO without those elements at play.

To blame Scrum rings hollow to me. Every one of the scenarios he describes just sounds like someone poisoning the well and the people around him (or her) failing to deal with it for one reason or another.

Which is not to suggest that Scrum is going to save those organizations. Some places are too dysfunctional to survive. But blaming Scrum is like blaming the building or your desk. Move down the block and switch to a standing desk if you want, but you’re still the same people with the same dynamic. Scrum might help your team change its frame of reference; Scrum practices might promote better transparency between you and the rest of your business; but chances are you’re just going to spend the first couple of iteration learning how broken things are and if the business isn’t prepared to deal with that then guess what? Scrum wasn’t going to help you anyway.

His post has plenty of good points. But “Scrum should basically just die in a fire”? Sorry; you’re optimizing the wrong problem.

(And then there’s that wink-wink-nudge-nudge suggestion about how engineers are somehow the superior breed and let’s not go into that tired notion.)

Linkdump for September 13th

by Rob Friesel

jQuery Fundamentals :: A guide to the basics of jQuery Looks like the crew at Bocoup gave "jQuery Fundamentals" a nice, solid refresh. If you ask me, this is one of the best (if not the best) guides to writing efficient, scalable jQuery-based JavaScript. Recommended. (tagged: JavaScript jQuery ) Bash One-Liners Explained, Part III: All about […]

Agile for the Introvert

by Rob Friesel

A couple weeks ago, I finished reading Shore and Warden’s The Art of Agile Development as part of a (half-hearted? abandoned?) book club/reading group. Our goal was to get familiar with Agile’s core tenets and terms, ^^If you’ve never heard of Agile software development before, the Wikipedia article is actually pretty good. (Link.)^^^ to become […]