Comment by irahul | Hacker News Reader

Comment by irahul | Hacker News Reader

Parent Full thread

> 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.

Reply on news.ycombinator.com