Agile Scrum: Delivering Broken Software Since 1991

Agile Scrum: Delivering Broken Software Since 1991
writemoretests.com

I once started a contract at a company where I was working with a permie on this hugely popular site running off the God-awful blogging software. Everything was a fire that had to be put out RIGHT NOW. And there were two of us.

Coworker had earned himself a reputation for being unhelpful and unproductive. This was partly because he had sociopathically bad communication skills and hated people, but he actually worked hard, and productively. But everyone thought he was lazy and didn't get shit done.

Essentially his workflow was: work on a task. Someone comes and says "DROP EVERYTHING, YOU NEED TO ADD A WIDGET TO THE BLOG NOW". So he would start on that, and 3 hours later, someone would come to him and say DROP EVERYTHING. And three weeks later, he'd struggle to explain why he hadn't done much of it.

So we (well, I) split the work in to Stories. We estimated them, and stuck them up on the wall behind us. We found someone who was meant to be the Product Owner. Whenever anyone came to ask us anything, I'd intercept them from talking to the coworker, ask them for details on the task, estimate it, and put all this on a card. I'd then call over the Product Owner, and with the Requestor, we'd put it on the Story Board.

Suddenly items weren't /that/ important any more. With the opportunity cost suddenly marked out, many things found themselves inserted far below the current task being worked on. We'd burn down time against each task. We could tell you where we'd spent our time, and also, we could tell you what we'd achieved recently.

Essentially then, with a very small amount of overhead (like learning these terms ;-)) we suddenly had a system for prioritization and accountability. I did very little programming in the six weeks I was there - the productivity gains we saw - both real and perceived - made it look like there were 5 of me working fulltime.

You might work differently, but that's not bugfix mode. Everything is an issue in an issue tracker is a development model followed by many projects. I don't think OP is in bugfix mode.

> Once you get into Scrum, it isn't hard to remember the terms.

So not very different from not having terms at all? Which is what OP is following.

> A 'story' is just a feature to implement.

And since features/tasks it interchangeable, I would rather not introduce another word.

> Yes, it was WAY better than waterfall for us.

Of course, but there are methodologies other than scrum and waterfall - like the one OP mentions. I don't see how scrum terminology improves over the model OP is talking about:

1. Having a list of tasks to work on.

2. Fuzzily committing on the tasks which will be done in a given cycle(5 days, 10 days...)

3. Repeating.

> Instead, they were forced to actually put things on a timeline and decide what was more important, instead of just getting upset when everything didn't magically happen.

How is scrum doing anything different? I have a list of tasks, I can only commit to a certain ones which I am going to deliver this week, management can choose which ones. Isn't that the same with having a list of issues on an issue tracker?

> they gained the ability to estimate when things would be implemented

Your team must be super efficient. I have been doing this committing for the week for last 4 years, and I can recall only 2 or 3 weeks where I haven't lapsed. Whatever I tell you is my best guestimate, nothing more.

> instead of going months between releases, and having a ton of bugs when it finally did launch.

You can release early without having all this extra terminology kludge.

In addition to business stories that need to be meant there are at least two other areas whose stories are as important: development and testing. Maybe ops too, depending on your structure.

With a product owner that doesn't listen to any area beyond business, of course stories from those other two departments are discardable crap. There needs to be conversation from the departments involved. Sure, if priorities change in mid-sprint that's one thing, but there are other voices that need to be heard beyond business, when planning the story selection.

Likewise, sole product owners might think, "Oh, if we have these programmers work 16 hour days, instead of 8 hour days, we can get twice as much work done, and make the deadline!". Again, other voices (voices of reason) need to be heard in this situation too.