Ask HN: What bothers you most about Scrum and how could it be fixed?
Most of struggle with Scrum (or what is called "Scrum") in practice. What bothers you and how could it be fixed?
Other problem is that doing any kind of deep work in a two week sprints is highly risky. You don't want to get to the end of the sprint with anything 90% done, because it doesn't matter, you're a failure. And when you have other things to do beyond crunching tickets, anything that would take more than a couple of uninterrupted days to be done become highly risky, because the deadline is there next week looking at you.
It's crazy that the term "sprint" stuck as a way to describe a development cycle. The last thing I want to do after a sprint is another sprint.
Good luck!
My solution is to ignore the deadline and do what's right and explain why, as I go. This will only work with great product folks, not mediocre ones.
Candidly what every org is missing: accounting. IN a very literal sense. How much time did we spend on a feature, what was the cost. How much does it cost to run the feature? How much do people use the feature? Are we gaining or loosing clients because of it? Stuff someone from accounting into every dev team and make them live and die by the numbers.
A lot of features for resumes will die quick deaths.
I miss the 90s when we did XP.
Another complaint I have about Scrum is its structure assumes you have a good idea of what you're trying to do. Agile was supposed to reduce the cost of design changes.
Also... is there anyone who uses Scrum who doesn't use Jira? At this point Scrum is essentially the same as saying "Our organization uses Jira. No one in my organization knows how to configure it because we don't want to pay to send the guy who manages it part time to training. And when we paid for the consultant, they asked all sorts of questions like 'how are your projects laid out?' and we said 'uh... we hired you to tell us how we should do that' and they said 'you need to know how your projects are laid out' and we said 'heck, batman, we don't even know what the hell we're really building because we're waaay early in the requirements gathering and design' and they said 'how cute, call me when you know what you're doing' and we said 'yeah... i think we can randomly click buttons on the Jira interface without your help' and our VP said 'we need to monetize our synergy by leveraging our learnings and develop asks for cross departmental interfaces' and i said 'absolutely, Bob, I'll just be over here writing a distributed map reduce function in Erlang' and my management chain said 'CI/CD is hard, let's just do GitFlow and hire interns to randomly type YAML files we upload to AWS' and at this time I tried to wake up but it was not a dream."
Which is to say... Scrum adds structure to the things that are easy to add structure to and seems to avoid having people think about the problems. You ABSOLUTELY can do Scrum without it devolving into a crap-fest, but it's not easy and you wind up using other tools, often without telling your management chain.
When I was at Amazon my team used Scrum but didn’t use Jira. I’d imagine the other FAANG companies don’t either
But... was decision making authority devolved to the team, SDM or TAM? ABSOLUTELY NOT. Our code was nothing but a series of queries to config settings and simple math. And even then it took weeks to get a decision on how things should work so we could tweak the config settings used in code that was now difficult to understand. Refactoring? pish! Unit tests? who wants to test every class? (i.e. - management didn't understand what unit tests or TDD were.)
My experience with Amazon was we toed the line for the easy bits of Scrum (ceremonies, etc) but the stuff that seems to matter where wildly different between teams.
If someone asked me "Does Amazon use Scrum?" I would say "in theory, but not really in practice."
In 2016 when we all moved to the new issue tracking system, I sort of wished we could use Jira. For most of that year my team put Todos and Issues in the GIT repo along with the code because we were tired of losing days of info in the system as they kept reverting to known good versions and losing issue tracking data (because the format of the data was dependent on new code that was just reverted.)
Though I do know that parts of amazon (AWS, Studios, etc.) were able to avoid the majority of the problems. I had hoped when Andy took over the whole shebang, things would get better. But after poking my head in last month, things as the bit-A seem to have gotten a bit worse: interns and SDE II's still do all the coding (one of the reasons i left; i'm not an intern and i like coding), but no-one on the team I was called in to help still hadn't read any of the TDD books and just assumed a unit test was a test you wrote to test a single class, because a class is a unit.
But let me stop bitching about a company I don't work at anymore and say I don't disagree with you but it brings up a point I should have mentioned: "Scrum" probably means different things in different teams. Big companies have a lot of teams that might all say they're doing "Scrum", but they're doing it in a very different way. Some will ignore the intangible aspects of Scrum and Agile, and only use the tools (like Jira). Others will be adamant that every ceremony must be performed at exactly the right time. Most will try to do the best they can even though product management has their heads so far up... hold on... i should be nice... i have worked with product managers that are excellent, i just wish there were more of them.
Yeah. Amazon is a big place with a lot of teams. They're probably all doing a version of scrum. And they're not using Jira. So we have an existence proof that it happens with at least big companies.
Yes, there are quite a few shops that use scrum without using Jira.
However, I'm not aware of a shop using Jira that isn't using scrum. This is useful to suss out job opportunities at companies who use scrum but don't want to advertise it. If they mention Jira, I know it's a scrum shop (important to me because I want to avoid scrum shops.)
I should have been clearer as to what my point was: Just 'cause you're using the tool (Jira) does not mean you're automagically using the process (Scrum).
And maybe a related side-point: Scrum (like Agile) is a way of thinking about software development. Not everyone gets that. That might be the value of a good Scrum-Master. I've yet to see a good Scrum-Master in the wild. Most of the ones I've encountered are just dudes who tweak Jira settings half the day and use the other half of the day poking at Jira's SQL schema so they can fix config errors they made before they learned how the current version of Jira works. Or... in other words... if you're only filling out Jira tickets and only doing the ceremonies, then you're leaving half of Scrum's value on the table. Too many people do this.
Absolutely. No tool can successfully make the process. Its job is to make the process easier.
> That might be the value of a good Scrum-Master. I've yet to see a good Scrum-Master in the wild.
Let me share a secret. I'm a trained and certified Scrum Master. You're spot on about it being a way of approaching things more than anything else. Software development is in large part an exercise in complexity management, and the Agile approach is fundamentally a very useful way of conceptualizing how to manage complexity at a very high level of abstraction.
But as practiced, I've soured on it quite a lot. The ideal is... ahem... ideal, but what we tend to see is kind of a funhouse mirror version of it that, at best, isn't helping. Different flavors of Agile are better (Kanban) or worse (Scrum) about this, but it affects all to one degree or another.
One of the best decisions my org made was to hire a dedicated Scrum Master. She configures all our projects if we want her to and she knows exactly the problems to avoid, the right questions to ask about how she should configure things, how to set things up so it simplifies our monthly project budget reporting meetings, and generally keeps us honest during standups (you guys have really low velocity; are you being interrupted a lot?).
Possibly, the second best decision was to give individual projects the option to use the Scrum Master or not, and leave that decision up to the team lead, including whether or not Kanban might be a better choice for that particular team.
I'm not anti-Scrum, I'm anti-people-doing-stupid-crap-and-saying-it's-Scrum. Sounds like you have a decent environment with people who sort of know what they're doing. Are you hiring?
I have seen (and often done myself) all of the following X items to avoid Y consequences in Scrum.
- Not written unit tests to get a ticket merged under the sprint timeline. We eventually turned them off at one org as a hindrance to merging tickets. Seriously, our unit test runner failed and to keep the sprint on track we disabled the tests. And to keep the project on track, they were never repaired. Scrum demands the sprint always provide value and as value is only what is provided to the user, no tests.
- Inflated points totals and conspired with others to inflate points totals so management is convinced pace is improving. I waited for my preferred and less diligent QA to be free to get a ticket done, so I am not interrogated holding up the burndown chart.
- Put unfinished functionality into the code as an error and merging it so that it would come back as a bug report, allowing the ticket size to be inflated for the same work.
- Skipping obscure edge cases found later if they would take more time, to avoid a lecture about the importance of detailed grooming. One job got to the point of specifying which files and functions needed to be changed for higher precision.
- Finished a task in the morning and then waited until the next day to pick up a new ticket because points is tied to days and you don't want the Scrum master asking why something is delayed in the burndown chart because you really only had half a day from when you assigned it to yourself.
The central failing of Scrum is that it is built on:
> Commitment, Focus, Openness, Respect, and Courage
And 1,3, and 5 in particular are either about different things for different people, or simply are absent because of the reality of a corporate hierarchy (i.e. it is always in your interest to suck up and seem reliable while hiding failures).
I hate sprints. It really feels like they're forcing us to come up with rough deadlines for arbitrary work, then treat those deadlines like a contract. We're playing ourselves.
I also hate all the ceremony around planning sprints. I'd much rather have a constantly sorted backlog and let the manager types focus on keeping the top tickets clear and actionable.
And to stave of possibly detrimental short-termism a culture of brain-storming systematic solutions to any significant problem (technical or HR) that has had a history of occurring more than once.
Work talk discussions should constantly revolve around tradeoffs instead of the word "deadline".
+1 to doing away with daily status meetings if unproductive.
Beyond that, you're asking a bunch of (probably) introverts to have a social meeting every. single. morning. That couldn't possibly cause issues with job satisfaction could it?
I did scrum for the first three or so years of my career. In my latest role we don't, and it's a way, way better daily routine.
If things get done the way the business wants them to get done, shouldn’t the people who dislike the meetings be dissatisfied with their job?
Worked at 3 remote teams and the team without scrum I knew the least.
So I'll stand by the statement that if daily sync is your solution, you are missing part of the puzzle.
Also, I really don’t see it as ‘social’ meeting, to me it’s a focused technical meeting about the work that is going on.
But people who have only done capital A agile and scrum are so buried in the philosophy that they don't understand that there are far better ways to do things.
Over a 40 year career I've done all kinds of methodologies. If you understand that there are far better ways to do things, I'm all ears.
The big advantage to agile/scrum methodologies in my opinion: dramatically improved predictability. Total elimination of drama. Efficient management of expectations outside of the development group. Never having to do a death march ever again.
I completed this task (or not). I'm working on this task. Any other discussions take place outside the meeting. Short. Sweet. No pressure. No drama required.
Fix it with Kanban. Or at least the Kanban-flavored way of working where you set top priorities, keep lines of communication open, and just do what matters.
All processes can be screwed up if your leaders try hard enough, but Scrum is almost never the answer.
The advantage to scrum when dealing with product management: an evolving prediction of what features you get, and when you'll get them. If you're neglecting the part where your product manager decides which features he can do without in order to meet his schedule, you're missing a vital part of the process.
That being said, I get your point with respect to sprints. There's something irrational about dividing work into sprints. But having done both, I prefer sprints. I'm honestly hard-pressed to say why. Maybe something to do with the psychological effect of feeling that you've accomplished something and done it well every two weeks, instead of once a year.
It may be true that one of the key traits of a software developer is low need for external motivation. But having done it both ways, there is something rather pleasant about getting those 30 second moments of satisfaction at having performed your craft well once every two weeks, instead of once every major product release.
It takes some getting used to, but in the end the PM not only has the information of when features can get delivered, they have more control because all they need to do to change a feature's timing is drag it higher on the board. No meetings, no fuss, just drag and be done.
I think PMs who declare they need Scrum for timing purposes have never explored the equivalent timings in Kanban. If they prefer Scrum, that is fine... but claiming that Kanban can't time features is incorrect.
For my current team, I like either sync or async (in Slack) standups that basically say if anyone's blocked or could use some extra eyes, and what's next in their sights. For a team project board, I prefer Kanban style without estimates--I've never seen velocity tracking used to any purposeful effect. If you want a team to build good features fast, don't bother them with "process theatre", instead ask the team lead/PM the questions and they should either have a good sense or be able to find out soon by having human discussions with the team.
Is it perfect? Of course not. But it's far more accurate than any scheduling methodology I've ever used over a long career.
I can't speak to why it didn't work for you. But I have seen it fail when an outside managers refused to allow proper calibration. Or when the same outside manager refused to make appropriate schedule or feature tradeoffs. In that particular case, velocity tracking predicted total disaster with 100% accuracy.
The fix is... just trust? You can do standups async, in text. Or better still, expect devs to move tickets accordingly.
We moved to monthly retros. They're a good fighting ground - people will argue about how we do deployment, QA, etc. We often argue on scrum and processes too. These are useful to do frequently early on and then reduce later. Sometimes we use them when something is slipping.
You can have demos just to showcase new features, without having to demo the API or do it live. Live wastes a lot of time because things suddenly don't work or people show uninteresting parts like loading or navigating all the way from the home screen.
This is one of the biggest issues I've seen in Scrum setups. I've seen the pressure cooker standup where it's like going into battle, to less hostile ones where but you are still doing progress updates.
I've found a senior dev or team lead doing the Scrum Master role is a lot nicer since they are naturally on the developers side and can empathize with them when the unknowns start to surface.
I've had this at my latest position for a while and it's been incredibly healthy. The team is incentivized to actually work together when someone has a blocker or stuck on something. It also turns into a team spirit boost because we can shoot the shit while people hop in instead of worrying about posturing for management.
The scrum guide 2020 doesn't mention story points at all.
I don't know how to fix this. But maybe we should just go back to plan in hours..
the problem with pointing is that a lot of tickets are really really trivial and the main expenditure is attention, not effort. and on the other hand, the cards that are big enough to warrant measurement are often chuck full of unknown unknowns.
Pros:
- It provides a common reference for everyone in the hope that developers might at least be consistently misestimating.
- It provides an easy justification for burndown multipliers, for those external sorts of people that object to burndown multipliers. "The burndown multiplier is a calibrated measurement of how imperfect scheduling estimates are (see The Mythical Man Month). Now go away and stop imposing unnecessary drama on my development team."
- It provides cover to those who assigned initial story points from being needlessly stressed over differences between estimated and actual effort (if you have one of those dreadful people who don't get it involved in your process).
I worked on a project (I do consulting) for a company that used scrum. The experience nearly gave me a nervous breakdown. The constant estimation and standup meetings were a total waste of time. I felt trapped unable to work on several tasks at once which is my normal MO.
I do like Kanban and use this for my current project. I will do estimation at some point .. but maybe not. My time is valuable and should be spent on working on the issues I have and not on estimation.
I have a proper backlog which contains tasks which are ready and are well described. I do have stakeholders with which I regularly communicate and modify the backlog.
So I do like parts of agile, just not the scrum methodology that I have been exposed to so far.
“Scrum works … if it is being properly implemented and followed.”
Sure that is with almost everything. In addition if you need an army of scrum coaches to implement scrum and you see many failures in the industry isn’t it time to rethink the process how we create software?
Maybe scrum isn’t the solution but just a stepping stone that came after waterfall.