Live data from Hacker News

Split user stories ruthlessly and get value earlier

mikeborozdin.com

51–60 of 98 posts

Re: Split user stories ruthlessly and get value earlier

#51
> You read articles that say it should be possible to complete a user story within a single sprint, ideally within a few days. That’s entirely accurate.

I'm surprised by that, as I tend to break down stories even smaller, to the point where they can be completed in a day or two. Anything that takes longer I consider risky and potentially a rogue story that could end up eating a lot of time.

Smaller stories are easier to manage, easier to refactor, it's much easier to review the resulting code and they usually have less complexity. I think it's sometimes easier to clear blockers with smaller stories as well.

Downsides are that it can be harder to get an overall view on the progress being made during a sprint, and sometimes tasks can have more dependencies or it can be harder to work on things in parallel. It also takes more time to prioritise the backlog.

Re: Split user stories ruthlessly and get value earlier

#52
post #49
post #46

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I t…

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.

Re: Split user stories ruthlessly and get value earlier

#53
post #50

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…

You haven't seen cargo cult until you've worked in an organisation with a pmo, and tranditional project management. I had to literally write a 5 page business case for relatively small features that takes more than 5 days. You then had to get it approved by the pmo board. These people have no product management skills either. Once it's a approved I have to write a full plan and schedule. Companies like this exist. Th…

The problem is that the companies that "went agile" just added some cargo cult practices they learned by some Agile consultant /in addition/ to the old practices you describe.

You know, I am sure many of those Agile consultants that big companies hire don't even know what the Agile Manifesto is.

Agile is not agile.

Re: Split user stories ruthlessly and get value earlier

#54
post #20
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…

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.

Re: Split user stories ruthlessly and get value earlier

#55
post #46

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I t…

> Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing)

If the engineers are speaking up and are actively ignored, then the business's feedback loop is broken. The things in the agile manifesto need buy in beyond the people writing code.

> scrum master end up make it happen as his job is to make sure "sprint commitments" are met

The whole idea of using the word "agile" is to allow commitments to be re-evaluated. Respond to change, don't rigidly follow a plan.

If someone is mandating a rigidly adhered to practice of scrum, and doesn't allow teams to adapt that process to the individuals and interactions at hand, it's not agile.

Re: Split user stories ruthlessly and get value earlier

#56

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 think Dave Thomas[0] made some great points recently [1] about what Agile (as a noun) has become and I think it addresses some of your complaints. Note this isn't just a repeat of the agile manifesto, it is him discussing why he hates what Agile has come to mean to a lot of people and it sounds like his grump-level closely matches yours.

The jist I get from it is that agile has become an Enantiodromia[2] and has in some ways simply replaced the problems it was there to fix. That doesn't mean it has to be that way, but thats what happens when people take something and create a religion around it.

In my company we call our process "agile", but what that really means to us is to do the minimum amount of analysis we can to develop the features that the customer actually wants, and when they realize what they thought that they wanted was not really what they wanted, we can change it without wasting massive amounts of time. If we find that our process is causing problems for the devs, we tweak it. When we find we're not doing enough analysis in some situations, we try to improve those situations. No buzz words really, just what is best for us and what is best for the customers.

[0] https://en.wikipedia.org/wiki/Dave_Thomas_(programmer)

[1] https://www.youtube.com/watch?v=a-BOSpxYJ9M

[2] https://en.wikipedia.org/wiki/Enantiodromia

Re: Split user stories ruthlessly and get value earlier

#57
post #49
post #46

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I t…

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 true, right?

I wish that instead of promoting scrum as a one-size-fits-all agile process, scrum was taught as a place to start. That if in a couple months, a team was still doing scrum exactly as taught, they were probably failing to respond to the team needs, and also the business.

Re: Split user stories ruthlessly and get value earlier

#58
post #3

This is all correct, and following this advice will improve your project planning. BUT it skirts the problem that Agile makes people think they can plan a project without knowing what's a functional spec, what's an implementation plan, and what of those things is implied by a user's desires. You can't arrive at a really good plan just writing more-concise stories that don't span too many hidden requirements. It helps…

The hard part for agile projects is that you only loosely know what is the desired end result.

Specs should and will change.

Re: Split user stories ruthlessly and get value earlier

#59
post #49
post #46

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I t…

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.

You may be right in this case, but is there any discipline more rife with no-true-Scotsman rejoinders in its defense?

Re: Split user stories ruthlessly and get value earlier

#60
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…

It's akin to technical debt, maybe call it Agile Feature Debt.

You implement a feature, it's done, all obvious bugs are fixed. But now that you have finished it you've gained additional knowledge from actually using it. And you realize the way it was designed or implemented isn't optimal, in fact sometimes you realize the way it works is dead wrong, and makes the product less usable.

Too late. It matches the spec. It's been checked off. Time to move on to the next imperfectly designed feature and ignore what happens when it actually works.

In my case our product was designed with a UI that was overly complex, with far too many taps and views to navigate through to accomplish a specific task. And apparently the implementors were either incompetent or totally under the gun to make tight deadlines. Because it's performance is terrible, making the long trip through all those views slow and twice as onerous.

But it matched the spec, exactly.

Post reply on HN