Hacker News Reader

Comment by stingraycharles | Hacker News Reader

Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines).

Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.

View on HN

> Sprints are really just a form of pressure

I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.

In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.

That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.

Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.

Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release.

It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)

I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)

Funny how whenever I've done kanban, top tech debt items always are eternally pushed down to #5 or 6 in the backlog, never to see the light of day.

I have my criticisms for sure, but sprints give more discretion to the teams to carve out space for multiple types of priorities held in balance, and lock that ratio in for a period of time.

> sprints give more discretion to the teams

when they do. i was part of an 'agile' team in 2019 (6 mo contract). I wasn't there long enough to have strong views on work items or priorities, but did watch the interactions between others. It was a decently organized team inside a (fast) growing org - lots of challenges there. But overall, there was a decent balance.

Worked on another smaller team longer - 2 years. As the company grew, it got far more process heavy. The 'sprint' stuff was "as tech lead, you get 5 points to use however you want per sprint!" (yay?). that got taken over by the CTO getting involved and using those '5 points' for constant infrastructure stuff. I was reviewing code I delivered, and it was full of cut corners to continually hit deadlines. I begged on a few occasions for more 'cleanup' time. It was always denied (except for 3 days over xmas, because... literally no one else was working, so they couldn't say no).

The project transformed in to "here's our strategic goals for 2022" with every quarter mapped and filled to the brim with work. 0 time for anything but bare minimum MVP. The thinking was "well... you've been able to work at that pace before, and we added someone new, so we can increase that". In 2019, it was MVP - test the idea. Speed to market makes some sense. In 2022, millions of dollars and hundreds of lives affected each month... we need to take a bit more time to clean up existing code, retire legacy code, adopt a slower pace to focus on clarity, testability, even performance concerns etc. This seemed to fall on deaf ears.

"discretion to the teams" tends to ring hollow to me based on recent experiences, and ideally I'll work with another group in the future with a healthier balance.

I think the answer here is to point your current tickets higher. When someone asks for estimates on time, or points, you give a higher estimate so as to not leave as much tech debt behind. In theory or course, may not work in practice.

Potentially, some, yes. However, when goals have already been decided, and 'missing' those goals is a 'bad thing', there's only so much you can do. We'd gone from collaborative to 'command and control'. And... FWIW, we got a lot more done under 'collaborative', but it was mostly just 'me' on the dev side and one other person on the product side.

At some point though, many of the original assumptions about problems are understood to have been fundamentally wrong/misaligned, and need some revisiting. You need to touch old code, whether to delete it, or to have it align with new standards or new ... whatever. Touching anything that didn't relate to an explicit 'agreed on' jira ticket was seen as wrong/bad. I ended up bundling in 'fixes' of unrelated stuff when working on 'new' stuff because... it had to get done, but was ignored or rejected during any sort of planning.

I've heard it said that "to go fast, do it alone. to go far, you need a team". I can get on board with that, but you need a team in agreement and competent. I have a colleague working on a small team and... they're mostly just completely inexperience and bad, but there's no self-awareness. Taking direction from the guy who was in high school last year, while ignoring the person who's lead multiple teams and has delivered high value software for 20 years... that's a bizarre imbalance that can't be fixed with 'sprints' or process alone.

On a 6 month contract you haven't been around the code long enough to know what is tech debt and what is a good solution for a complex solution.

Though your point is correct - you rarely are given time to fix tech debt. If you switch to a long term employee, then you should intentionally slow your velocity a little to fix tech debt. By the time management catches on you will have fixed enough that an improvement is visible and so you have proven yourself, and thus will be allowed to do more of it.

Also note that a story isn't done until refactoring is done. Sure it works, but if the code is a mess your story isn't done and you don't move onto the next one. Many developers fail to force this, but as a professional this should be part of your code of conduct and thus not optional no matter what the deadline.

In any case the point is you will never be officially given those 5 points - but you can take them by force.

Agreed.

As an aside, one thing just came to mind. Even if you're bringing tech debt tickets into each sprint, there's a possibility they'll get picked up last - fine, unless they keep getting pushed back!

Part of me thinks this could be mitigated by reducing the velocity expectation. But there tends to be an overarching sprint goal relating to product work, and this often invites extra scope due to unforeseen impediments. So 'background' work like tech debt is easily pushed back.

I don't know of a better way. Perhaps it comes down to human factors such as limited focus.

There are two ways management can handle getting things done on time: commit to taking only 80% of the teams capacity, thus ensuring there is plenty of buffer; or commit to the full thing, and accept that some things won't get done. If (as most do despite Agile warnings about it being wrong) your management wants you to get done 100% of what you commit to, then as a team you need to hide 20% of your capacity from management.

Do not let formal debt and improvements compete on the same ranking.

Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.

Yep. We used to dedicate 20% of story points to tech debt, when we had quite a lot of it.

You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.

At a past job for a while we did Kanban with the sprint as a time box and it worked really well for the constraints we were working in. When we had work with deadlines, we'd flag that work as needing to be done in the sprint time box and put it on the top of the pile. Otherwise the team just kept picking up the next item, and we'd do a single review meeting at the end of the sprint to check in and see how everyone felt and what was accomplished. It was less of a retro and more of a temperature check.

It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.

If you place a lot of value on planning and deadlines, you should probably embrace that wholeheartedly, and not try to pretend to be “agile.”

Reply on news.ycombinator.com