Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Split user stories ruthlessly and get value earlier

mikeborozdin.com

Post reply on HN
Print view View original

61–70 of 98 posts

Re: Split user stories ruthlessly and get value earlier

#61

Post by Huggernaut »

stult wrote: post #54
joncp wrote: post #20

Earlier quoted context omitted.

Following your metaphor of the PT Cruiser: it seems like they followed a waterfall process. They came up with a list and then built a car that fulfilled that list without evaluating what they were building st every step along the way. If they'd done it agile-ly, the crappyness may have surfaced much earlier in the development of the car... Maybe early enough to have done something about it. Alas, agile doesn't really…

Agile doesn't work with cars because you can't deliver value incrementally by designing additional features. Producing a brake pad this week doesn't help if the chassis is still unfinished. Similarly having the entire car except the brake pads complete doesn't deliver any value. It's all or nothing.

Not sure I totally agree that it can't be done. I have no idea whether it's at all realistic/sensible/pragmatic to create a car via agile but taking your brake pad example it would seem very alright to have a set of stories such as:

"As a driver, I can stop the car at a reasonable pace" - ok, maybe you get some awful brake pads to begin with (or maybe if you are cheeky you just say...well, air resistance does that!)

"As a driver, when the car is travelling fast, I can stop the car extremely quickly" - ok so now we probably need some reasonable brake pads.

"As a driver, I don't need to replace the stopping mechanism all the time" - ok so maybe now we need to make sure the brake pads fitted are of a certain quality.

I think you can see where this is going. Sure the car probably needs brake pads...but assuming you didn't know much about cars (something agile is suited for), at each stage you could decide you need to do something different for the stopping mechanism. Additionally, many of the qualities of the brake pads demonstrate that things are not "all or nothing" necessarily.

Re: Split user stories ruthlessly and get value earlier

#62

Post by tootie »

I generally advocate this approach, but there is a limit. Each new story is a context switch for everyone involved. It's easy for a product manager to lose track of the holistic POV if they are tracking too many stories. The dev has to stop and start or worse yet, split very tightly coupled work among more than one dev.

Re: Split user stories ruthlessly and get value earlier

#63

Post by dasmoth »

NAHWheatCracker wrote: post #44
hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

I used to think that the words you mention are the problem causing so much bureaucracy. My thinking has changed such that I don't blame the vocabulary, instead I blame the people who abuse it. There are genuine people who use these buzzwords you mentioned because it makes it easier to discuss concepts/aspects of project management. It's faster to say "user story" than to say "an informal, natural language description…

There's some truth in this, but I don't think "good agile" is totally innocent. In particular, they always seem to be uncompromisingly team-focussed methodologies (a lot of stress on the "...and interactions"), with little scope for individual creativity and problem solving.

Re: Split user stories ruthlessly and get value earlier

#64

Post by nulagrithom »

hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

What do you propose as an alternative?

Re: Split user stories ruthlessly and get value earlier

#65

Post by tootie »

k__ wrote: post #43
tootie wrote: post #38

Earlier quoted context omitted.

Anyone who traffics in buzzwords without adding value is the problem. Scrum is fantastic when you understand the why of its process instead of just following the rules. If you schedule scrums and sprint planning, then accept ungroomed stories, change priorities, deliver without testing, then you are doing it wrong. Really disciplined and experienced teams can follow the intent without the process, but more often than…

Isn't scrum what happend to XP after managers mangled it?

XP was for developers. Scrum expands it to product management and ownership. The biggest benefit to me isn't developer productivity, it's the ease with which we can communicate progress to stakeholders.

Re: Split user stories ruthlessly and get value earlier

#66

Post by [deleted] »

acdjuiamadfn wrote: post #28
hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

I cannot "upvote" you enough.

[deleted]

Re: Split user stories ruthlessly and get value earlier

#67

Post by hollerith »

hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

I see you have "user story" in your list of hated buzzwords. If you don't mind my ignoring the rest of your comment, I'd like to focus on that single phrase. I claim it is ok.

What was going through the programmer's mind when he wrote a particular passage of code is a very useful thing to document. In my user-facing code such documentation tends to look something like "just now as part of an attempt to achieve X, I did Y, expecting to see Z, but I got U instead." Comments like those occur often enough and are valuable enough that it is good for me to have some quick way to refer to the category. Isn't "user story" just as good as any other quick way?

Re: Split user stories ruthlessly and get value earlier

#68

Post by haukilup »

hal9000xp wrote: post #24

If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…

It seems that you don't actually object to the principles behind Agile or the processes themselves - just people who abuse and force agile processes on others without understanding _why_ these processes were introduced in the first place.

I don't think the terms you listed are just buzzwords, and I don't think people who use them are always going to be bad hires. It's just terminology.

Agile development has worked well at a lot of organizations. When you hear someone use these terms, you should probably begin digging deeper into why they think the framework/processes/whatever worked for their previous team.

Re: Split user stories ruthlessly and get value earlier

#69

Post by ju-st »

djeikyb wrote: post #57
ju-st wrote: post #49

Earlier quoted context omitted.

Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.

I think scrum gets a bad name because folks get so caught up in strictly adhering to a concrete implementation of the agile philosophy that they lose track of the philosophy. Folks doing scrum often value scrum processes and tools over the individuals using them. Scrummers stick to their scrum plan rigidly instead of reflecting on and changing their process. It's fine to say such teams aren't really doing scrum. It's…

Yup, the problem is that many people just implement agile without understand why you're supposed to do the rituals. I'm deeply convinced that most things of scrum really benefit the developers. You have to be aware about this and think about it and not just implement it as it was thought.

To pick an example: the OP described how the managers enforce the completion of a story at the end of a sprint. This obviously doesn't make any sense. The philosophy of scrum is that you as developer have the (1-week long) sprints to iteratively learn how long you need for a story. So after several months the team will finish most stories as planned because they have a better understands of their own speed and more importantly how to judge stories.

The most important thing about software development is to understand the "requirements". Or in plain text: what the fuck shall I do? The customer doesn't know this either but it is your job (and that of the product owner and actual customer) to clarify this on a business level. On the concrete implementation level you have the scrum planning where you talk about a story and you try to understand it. You try to clarify what it means and how to implement it. Assigning story points is not a "work item" itself. Assigning story points is only the result of the process of clarifying what the story means. You can only judge how much time you need to implement the story when you really understand it. After a scrum planning you should exactly know how you should begin the implementation of a story. In a scrum planning session the team basically implements the story in English words.

In the first few sprints nothing will work correctly, your estimates are completely wrong and you are not sure how to handle storys. But this will improve sprint after sprint. Shorter sprints = faster learning. And this learning is the whole point, if your manager decides how long your story is and giving you deadlines you won't learn anything. Instead of learning how to evaluate and interpret a similar story in the feature you have to work on the weekend.

Re: Split user stories ruthlessly and get value earlier

#70

Post by ju-st »

doseofreality wrote: post #52
ju-st wrote: post #49

Earlier quoted context omitted.

Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.

This is the inevitable and unwinnable argument in any thread that dares to question the value of Scrum.

Sorry, I have clarified my point with an example in another post: https://news.ycombinator.com/item?id=15004260
Post reply on HN