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.
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)
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.
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.
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.
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.
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.
Either do 2 of this, 1 of that, or have separated time slots, or whatever. But separate them.
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.
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.
Also all the sprint planning and retrospective took basically 30% of our time.
"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level".
All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc.
People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this.
Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate.
So how do you expect that to happen in a situation with money involved, and competition between people?
Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.
Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes.
Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns.
What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables.
It’s what very good teams do, though they do it without the need for formality.
My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.
My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
The Retro yesterday was 30. So that's less than 1.25% of my time spent.
Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.
Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.
If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.
Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
It's just a 5 letter word, it's not that difficult.
Beware the careless pedant!
I rate my comment a perfect 7/5.
Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.
Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.
Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.
Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.
If you overestimate everything then you end up idle at end of sprint & picking backlog items to bring in, so then product wants to put more points/stories into next sprint.
The system is seemingly designed to produce this outcome.
The system is to teach everyone how to lie and juke the system. It feels awful working in most sprint-based environments. Because even when you're highly productive it still feels like you failed in multiple places, and it always feels like you're being dishonest and have no real choice about it.
So instead of "ticket: make pasta for dinner" it was like "ticket 1: purchase prego & pasta from instacart" , "ticket 2: boil water & get out the jar opener", "ticket 3: cook the pasta and sauce", "ticket 4: place the meal and serve".
Zero chance all 4 finished in the sprint, in fact they were rarely even all planned for same sprint.
It became impossible to express to users what they were getting at the end of each sprint. "OK, so you've.. purchased ingredients, when do I get to eat?"
This happened with multiple product managers, agile coaches and tech leads so it wasn't just a single person forcing stupidity on the process..
*most of the times we use a lot less
So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.
Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.
This is a weird take.
I’m making a pithy statement about the difference hackers and developers