Hacker News Reader

Comment by MostAwesomeDude | Hacker News Reader

This just makes me feel like scrum isn't worthwhile. Here's how my work flow goes, as a developer: There's an issue tracker. A handful of issues are assigned to me. I know, by memory, which issue's important, because it's always the one people are yelling about the most. I write the code for the issue, test, commit, get feedback, close the issue. Done.

I could not remember all of this terminology. Stories? Sprints? Clearly this is something above and beyond what I ever do. How do people do it? Does it really deliver on its promises?

View on HN

Author here...

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.

Cool story! This is interesting.

In this case it seems to be a tool forthe developers to manage the expectations of the 'other' non-development side of the business.

It sounds like you're in a 'bugfix' position, and we found it hard to integrate that into Scrum, so I'm not surprised it's confusing for you. In the end, we ended up just saying that bugfixes were more important and slicing off some time for how much we expected, and using the rest of the time for Scrum.

Once you get into Scrum, it isn't hard to remember the terms. A 'story' is just a feature to implement. It's called that because it's supposed to be seen from the eye of the customer, rather than the developer.

A Sprint is a timeframe for completing a bunch of stories. Usually 2 weeks, but some find shorter sprints are better, and others need longer ones.

As for the question: Yes, it was WAY better than waterfall for us. It forced everyone to get organized. Management could no longer be ignorant about what they were doing to the developers and testers on a daily basis. 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.

As a bonus, though, they gained the ability to estimate when things would be implemented, and changes to the system were rolled out every couple weeks, instead of going months between releases, and having a ton of bugs when it finally did launch.

> It sounds like you're in a 'bugfix' position,

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.

Sounds like you are violently in agreement on substance and quibbling over the wrapping.

Your argument basically breaks down to: I do all that stuff but use none of your fancy words.

That's great, spread your work methods around, many others are not as fortunate as you.

If you've found a system that delivers a great product on time, then keep going. But formalize it, and get complete buy in from those running the show. We are talking about a repeatable and trackable process. With a well defined system, you simultaneously get visibility and accountability (for both the developers and product owner). Compare that to a software framework, where people have found enough commonality and repeatability to simplify and streamline how things get done. Why put in the effort required to learn a framework? It cuts down on time to market, cuts down on your lines of code (seems to be a debate about LOC benefits), and gives the team a single, well understood frame of reference.

Having a process that is transferable between teams and companies makes the lives of everyone better, and gets us to past a lot of the overhead that leads to unfulfilled goals and unrealistic deadlines. What if your team grows to 4 people, and they all have their own idea of how to get stuff done? Without some formality, it becomes the wild west. What if you decide to leave, will you leave chaos in your wake? What if management keeps bugging you about getting stuff done sooner? If there is no well defined process, then management may be left believing the software team just isn't 'professional' enough to get things done. With a well defined and understood process, everything can be tracked and people can be made accountable for their choices. We aren't talking about a witch hunt, it will allow the company as a whole to grow and get better at defining what can be accomplished in what timeframe. If everyone agrees to abide by the process, but continually subvert it (1 + 2 = 4), then you can either suffer now (work 50+ hours a week), suffer later (build up of technical debt), or find somewhere to work values building really great software in a coherent manner.

So what is Scrum? It's a process, as are Waterfall, RUP, and XP. Those of us that willingly practice believe it's a great way to achieve maximum visibility and minimize scope creep, all while reducing artifacts and overhead. It allows us to deliver value early and often. It gives developers the tools and justification to point and say "It can't be done given our constraints". Scrum is great for team ownership, and encourages us to get early feedback on features.

Regardless of how you decide to get stuff done, make sure you have 100% buy-in from the people cutting the checks. This whole topic reminds of the discussion on designer pricing (http://news.ycombinator.com/item?id=3042803). We assume non-technical team members (our customers in many cases) implicitly understand what it takes to get a product shipped. We must do our best to bridge the gap between expectation and reality.

I am in what might be accurately called a "student" position. I work not more than 4h/day, vary wildly in capabilities, and occasionally need training on the spot.

We don't have customers. We have the sysadmins, who want features, and ourselves, who want our names to be associated with quality software. Maybe it helps that we're an open-source-only shop.

Stories seem like they might not work well with what we do. For example, a bug I was given in January was "implement WebSockets in this proxy so that we can have WebSockets in the backend." Estimated time: 2 months. It's now September and we are just now considering the relevant code battle-ready and getting it out the door. Turns out that the bug didn't really address any of the design decisions, so those have all been slowly reevaluated over the spring, and I ended up rewriting an entire library in July.

This sounds interesting, though. Thanks for the story.

Scrum is more useful when there are a bunch of people at work producing new functionality, and therefore a need to talk to each other on a regular basis, produce code that doesn't walk all over each other, and get the functionality (or "stories") in that the users want.

Here here. I have worked in places where they had a bog standard waterfall development process but used agile buzz-words like 'story'. The result? Can you imagine a cross between a giraffe and an car sized amoeba? Yikes.

Reply on news.ycombinator.com