Ask HN: Do you think Agile/Scrum is beneficial for software delivery?
what are the pros and cons of sprints and daily standups in your experience
Coming from old school 'non-agile' financial world focused on bottom line I was in a bit of a shock learning about this daily standup ritual.
Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Do these extra bureaucracy layers, meetings, checkmarks and vague "man-points" estimates actually bring any value.
708 comments
[ 0.24 ms ] story [ 291 ms ] threadMba-speak, translated:
Value prop = You don’t really need this
Data Science = Not a Real Science
I have it more or less working = It’s not working
I got it working = Please don’t ask me about this anymore
Does this make sense? = Are you even listening?
Let’s stop talking about talking about the issue = We’re halfway through this meeting
Please enter a jira estimate = I am or want to be your boss
Quick stand-up = I’m interrupting your flow
Daily stand-up = I’m interrupting your flow every day
PM = Tom Smykowski
Product = Paid Intern
Feature complete = See “I have it more or less working”
Deep dive = I have no intention of pursuing this
In-flight = I enjoy dramatizing the trivial (See “How Can We Land the Plane”)
This is not intended to offend anyone = This probably offends everyone
Big Data = an Excel spreadsheet
Decentralised = not our problem
Open-source = we didn't build it
No-code = I didn't want to pay a programmer
That's also the reason they advocate that ideally the team should sit all together. In that ideal work the daily stand-up lasts only 5-10 minutes, it's not meant to be a dreaded status meeting where you talk for 5 minutes then try not to fall sleep for an hour...
It's meant to help keep the team aligned on what everyone is doing at a higher level, not for any details at all. After the standup, the team can address any requests for help that came up as needed. But that falls outside of the standup.
Agile is meant to help empower teams and improve their velocity, and that requires people to own their own stuff. So the standup should be a purely informative, high-level overview of where the team is so everyone is aligned. If it's anything more, it will become a cumbersome, painful exercise in micro-management and tangential discussions.
In my mind scrum has less bureaucracy than that.
Scrum Meetings are best used as a way to come together as a team to work how to make progress today.
For example:
I want to deploy this change to prod today, but one of the tests is failing and I don't know why. Ok lets get a couple of people to mob on the test to figure out whats going on after scrum etc
That's a good scrum meeting.
Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x yesterday etc Person 3: I tried to get x done yesterday, but I got stuck i'll try again today.
No value whatsoever.
The emphasis should be on problem solving as a team, and focusing the team on pain points to get work across the finish line.
To that end i find "walking the board" far more valuable, than status updates from each memeber.
- Standups don't need to be daily - it's too much. Twice a week is okay (this can be adjusted depending on team/product dynamics).
- They shouldn't consist of everyone telling everyone else what they're working on. This practice is boring and useless to anyone who is present. (If you want to check what I'm working on, log into the issue tracking system and look at the tickets against my name.) Instead, standups should focus on pieces of work that need to be delivered or that need to change status.
But this was their personal understanding, and was then removed to pave way for the mandated certified "Agile" methodologies and rituals (=WaterScrumFall). So whatever was learned, gets lost in the next turn of the wheel, inevitably.
What people miss in their accounts is that any success or learning is temporary, and in the organisational space, change is inevitable rendering all and any accomplishments transient.
It's a common habit people fall into when transitioning to scrum. An experienced scrum master should never let this happen though.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.
The agile manifesto is tiny and a scrum guide like this one: https://scrumguides.org/scrum-guide.html is readable in a couple of hours. But the version of "scrum" forced on many people is a far cry from that.
A dysfunctional team won’t be fixed by a new process to follow. It’ll just warp to the dysfunctions.
The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective. When this is included and is permitted to include not just code/product issues but also process issues, it has worked very well even when they skimped out on other elements of Scrum. But most often the retrospective is absent or the process is not permitted to be included in it. This makes you fundamentally anti-Agile as you literally have a rigid, static process.
The one consistent element that I have found across nearly every reading of Agile I've done and my experiences over the past (now almost 20 professional) years has been that the critical element of agile is its responsiveness and introspectiveness. Lacking those two things you do not have anything that can be called Agile, at best it's an imitation, at worst it's SAFe and you should run fast.
DevOps, Lean, Scrum, Theory of Constraints (realized in software, at least in part, as DevOps) to the extent that they have defined processes they are not the same. But the consistent element is introspection and responsiveness leading to adaptation to the team, organization, customers, and systems being developed/maintained.
This is the critical element missing from many organizations and teams at the time of the manifesto. See Waterfall, any CMMI office. They become static, they delay their feedback loops to extraordinary time frames. Waterfall (may it die a fiery death), in some spectacular failures I've witnessed, had 5 years from start to delivery for customer test, not deployment. CMMI has a strong association with Waterfall (unjust in my opinion), but it still promotes a static process that is only reviewed when it's time for your next appraisal (technically it promotes continuous monitoring and improvement, but like with Scrum everyone ignores it).
It's still a crucial element missing from many organizations who have cargo culted their way into Agile or adopted "Agile" processes (like SAFe, may it suffer the same fate as Waterfall). If your processors ever become truly static, you either found The One True Process (for your team and situation) or you're failing to recognize and adapt to your circumstances.
This is explicitly forbidden in Scrum. Retrospective is the only part that cannot be removed.
But I agree, most companies prefer to allow as little feedback as possible.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
For experimental stuff, agile could be good.
For product stuff, Scrum could be good.
For commodity stuff, six sigma could be good.
Using one of these for something it isn't meant to do will lead to failure.
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That totally relates to my experience.
I've seen this scene repeated over and over:
- project begins
- something happens and delays the project (arrival of new team members who need some time to learn about the code base, for instance; it's not even an issue, it's just a natural consequence which makes the project go different than planned and put certain kinds of managers in distress)
- project start to get behind of the schedule or whatever tool in use to track progress
- "you are not a true Agilist"
I just can't understand why is it so easy to blame the old methods while it's so hard to identify weaknesses in the current ones.
Besides, the room they left for interpretation leads to a good amount of bike-shedding and witch hunting as soon as something goes wrong in the project -- if one assumes the method is perfect, the only possible explanation for a failure is that the method has been misfollowed.
Scaling developers vertically requires having support tools, processes, and people to get past the things that trip them up and back to forward progress. They don't have to be big tools, or big processes. In fact it's much more important that they be reliable than that they have huge feature sets.
But Agile without tools and processes? Show me anyone who is pulling that off, and I'll show you someone who has mislabeled a bunch of things as 'not-tool' and 'not-process'.
"That is, while there is value in the items on the right, we value the items on the left more."
Agile doesn't mean no documentation and no tools - it just means they should not be the focus.
Except for Jira, of course. /s
The difference is one of intent. Having tools or processes to have processes is a bureaucratic mess which they Agile folks rightfully wanted to cut with a scythe. Sword. Scary sharp thing of your choice.
There's a difference between building tools and process, and building a culture of toolsmiths and process tweakers. The latter, I think, follows the spirit of Agile but not the letter of it. And lean is just... throw the baby out with the bathwater. It's bureaucracy as written by a minimalist.
It’s so common that it’s been branded: SAFe, and it’s a complete abomination.
As an example, I have never had a PM/Team practice Agile/Scrum in a manner where the total amount of Work-in-Progress is something that gets paid attention to.
In my opinion this is a very serious error.
If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.
Okay, so suppose my best guess is that there is a 10% chance something could be done in a day, 80% chance it would take two or three days, and 10% chance it would take five days. What is supposed to be my "estimate"?
If I keep giving the longest time interval, I will seem like lazy and incompetent, because why am I always saying "five days" to tasks that everyone knows usually take only two or three days. But if I say "three days", then in those 10% when it actually takes five days, I have estimated wrongly.
In a long sprint, this will usually average out somehow; one "three-day" task will take five days, another "three-day" task will take one day. In a short spring, things are less predictable.
(yeah, technically it's not days, it's story points, but the idea is still that "medium complexity" only means "medium complexity unless something unexpected happens" and the unexpected things sometimes do happen, you can't simply commit to unexpected things never happening.)
I don't know how they do it, but you used to have to group stories to stories of similar effort done in the past in order for the simulation to take into account story size. Otherwise your model will be effected by things like stories in different components taking more effort to do.
Putting stories into rough size pots is essentially what pointing is.
You aren't, and that's the grift.
I force developers to do something they are bad at. They get better, but they're never 'great' at it. So I can withhold raises they deserve because I'm punishing them for what they're not good at instead of rewarding them for what they are great at.
This was my complaint of the term “velocity” because it sounds objective and absolute when it’s really much more arbitrary and not even comparable to the same team from year to year.
So reality trumps ideals.
This article gave me clarity between the two philosophies. Kanban is about perfecting the process and trusting that results will naturally come as a result of that process. Agile is about attaining the outcomes and then focusing on what works for those outcomes.
I agree that Kanban makes more sense but Agile allows managers to point the finger at devs instead of having to point the finger at themselves.
What really gets me about story points are the Agile folks who say "story points are a measure of complexity not effort/time". As if adding more complexity in the same amount of time were a good thing...
But I think that would get thrown out at the first sign of trouble. In many companies if the anonymous survey showed we were behind schedule the fix would be to stop doing the anonymous surveys.
I think this is suspicious. It smuggles things from the Old Ways into Agile. Estimation sucked, to a fatal extent, when trying to do critical path analysis of software projects. Why should it suck less in Scrum?
The manifesto mentions retrospectives. Retrospectives have hard reliable data. You can learn from retrospectives. Estimation is unreliable. Would project outcomes actually differ with less emphasis on estimation? Would they improve with more emphasis on retrospectives?
Story points are even worse than man-months at measuring work.
Because in scrum not only is the assumption that the estimate for a task holds not matter who and how many works on it, but dependencies are also not handled well for either tasks or backlog items. To some extent a team can try to handle it in a sprint, but it is not part of the estimation.
For example it can be a lot faster if the same developers can work on corresponding frontend and backend jobs. If they are split in different sprints or if the developers also have to work on other tasks, it could take a lot longer.
And the whole story points, fibonacci, etc is just nonsense. If an experienced developer estimates that a given job would take somewhere between 10 days and two months, depending if they can reuse X and the Y algorithms performs if he and developer Z works on it, then that is the best estimate you will get.
The only thing that makes scrum estimates more precise, is that once you have broken everything into 100 tiny tasks, you have added about 20 hours of writing commit messages, updating JIRA, and preparing for the next task.
In a team of five, we might get 2,5,8,8,20. The value of the estimation was in discovering that someone thinks it's a 20, while someone else thinks it's a 2. They tell the rest of the team why, and we estimate again. Another useful signal is ?,?,?,?,? or (50,50,50,50,50). And of course, 5,5,5,8,8 (or other general agreement) suggests that this is low risk.
You certainly wont hear that from a scrum consultant.
Why? If you made those more detailed estimates and models (which I'm sure would have a significant time cost), what would you do differently based on the results of them?
You need a rough sense of how relatively costly different tasks are, so that you can prioritise - if you ask the business/product side to prioritise completely blind, you'll end up not doing small things that could have brought a lot of value because they assume those things are hard, and you'll spend far too long doing things that they thought would be easy but are actually hard. So you want developers to do just enough estimation to allow the business to prioritise. Which means giving a low-detail estimate and giving developers assurance that it won't be used as a deadline. Story points are the most effective version I've seen.
(I don't watch videos, I'd be happy to read text articles)
Management needs tools to detect (1) slippage, (2) true cost, (3) emerging issues.
Engineers need to not silo, work together, make progress, and share status.
Amazon would do it at 11am, and it would last no more than 10 minutes for a small team. Every two weeks, management and engineers get in a room to holistically determine where things are at, and then they go and report status up.
What I would tell teams that I bootstrap is that the process itself doesn't matter, but the team needs a shared discipline to be effective. Their team has desired outcomes and everyone needs to be accountable for making progress.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
When the great CPU architect Stephen Keller was on Lex Fridman's podcast, he made a comment that architectures should be refactored every 5 years and I thought to myself, "Good luck with that in Enterprise" as I looked over at the 10+ year old legacy infrastructure holding back org-level velocity at work
Doesn't mean there isn't value to companies that have succeeded with it, or created a value culture around this coordination. But my experience was a bunch of people sitting around talking about what color paper should be used for a particular work item on the sticky board, which I struggle to see the value of.
So. If you're not doing scrum you are not leveraging it's potential and even more important, its rules.
The rules of a daily is non-disputable. It has a formula. If you're not following the formula, it's not scrum.
A daily is not about progress. It's about communication. You communicate what you did since the last daily, and what you expect to do before the next.
But you're not being measured on what you communicated. You are merely sharing what you' re doing.
If there is discussion in a daily, it's not a daily. If you're not using a board for the baseline for communicating, you're fucked.
The role of a scrum master is to take note of what is going on and help out if she hears anything that sounds off. A good scrum master is a bit like a dictator. Focused, on top of things, helpful and listens to what is going on and does not bend to outsiders.
Good scrum masters are hard to come by. That's most often imo, why scrum had a bad rep in some places.
Also remember, agile is something that must happen on a top level, otherwise it will not work very well.
This is never true. Its a daily confession of what you did. Its micromanagement.
Beyond that, it's just a way of doing things, much like an OS. It doesn't matter if you're running W10, MacOS, or some flavor of Linux. If it's the right tool for the job, then it's the right tool for the job. But if it's not, then why is it in use?
I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot.
If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion.
I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices.
Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore.
One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.
Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work.
Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.
and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects.
Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time.
Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.
Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures.
It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition.
But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings.
I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)?
In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation.
I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center.
> It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.
Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation.
Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.
It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
Not to beat a dead horse one more time, but "Agile <> Scrum"
Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum.
And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto.
And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.
I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management).
I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up.
I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed.
Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.
I'm curious how bigs were your teams? and if you were all local in the same office?
There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
(More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.)
> I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next.
In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time".
> One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible".
This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".
A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.
Too often though in practice it devolves into a kind of cargo cult and the apologists lean way too hard into the "if it isn't working, you must not have believed in it hard enough" defense which is a bit too easy in my opinion. It short circuits any actual reflection and learning.
Basically, the agile manifesto is great.. the stuff agile coaches try to sell you is hot garbage. Everything else is somewhere in the middle, but Kanban is the closest because it preserves the "we are uncovering" part of the manifesto.
Scrum, management, meetings distract at best, crush at worst, this critical creative process.
Then you check in as a group on a weekly, or maybe twice-weekly basis, with an explicit goal of identifying risks and uncertainties that have arisen during that timeframe.
The goal here is not to micromanage, but to give a sense of progress towards a goal - whether a metric shift, a release, a roadmap commitment, etc. If you don't hit your interval milestones a few intervals in a row, your high-level thinking about timing is wrong, and you need to adapt the project or the timing.
Agile is defined here: http://agilemanifesto.org/
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
And it also contributes to this one:
"The best architectures, requirements, and designs emerge from self-organizing teams."
That statement indicates just how broken the whole idea of "Agile" is.
Agile/xp started at Chrysler as a way to push back on management on give engineers a chance to pace/structure/set expectations for their work
Modern agile is just a management framework used as an excuse to micro manage the shit out of your work force.