Hacker News Reader

Comment by colordrops | Hacker News Reader

> Commitments and sprints become terribly destructive over time.

Could you elaborate?

You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks. This requires sacrifices like ensuring network connections remain alive, handling exceptions, optimizing queries, abstracting functions for re-use, handling all the data input scenarios, etc.

This creates a confusing code-base with lots of IF statements, copy/pasted code, data modifications from several areas of the system, etc.

You'll fix a problem with data getting into the database incorrectly and realize a couple sprints later, fixing that bug caused other bugs elsewhere.

Automated testing doesn't catch it because automated testing only handled certain scenarios.

It's a mess.

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks.

Well there's your problem. How is that inherent to scrum?

Because it's a sprint. You've got a finish line and you're racing towards it. Businesses don't function without prediction, and refactoring gets cut before roadmapped features. If feature development is a bottleneck in company growth, debt will grow, quickly.

“Sprints” are, pretty much by definition, a non-sustainable pace.

Agreed. I regularly ask "Why are we running a marathon in a thousand sprints?".

Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for "high velocity". There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.

imho a problem with the implementation of SCRUM, but not necessarily restricted to SCRUM.

In a perfect SCRUM world you could not be forced to implement this in a time not of your own estimate. A feature that is so big that it takes more than a few days to implement has to be split...but well we all know how this plays our in reality most of the times...

>You're asked to deliver a feature that would take 4 weeks to implement without tech debt in two weeks.

There is something odd with this, if you did the estimation. Shouldn't the story points/sizing/estimates preclude this?

Doesn't the team pick the items for the sprint that they think they can complete?

You can never take a 4 week story in a two week sprint. When would you ever be able to complete it?

By breaking it down into smaller stories?

My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.

I have not worked in a scrum environment in a couple of years, but when we did it those items were not included in the story. They were part of a definition of done that the team did not really talk about publicly.

Refactoring stories were also rare, it was just sort implicit in the task, unspoken as part of doing it.

I'd imagine that is why they did not get cut.

But yes, management picked feature priorities, but left the implementation up to the team. So at any given time were were working on the "most important" thing from a business perspective.

The most successful (but still crappy) solution to this that I have seen is developers undertaking guerilla tech debt work. This can be done by bundling maintenance work into an existing task where the two are actually not that related or by simply carving out bits of time between official tasks.

While it "works" it is certainly not ideal that people have to go off the reservation to ensure that the project doesn't implode in the future due to the accumulation of buggy code, performance problems and likely security vulnerabilities.

> proper testing and documentation is the first thing that management wants taken out of the story

That's not breaking down a story into smaller stories though, that's simply not doing some of the tasks necessary for a story to be complete. "Story" is not a synonym for "task"; a story is user-centric not about internals. "Write the documentation for this feature" is not a story and "write the tests for this feature" is not a story, they should be part of your definition of "done".

That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...

You're not doing Scrum then. One of the few meetings that Scrum dictates is "backlog refinement" where the dev team works with the PO to get the stories into a workable state.

Yeah, we do waterfall and scrum with the worst of both.

If you can't touch the stories, you can ask whoever does to break it down. If they don't then you shouldn't ever pick it up into your sprint. If they insist and it doesn't work out then you should call out the incident in your retrospective and hopefully get everyone to agree to do things differently in the future.

Sadly, it’s more like the dev team points out that we really cannot work with these stories then management telling us to deal with it while the BA’s suck their teeth.

Then they ask us why there isn’t any progress.

Yep. :)

https://www.brightball.com/articles/reality-driven-developme...

Reply on news.ycombinator.com