Split user stories ruthlessly and get value earlier • Hacker News Board

Re: Split user stories ruthlessly and get value earlier

#31

Post by sixdimensional » Sun, Aug 13, 2017, 4:33 PM UTC

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…

Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method.

I'd be curious what software engineering process you'd prefer then, for your own company?

Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of quality due to standardization of process and method.

Re: Split user stories ruthlessly and get value earlier

#32

Post by Infernal » Sun, Aug 13, 2017, 4:35 PM UTC

maxxxxx wrote: post #11

lotsofpulp wrote: post #10

Earlier quoted context omitted.

I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).

I think they had checklist like this: Retro design, quirky, different. I actually like the concept. But the implementation is just terrible.

I think the number one item on the checklist was "how can we build a car that /just barely/ crosses the line into 'light truck' category so has much lower fuel mileage targets per CAFE standards". On that point they did very well.

Re: Split user stories ruthlessly and get value earlier

#33

Post by johnrob » Sun, Aug 13, 2017, 4:37 PM UTC

sixdimensional wrote: post #31

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…

Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method. I'd be curious what software engineering process you'd prefer then, for your own company? Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of q…

Small batches. What can I do today, that will demonstrably put us in a better position at the start of tomorrow. Ideally should result in deployed code to production, but not always (e.g. research).

Ironically, you could argue this is agile with one day sprints - I wouldn't disagree much.

Re: Split user stories ruthlessly and get value earlier

#34

Post by [deleted] » Sun, Aug 13, 2017, 4:37 PM UTC

sixdimensional wrote: post #31

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…

Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method. I'd be curious what software engineering process you'd prefer then, for your own company? Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of q…

[deleted]

Re: Split user stories ruthlessly and get value earlier

#35

Post by [deleted] » Sun, Aug 13, 2017, 4:37 PM UTC

sixdimensional wrote: post #31

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…

Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method. I'd be curious what software engineering process you'd prefer then, for your own company? Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of q…

[deleted]

Re: Split user stories ruthlessly and get value earlier

#36

Post by losteric » Sun, Aug 13, 2017, 4:42 PM UTC

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…

Processes are templates, anyone that treats them as dogma is doing it wrong... a good process simply facilitates effective communication and planning with the lowest possible overhead.

Agile/Scrum/waterfall/etc should be used as inspiration - but the right process is custom built for each situation.

The only thing that really matters is periodically retrospecting and refining - cut the cruft, fix the flaws, and reinforce what's working.

Re: Split user stories ruthlessly and get value earlier

#37

Post by another-dave » Sun, Aug 13, 2017, 4:45 PM UTC

IshKebab wrote: post #19

bonoetmalo wrote: post #16

Grooooaaaaaaannnnn. The amount of developer hours that go into micromanaging user stories and story points is infuriating

I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number ." Blarghf. Why not just "Implement about dialog with version number.". I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.

The point of the "narrative statement" is to show what value implementing a story will bring to help bring a relative priority order to things. Otherwise people keep championing their pet features, without focusing on _what's the point_ of this feature.

"As a user, I want to be able to find the full version number of the product to make it easier to get help when raising support requests".

This is now something we can argue about — is this story bringing more or less value than, e.g. setting reminders or 2FA?

If you write the narrative statements in a banal or glib way, just for the sake of them, then of course there's no point, but that's true of most processes — e.g. JavaDocs are a good idea in principle, but you can make them equally useless: "return Boolean: true or false".

Re: Split user stories ruthlessly and get value earlier

#38

Post by tootie » Sun, Aug 13, 2017, 4:45 PM UTC

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…

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 not you need rules to keep everyone aligned.

Re: Split user stories ruthlessly and get value earlier

#39

Post by tootie » Sun, Aug 13, 2017, 4:48 PM UTC

IshKebab wrote: post #19

bonoetmalo wrote: post #16

Grooooaaaaaaannnnn. The amount of developer hours that go into micromanaging user stories and story points is infuriating

I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number ." Blarghf. Why not just "Implement about dialog with version number.". I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.

The stories aren't just for developers. If business doesn't understand the intent, they don't understand the value and can't set priority.

Re: Split user stories ruthlessly and get value earlier

#40

Post by talldan » Sun, Aug 13, 2017, 4:53 PM UTC

maxxxxx wrote: post #9

With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car. But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and…

Is agile considered a product development framework or just a software development methodology? I think that's quite a difficult question to answer. I'm sure anyone that has worked on product development finds it difficult to figure out how things like research, design and maybe even quality assurance should fit into the agile way of doing things.

Agile is so flexible that it doesn't really answer the question of how some of the non-software dev things fit in, ultimately it comes down to strong leadership, and the honesty to say when something is going wrong. At the very least, agile provides the opportunity to fix bad decisions.