You should really consider dropping sprints
Posted by ninetofivedev@reddit | ExperiencedDevs | View on Reddit | 156 comments
So recently I made a post about switching to 6 weeks sprints and I want to address a few points brought up.
- Just use Kanban instead
This is actually something I think most of us are onboard with. The problem is selling to management this continuous stream of work with no clear dates for start and end.. For whatever reason gives them heartburn.
- Misconception that sprints align with release schedules.
They don't. We release multiple times per day, sometimes we go days without a release. Point is, we release when we want to.
- Misconception that sprints align with stakeholder feedback.
They don't. We're constantly getting feedback from stakeholders. We're also constantly prioritizing work. Just because we planned 6 weeks worth of work doesn't mean work doesn't get pulled in and it also doesn't mean deliverables that take considerably less time don't get delivered in shorter spans.
- Sounds like you're doing agile wrong. There is something wrong with your organization.
I know. We all are. Tell us something we don't know.
- OP, you're an idiot.
I know I am. And I know this is all stupid. But I really appreciate the constructive criticism.
TLDR:
I made this post to address something that has become the norm in our industry. And that's this completely "standard" way that every company under the son has decided to manage projects. And that every single variable, down to how long the cycles run, is completely fixed.
I would venture to guess that over 85% of all companies run on a very specific methodology of "Agile", all pulling from the same Scrum boiler plate with all batteries included.
The point is to challenge these assertions. Consider longer sprints. Consider skipping ceremonies. Consider doing away with standup. Consider dropping Jira.
More-so, the key thing dropped from Agile: Individuals and interactions over processes and tools.
This, to me, is the most important thing that makes an engineering department successful. And yet, everyone is running the other way.
Trick-Interaction396@reddit
Not matter what we choose to call it we’re all actually doing Kanban
Robodobdob@reddit
Everyone ultimately ends up doing some form of Kanban because it naturally fits the lumpy nature of work.
Etiennera@reddit
Sprints are okay to set regular intake and retrospective meetings. They suck if assuming work completes at the sprint boundary.
Brutus5000@reddit
That's my take as well. Showing the progress in a review and talking about the way of working in a regular interval is a good thing. Even if you are actually doing Kanban.
NoPain_666@reddit
99% of sprints we continue stuff from previous sprints. And we add new items to sprint during it, when work runs out.
MoreRespectForQA@reddit
Yeah, but if you call it scrum you can create an artificial sense of urgency at the end of each "sprint" which lets you create more compounding technical debt.
james__jam@reddit
Highly disagree.
Everytime i hear people say they use kanban, almost always there’s no WIP limit
If you have no WIP limit, you’re not doing Kanban.
RGBrewskies@reddit
don't understand. I work on one ticket at a time. what other option is there
BogdanPradatu@reddit
Work on multiple tickets at a time?
RGBrewskies@reddit
why would you do that. Just finish a task.
BogdanPradatu@reddit
Push a change, wait for CI, do a change on another branch. Wait for review on a PR, work on something else etc.
RGBrewskies@reddit
this makes so little sense to me
if I've pushed the PR, it goes into Code Review, and I'm on to the next thing
If I'm waiting on a PR, the ticket is in code review, I'm on the next thing.
There is no "go work on something else" , I finish one ticket then complete the next. It wouldn't make sense to stop in the middle of one, I'd just lose context and momentum. Sure shit happens and the boss says drop everything go do XYZ, but that's extremely rare
there is rarely a spot in my ticket where it would even make sense to pause. My ticket is "add field XYZ to the database" ... how would I come back to that later?
I think your tickets are way too big.
again we're speaking in generalities here, there's always exceptions. But 99% of your tickets should be laser surgical.
BogdanPradatu@reddit
My tickets are sometimes a little more complex than just add a field to the database. Sometimes I need to collaborate with other teams and will have a PR that is dependent on another teams PR or maybe I will start working on something and then realize in some locations the firewall is blocking traffic so I will need to raise a ticket for the firewall team and wait for them to solve it.
Sometimess I will need to handle hardware testing and maybe there are not enough hardware resources available, so I will run the CI and will end up in a wait queue and the teste take 1 hour to run as well. I can do something else in that time, I'm not just gonna stare at my screen until the tests finish.
Sometimes reviewers don't have time to review my PR quickly, so it just sits for a couple of days until I have feedback. I'm gonna work on something else in that time.
RGBrewskies@reddit
interesting, just two different worlds I guess
Constant-Question260@reddit
Our CI takes around 25 minutes to complete. I sure want to do something else during that time. And don’t „make your ci faster then“
RGBrewskies@reddit
your ticket is over when you send it to CI is it not... what are you waiting for
Constant-Question260@reddit
Maybe some tests fail. They take like 10 minutes in ci and 6 minutes locally so I often resort to just push it in ci and look at it. Oh. And our CI is flaky sometimes (I could go on about this for an hour and the problem is currently under fixing)
itsjustawindmill@reddit
Many team or product development cycles are very pipelined and have handoff points between teams. When you’re waiting on another team to unblock some final part of your implementation, or waiting for a long regression suite or fuzzer analysis to finish, do you just stare vacantly at the ceiling?
I think it’s fairly normal to have multiple tickets in progress at the same time, and switch between them as you become unblocked. IMO this also helps with burnout because you get more variety in your day and don’t have as much stress from being dependent on someone else (because you’re still producing results in the meantime).
Also, if a ticket was started but then got pre-empted, do you really always move it into another column? I don’t! Time tracking that granular is just a waste of time that enables micromanagers to invent problems.
RGBrewskies@reddit
If I'm waiting on something for a ticket the ticket goes into Blocked status and passed off to that person/team... they hand it back
james__jam@reddit
Sounds like you’re just near the start of the pipeline and dont care about the folks near the end.
Actually, by the sound of it, you just care about coding. Not your problem if it never goes to production.
RGBrewskies@reddit
dumb as fuck
james__jam@reddit
Says the person who does not know how kanban works or cant even be bothered to google how it works
Ventukas@reddit
WIP limit is not for you personally. It's for the whole team. The team allows only X amount of items in progress at each stage (Jira columns). It forces you to focus on actually finishing things before picking up new tickets.
Affectionate_Link175@reddit
Ding ding ding!
bbqroast@reddit
I mean this is mostly because kanban can be vaguely jammed into "we do the work in pieces in some order".
Perhaps the main value of "kanban" is being a system you can tell the higher ups about without requiring a bunch of admin.
MichelangeloJordan@reddit
Always has been 🌎🧑🚀🔫🧑🚀
Sprints just exit to squeeze us to do as much work as possible
ChemicalRascal@reddit
Only if you're not being empowered by management to make decisions around work estimation.
In those environments, yeah, just Kanbanning a ticket inbox is the right way to go, capacity estimation isn't going to be useful.
w4tch3r0nth3w411s@reddit
Been with my current company for 3.5 years and we’ve never done sprints. We use a process called Plan of Record and sync up with product and stakeholders weekly centered around a per-project basis. Teams have 1-3 projects in progress at any given time, and we do our research spikes and refinement up front (if possible). We provide a rough level of effort and date estimate before starting Engineering work, and make heavy use of CI/CD and feature flags so we can release small iterations at a time, usually daily. As the project progresses we’ll refine our date to be more precise if needed. Deliver dates usually evolve from e.g. Q2 > April > mid-April > April 13. For bigger and more visible features usually Product, CS, and Marketing want a more specific date up front so we will usually overestimate.
ForeverYonge@reddit
I ran a team on Kanban and it worked really well for both advancing long term plans and urgent interruptions.
I also really like somewhat-longer planning cycles, like Basecamp’s 6 weeks
ProbablyPuck@reddit
I'm being sarcastic, but I'm damn near ready to put us on waterfall to penalize requirements changes. Decide what you want us to build already!
prschorn@reddit
There's one project that it's pretty much a cyclic waterfall of 3 months, and I have to say that it feels quite good, you design, define a closed scope, implement and ship. We rarely have changes in scope
New_Enthusiasm9053@reddit
That's waterfall. The literal definitive paper on waterfall recommended exactly that. Multiple iterative cycles with meaningful planning and test cycles.
Of course it became most companies thinking they'd one shot the whole thing but hey. The author of said paper also Sait that's idiotic in the same paper.
Constant-Question260@reddit
Do you have a link to the paper? I would love to read it.
New_Enthusiasm9053@reddit
https://www.praxisframework.org/files/royce1970.pdf
Constant-Question260@reddit
Do you have a link to the paper? I would love to read it.
LeDebardeur@reddit
For already established products, that would make sense. But for new ideas or businesses that move fast, then that would be a long feedback loop and wouldn't deliver meaningful impact.
chipstastegood@reddit
Each individual requirement goes through a waterfall process
ProbablyPuck@reddit
That's what they keep saying, but I'm not convinced.
Constant-Question260@reddit
Now add some feedback cycles and boom you got an agile waterfall or - like I want to call it - an agile river.
latchkeylessons@reddit
I much prefer waterfalling anything I can these days for the all the reasons mentioned above. Fact is the business just wants to throw shit over the fence to do and there is zero ownership unless it can be shown to immediately impact timelines.
grizzlybair2@reddit
Yea our requirements are changing daily and yet we already have stories filled out. Then we have to magically know someone updated a confluence page and with what details. Each and every day. So over it.
capGpriv@reddit
I’ve been fighting for a monthly waterfall in my company (small startup)
We have no QA, and requirements just come from the C suite with no actual reason, or customer demand. I had a project where the only requirements were the title.
Modern agile acts more like a cult. We have had good people trying to push for hiring a QA for a tiny team, and a team all dispersed on little project, unable to help each other.
And all we need is a system of monthly goddamn jira releases, where the team all agree what goes in at the start, we all see the work items so we can help, and we all user test near the end.
Isogash@reddit
Recently I called for a "requirements" meeting because I was unsure that we really knew what we were supposed to build for a ticket. I asked product in direct language "can you walk me through the first planned use case for this new feature" and they said "we don't have any planned use cases for this feature yet."
Iannelli@reddit
As somebody who started as a Business Analyst in the mid-2010s with Waterfall, and was a part of large $20 billion dollar organizations through their "Agile Transformations"....
... I have to say, many people - myself included - are starting to suggest going full circle back to some Waterfall principles. Agile is a mere ghost of what it once was. Whatever the fuck it is today, is absolutely miserable for almost everybody.
At the end of the day, unless you're saving people's lives or creating technology that saves people's lives, basically everything we do does not matter. There is simply no fucking point in making everything so stressful and so annoying constantly. We're all just enriching shareholders. If we all have to do this bullshit, why are we choosing the most frustrating, unfulfilling, and soul-sucking path?
I feel bad for people who didn't get to experience working in tech or tech-adjacent roles from the mid-2010s and prior. It was truly a fantastic time. I strongly encourage everybody reading this to start to suggest using Waterfall principles in your organizations. It makes life a lot easier and less frustrating.
Lyelinn@reddit
Ultimately all processes are just complicated trello lol
Does not matter when you release (different for each company and business), you're moving from todo to done
patient-palanquin@reddit
"For whatever reason" is uncharitable. We are not doing work for fun. We are doing it because it is necessary for the business, and much of the time there is somewhere down the line that needs to know when it's going to be available. If you can't give them reliable estimates, they can't plan.
I don't think 6 week sprints is a good idea for the same reason why weather forecast don't go out further than 10 days: companies are chaotic systems that are hard to predict. If you can predict out to 6 weeks, congrats, you are remarkably stable. Lots of companies can't, and need smaller sprints to be able to pivot quickly.
vvtz0@reddit
Exactly. What you call chaotic, Cynefin framework designates as "complex" - such organizations operate in the domain of "unknown unknowns" and the best recommended approach to move forward in this domain is in small iterations, conducting experiments that are cheap to fail.
And basically the entire software industry has always been in the complex domain - "no one understands what we need to build but we need to build it by yesterday". And it is exactly the basis for the whole Agile development idea: plan work in short bursts, experiment and fail, gather feedback early and iterate.
Half a quarter sprints are so opposite of this approach, they are not even sprints. They are marathons.
And the OP says they're already delivering increments daily - so why 6 week marathons then? Just because of not willing to sit through planning or demo every other week? Then Kanban should work and if they need to sell it to management then let them set up some predictability metrics to keep lead time, queue length, cycle time and whatever else in check - and everyone will be happy.
Constant-Question260@reddit
I‘d argue that not the whole industry is in the space of unknown unknowns.
Perfect-Campaign9551@reddit
Nobody "experiments and iterates". It's a myth. The feature is expected to be done and working as expected by end of sprint. Very rarely do you ever get "feedback" and touch those features again
Aelig_@reddit
Most companies do quarter planning and that's all middle and upper management care about. There is no pivoting no matter how you schedule the work within that. Sprints are for devs and if it doesn't work for the devs they should change it.
ThlintoRatscar@reddit
This.
Sprints are the period of time that a team needs to show their work to the people paying for it.
A team that can be left alone for half a quarter is probably a team that nobody really cares about. It doesn't need a lot of feedback from the stakeholders and doesn't do enough that anyone cares to look too deeply at it. It'll deliver whatever it delivers, when it delivers it.
If a team is just producing the next daily ticket with no larger concerns, it also doesn't really need to account for the larger impact of its choices. It's pure customer service and that's best done with a continuous flow planning tool like Kanban.
But, for teams that need time to produce something meaningful for people that care, regular sprints can be a good tool to set expectations, get feedback, and adjust.
Working under the weight of expectations can be hard and uncomfortable, for sure, which is why most of us that dev don't like doing that. But, once someone is paying, those expectations start to matter.
ninetofivedev@reddit (OP)
But why. Why 2 weeks? Also no. I reject the premise. Our release cycles are daily. Our work is continuously shown to both our users and the people paying for it.
ThlintoRatscar@reddit
It's abitrary based on the availabilty of your stakeholders.
If daily works for everyone, then you have daily sprints. Kanban wouldn't even have a daily summary at all. It's just a continuous flow of work.
I would caution that a daily release ( we used to call those "nightly builds" ) doesn't necessarily mean that the work quantum is of daily size.
In many shops, while there is a daily release, there are still weeks or months of planning, testing, design, and customer collaboration that happens in parallel. In those kinds of shops, each "project" may simply take a set of daily releases as their weeks long sprint rollup.
ninetofivedev@reddit (OP)
Nightly builds is a relic of the past and is completely different than what I'm talking about.
Daily releases aren't really daily. They're adhoc whenever we need to, typically we release at least daily. Sometimes we release 10x a day. Sometimes we'll go 3 days without a release.
We build software, especially for the web, in a way that enables this concept of "release cycles" completely. Our software is constantly getting built. Our artifact repos are full of builds that won't see production.
Yes, now you're on the right path. Why the hell are we talking about releases when planning and releases are not coupled?
ThlintoRatscar@reddit
Because even in Continuous Delivery ( ad hoc deployments ), the deployment of software to an environment is not the entirety of what a release is.
A release also needs to be funded, marketed, documented, trained, and tested and the coordination of those other groups happens at a different pace than the devops "done!".
So, it sounds like the reason you have sprints in your organisation is to coordinate with your wider organisational partners and instead of doing that ad hoc, your management has decided that a regular cadence is best for everyone.
ninetofivedev@reddit (OP)
I don't really accept this premise either.
You're saying that the engineering organization is responsible for inviting the CEO over to the workshop and demonstrating the product to them.
I'm saying that I expect the CEO just to come over whenever to the workshop and inspect the product if they should choose.
Also the only reason funding, marketing, documentation, etc need to align with delivery is if you set that expectation for your customers or operate that way.
So sure, for specific use-cases, what you're saying is correct. Now why do we conform all standards to this apparent use-case?
ThlintoRatscar@reddit
And all the other stakeholders, yup.
Consider the disruption to the workshop and dev flow when random people are constantly interrupting and asking for status, running ad hoc tests, and offering advice/critique/demands in real time. And they feel entitled to because either their work depends on understanding and aligning with the devs, or because its their money and vision that the devs are hired to deliver.
Eventually, the circus comes to town and some poor engineer with people skills gets sacrificed to the meeting gods to convey the same information once.
That "engineer with people skills" ends up being a team lead, PM, or Scrum Master and they start asking the devs or testers to explain the rando new features and how they work.
Rather than doing that every day and giving a bazillion personal demos, they schedule a recurring meeting every X weeks/months and invite everyone to it.
Hence, sprints.
If you never have that many interested non-technical stakeholders than you don't need that framework.
We don't.
Steve McConnell way back when dinosaurs soared the skies wrote a book called Rapid Development where he laid out a compelling case that different projects required different frameworks. CD, Agile/Scrum, Agile/Kanban, Spiral, Waterfall, Stage gate waterfall, cowboy, etc... all were optimised for different organisational problems. Picking the wrong method contributes to why things fail to deliver as expected.
There is no silver bullet.
ninetofivedev@reddit (OP)
And yet, by and large, if you join most companies today, they all operate the same.
2 week sprints. Daily standups Jira Once a week backlog grooming Once every other week sprint planning Once per sprint demo Once per sprint retro
Everyone estimates with Fibbonacci numbers.
Maybe I'm not getting clear to people here. Maybe every agile discussion just has to run this course. I'm not saying that it shouldn't be more extensible and adaptable. I'm not saying that we should be doing something different.
I'm saying that nobody does. Even if we all will agree that we should do what works for us. Almost nobody actually does.
If you do, congrats, but you're in the minority.
ThlintoRatscar@reddit
Or... it could be that most businesses that produce software of similar size have similar problems with similar solutions.
Management theory has discrete and statistical math, just like we do. They have standard architectural patterns, just like we do.
There's a reason why most people just throw quick_sort at it until they need to reach for something specialised.
So too with why many companies start with Agile/Scrum and then only branch out to other specialised systems when they have to.
ninetofivedev@reddit (OP)
This largely assumes that these decisions are made with intention and not just cargo cult and tribal knowledge.
I think you're giving most companies way too much credit. Every CTO at every startup that I've ever worked for didn't start off with scrum because they crunched some numbers and it made the most sense.
No, they started off with Scrum because that is what they know.
But who are you going to trust? You think these companies that use LoC and Token burn as productivity metrics are making calculated decisions?
ThlintoRatscar@reddit
Well... most startups fail for good reasons so I wouldn't hold out that they have some kind of extraordinary talent or great insights.
Outside of startups, most professional CTOs have come up from the ranks and do actually know their craft. They work with their PMO to build intentional management processes to deliver results in a complex and chaotic environment.
Agile/Scrum is definitely an appropriate methodology for a swathe of corporate architectures.
valence_engineer@reddit
Lets force more work onto the single CEO of the company versus doing the work ourselves is how the CEO finds someone else to do your job and you need to find as new job. Like it or not, the CEO is more important and much more time constrained than you, your manager and your whole team.
ninetofivedev@reddit (OP)
oh brother...
_vec_@reddit
In my experience 2 weeks is usually the minimum bound on how often you can reasonably ask the stakeholders to block out some real focused time to understand and evaluate the work and provide useful, actionable feedback. If you've got management/clients/customers/etc who are willing and able to devote more of their precious time and energy toward you and your team then that's a good problem to have.
onafoggynight@reddit
No, deadlines are that time. You do not need sprints to establish and control those.
Mabenue@reddit
You do need some way to track some sort of progress towards a deadline though. Or end up setting loads of arbitrary deadlines to just help keep things predictable.
I really don’t understand why people have a problem with scrum. It’s a really simple and easy framework, just commit to some of work to be delivered in two week increments or whatever. It’s that simple.
onafoggynight@reddit
Yes. But for non-standard tasks that progress is often not linear. So estimating it via scrum in terms of story points / velocity does not give me anything.
It also does not tell me anything about risk. I.e. progress in terms of standard churn is meaningless until specifically critical blocks are addressed.
So the plain solution is boring project management anyway, basically a critical path along with specific milestones. Fundamentally, I (and certainly not stakeholders) care very much about progress in terms of scrum points (there is a reason why business deliverables never talk about them).
Our devs don't like it because of the overhead -- some of the work we do is not meaningfully split-able in a non-artifical way / in small enough discrete scrum stories, that are genuinely "valuable" (and thus justify the overhead of breaking them up at the planning level).
I don't like it, because it obscures when and how business value is generated. I also don't like it, because it's not sufficient, and thus basically (again) extra redundant work from a project management / planning perspective.
So, overall, just extra ceremony with no clear beneficiary.
Fair_Local_588@reddit
Or these teams commit to quarterly deadlines and deliver consistently. I wouldn’t take your personal experience and then apply it to all companies.
LousyGardener@reddit
> If you can't give them reliable estimates, they can't plan.
"Reliable estimate"
This kind of stupidity is why I can't stand PMs.
patient-palanquin@reddit
Yeah, reliable. estimates. Part of your job is to provide that. If you can't, you are a bad engineer.
engineered_academic@reddit
Doctors can't even give you a reliable estimate on how long it takes to make a baby.
patient-palanquin@reddit
Yeah they can: "about nine months". That is an estimate. It is reliable.
engineered_academic@reddit
Ah see you are assuming that the baby is already conceived. If you suddenly discover you have some kind of infertility, there is more testing and procedures that blow out that estimate while you struggle to root cause the issue. Sometimes, but not always the baby unexpectedly is no longer viable mid-development. We have also developed chemical methods of inducement and prolonging to force the baby to come out "on time".
AdjectiveNoun1234567@reddit
Meanwhile, the Boss proposes hiring another developer to produce a baby in half the time
LousyGardener@reddit
Estimates are unreliable by definition dingus
patient-palanquin@reddit
Who told you that? Nobody knows the future, everything is an estimate. Is everything unreliable? No, because you can use your brain and give decent estimates.
LousyGardener@reddit
I got a better one
If there are no unknowns in your project, you're not creating software, you're creating content.
thecastellan1115@reddit
I always get a chuckle when people act like deadlines don't exist or shouldn't exist.
Guys. Major releases have a ton of shit that goes on that is not relevant to you, but super relevant to the organization. Budgeting, communications, long-term planning, upper management briefing and expectations, etc.
I'm on board with revisiting the sprint concept when you cross into pure sustainment... but by the same token, the number of times I've seen a live product in pure sustainment, let's-just-keep-the-lights-on mode I could count on the fingers of one hand.
MoreRespectForQA@reddit
I always get a chuckle when people think devs are the ones being unreasonable. It's businesses who simultaneously want waterfall planning and and deadlines and to reap the benefits of "agile".
They can have as many deadlines and quarterly waterfall planning meetings as they want but it's their product which will suffer.
thecastellan1115@reddit
Shrugs in government IT
Everyone has a budget, everyone has a time to product, everyone has stakeholders, everyone has commitments. No one does pure Agile. Devs want to code. Managers have other priorities that must be met.
The bigger your org, the more all these things matter. If you've got a company small enough that you can co-locate everyone in one room every day, bureaucracy doesn't matter. The moment you expand much larger than that, it does. After that, you simply pick when you want to sit on the efficiency vs accountability spectrum.
MoreRespectForQA@reddit
No, that's not true. Some people do. It takes an unusual set of circumstances and they usually dont last forever but the results are fucking impressive.
Obviously it'll never happen in government IT and that is clearly reflected in the abysmal quality of government IT.
thecastellan1115@reddit
Shrugs again in government IT
Government IT is exactly the same as lot of other IT. I'd put my teams' products up against SalesForce or Microsoft in terms of quality any day of the week. I will die on this hill (granted: that's a low bar).
What people get wrong about government IT is the idea that government IT should be "innovative." It should not. That's what the private sector is for. Our job is to build shit that will work now, tomorrow, and ten years from now. So we are not leading the pack, generally, and no reasonable person ought to want us to. Otherwise we're likely wasting your tax dollars.
Regardless, the point here is that, especially in government, but also in any sufficiently large organization, you're not coding to have fun. You're coding to build and deploy a product.
That product presumably has a rollout timeline, even if that timeline is as vague as "sometime before the hardware it's designed for becomes obsolete," or "before the company goes bankrupt," because presumably someone needs and/or wants it. And if you have a timeline, the best you can generally do is iterative dev.
If it takes an unusual set of circumstances to do pure Agile, then pure Agile shouldn't be the aspiration of every organization. I said what I said.
MoreRespectForQA@reddit
Except shoddier and more prone to cost and schedule overruns.
Oh wow, you think you can go toe to toe with Github's 89% uptime promise? And produce a product people love almost as much as Teams?
No, the point is that when you deluge teams with deadlines and bureaucracy they produce dreck and slowly.
That it also isnt fun is beside the point.
You might have managed to convince yourself that it isnt possible to do any better and probably you havent experienced better and certainly you cant imagine better but trust me, it is.
thecastellan1115@reddit
Ok. At the end of the day, I have a budget I have to stay inside and a set of products I have to produce. You have fun, now.
MoreRespectForQA@reddit
I know. Ive worked in government IT. It could be profitable, but rarely fun and never productive.
thecastellan1115@reddit
Are we prepared to at least entertain the remote possibility that, as with any other industry, different orgs may have different standards, SOP, and outcomes?
Like, I wouldn't want to work for IRS.
MoreRespectForQA@reddit
Im explaining how those different standards, SOPs and norms have an effect on software quality and delivery speed.
Organizations can have it high quality and quick. They can have deadlines and bureaucracy. They cannot, however, have both.
thecastellan1115@reddit
No, you're asserting. But that's ok.
On your last sentence, at least, we are in agreement. One cannot have it all.
onafoggynight@reddit
So, just establish deadlines for things. Just as you need to control budget and comms. You do not need scrum or sprints for that.
thecastellan1115@reddit
No kidding.
ninetofivedev@reddit (OP)
Nobody is saying that.
thecastellan1115@reddit
The "just use Kanban" crowd often does, whether they realize it or not.
taelor@reddit
How does kanban prevent biz ops from doing any of those things?
thecastellan1115@reddit
Kanban doesn't. People who use Kanban to try to justify not working to timetables do.
onafoggynight@reddit
Your roadmap(s) needs to be much longer than sprints anyway. So, 2 week sprints do not buy you anything. If you need to pivot every two weeks, you have a business problem, not something that can be fixed at the operational / dev level.
And sprints also do not give you project planning / milestones for that matter. Scrum is not holistic project management.
Antique-Stand-4920@reddit
When I took an Agile training many years ago, they actually mentioned the concept of the Horizon of predictability.
Ok-Host2005@reddit
We’re doing quarterly “increments” because of reasons and we need to be 80% confident of delivering everything we commit to in the increment which means we have to start designing things in the previous increment.
Majestic-Mustang@reddit
I’m on board with this.
SebastianSolidwork@reddit
Scrum is attractive for (some, many) managers because by the faulty calculated velocity they can easily judges teams success without needing to go into what actually was developed. Just judge by the numbers. It's about team control.
One way or the other fixed X weeks release cycles aren't reality at many places.
Hot-Profession4091@reddit
I came to similar conclusions a long time ago. We decided to do the opposite. Keep shrinking sprints until they just disappear.
mechkbfan@reddit
Fundamentally this just comes back to one of the main purposes of agile/scrum
How do you shorten the feedback cycle and learn from it?
I can't remember if it's still used as an analogy but it's like an air con system
If you're measuring only once a day, then more than likely you're air cons going to be way too hot or cold
On the other hand, if you're measuring every 100ms, predicting 100ms ahead, then adjusting that's (possibly) a lot of wasted energy. I say possibly because I feel this is almost what mob programming encourages where everyone is in the room together whether they're relevant or not.
At some point you find the sweet spot but key thing is getting that feedback loop as early as what works for the business
Val0xx@reddit
Wait, you guys get to do feedback and aren't just reprimanded for not getting everything done that was dumped on you during the "sprint"?
Hot-Profession4091@reddit
The sweet spot seems to be plan together each morning, deploy continuously, release often (and actually measure the impact), retrospect on demand.
mechkbfan@reddit
From a purely tech company POV, I could agree. But those situations are so limited these days.
So the main issue to me with that always comes to how you integrate with the business
Finance team want projects with allocated budgets for CapEx/OpEx, etc. and deadlines for financial years, or quarterly results.
Marketing team want deadlines to run campaigns, etc.
Also software delivery may not actually be the most important part of the business with regards to finances and risk. e.g. If the guy in charge of logistics messes up, it might cost the business $100k+/day and loss of customers. They're not going to prioritse the IT delivery pipeline, or add all these ceremonies to it. e.g. You waste a week of dev's team time and it might set you back $20k but no customers are impacted.
Hot-Profession4091@reddit
Nothing about ditching sprints is incompatible with business or limited to pure tech companies.
I’ve done this at a manufacturing company. You’re making exudes for yourself instead of finding solutions to problems you face.
mechkbfan@reddit
If the business wants scoped projects, then that's what they're going to get. No amount of whinging of "scrum is bad" is going to get them to change their mind. After that point you're essentially doing mini waterfall / scrum but just not calling it that.
Once again, I'd prefer a daily deployment but that's not the world I live in.
Jeez, relax hey.
I solve problems that I'm paid to solve. I'm not burning myself on superfluous stuff.
ninetofivedev@reddit (OP)
Problem is that leads to more frequent ceremonies that don't provide value.
Now we could drop the ceremonies but sometimes we do want them. Just not every week and not every 2 weeks.
"So just adapt your process to what works for you!"... If that is the conclusion you've come to, know that we agree and you're not understanding my point.
Hot-Profession4091@reddit
The ceremonies get proportionally shorter and when the sprint disappears, you’re just culturally performing those things continuously.
ben_bliksem@reddit
You're not my dad!
Besides, we do whatever works for the team with these sets of people/personalities. Some need rigid sprints, others need kanban - a good team figures out what a good balance for them and a good company allows them that freedom.
The biggest problem in most companies is that everybody is treated like robots and have to do things the sane way. You want teams to output with maximum ROI and yet some insist of forcing jan-van-gent, scrum or god-forbid SAFe down everybody's throat.
LittleLordFuckleroy1@reddit
Lots of places use Kanban and just call it Agile. It’s a natural planning mechanism. You also can’t get away from estimating projects and committing to deadlines. Yes, priorities shift and unexpected things happen, but in a business environment it is usually a necessity that management knows roughly what to expect.
Anyone who does strict Agile usually comes away with your opinion imo, and that’s how most places end up relaxing back into Kanban. It takes a senior/lead dev speaking up about it.
Fair warning: going to Kanban doesn’t solve everything. Planning sucks, but it’s important. And it often requires regular checkpoints to work properly. Don’t call them ceremonies if you don’t want to.
Jazzy_Josh@reddit
My brother in Christ if that is your thesis, then lead with the thesis.
(100% this is the correct perception but say this instead of ragebaiting people)
LousyGardener@reddit
Agile only works for teams of low performing devs with little to no creative control. If your devs are capable, self motivated, and can make decisions then agile just gets in their way
james__jam@reddit
That’s literally not agile. But i get it. Most people here were introduced to the bastardized way of doing agile.
Agile was truly beautiful before it became mainstream and we started certifying scrum masters who have zero experience and zero understanding for $1k with zero failing rate.
LousyGardener@reddit
I agree -- the world was better before PMs and standups and jira.
I think "literally agile" is what is practiced by modern software orgs. It's not really helpful to talk about a 25 year old manifesto that could have been.
The original manifesto missed a lot. One thing I've seen that is rarely discussed is the checked-out stakeholder. I've seen plent a stakeholder snooze through weekly reviews only to blow up about some feature that was brought up to them explicitely and is now baked in. I've seen PMs literally fight against architecture decisions that would have prevented said feature from being baked in and thus nearly impossible to remove without serious redesign.
The whole thing needs to be rewritten (pun intended)
TenchiSaWaDa@reddit
Kanban is useful for operations as well. But there also needs to be very clear milestones for when things need to get done
james__jam@reddit
Kanban is for operations
Business-Row-478@reddit
Kanban can have deadlines and higher priority on certain tasks, so sprints really don’t benefit there.
prschorn@reddit
sprints are a delusion in most part, you add so many meetings and rituals to the work day that you end up having less performance overall.
james__jam@reddit
Curious, what kind of rituals eat up your time?
A typical sprint nowadays is 2 weeks long.
Total recurring meetings for an IC should be less than 7%. Add in adhoc meetings, then you should be at <20%.
james__jam@reddit
This is why i question this sub so much. How come “experienced” devs here have practically zero stakeholder management skills?
You should f*cking know!!
HiSimpy@reddit
If sprint structure no longer reflects how work moves, teams should stop pretending it does. Keep the planning cadence only if it improves owner clarity and blocker visibility; otherwise it becomes reporting theater. Tie updates to shipped changes and explicit decisions, not ritual attendance.
grizzlybair2@reddit
Yea we did kanban for years and I never knew the name of it. Felt so much better. New company I went to does 2 week sprints and it's basically hell making sure we have more than 2 sprints of half assed stories. And it's still so important to hit the deadline and get you cant tell me what we are working on after this project.
akash227@reddit
Potentially dumb question but if you release multiple times a day how do you get product owner buy in/ sign off?
ninetofivedev@reddit (OP)
Everything can be turned off and on without code changes.
Perfect-Campaign9551@reddit
I don't see why kanban should give heartburn. Your can easily say "we want to release the next version of our product and here are the features we think we can build". Then just work through them with kanban. It's more a time box than a prediction. I think it guarantees you'll release at least. Your can just cut stuff that isn't done yet
sleepesteve@reddit
Dropped sprints for kanban a couple years back and never looked back. Minimized meetings. One 30-45min weekly refinement/prioritization session is enough and as a Global team cross over hours are best spent on other things. 3 standup meetings a week The rest of the updates are async.
My team rocks, trust and productivity at an all time high and we get our shit done. It's so nice to not spend energy arguing about processes and We can drop what we're doing and work on that urgent thing without spending hours doing jira gymnastics each week
Sprints are fine if you need to deliver incremental project progress to unblock other teams for large projects but you have to have a scrum/project manager keeping it moving.
Isogash@reddit
We tried switching from Kanban to sprints, and it mostly hasn't worked as it gives us more planning overhead and less convenient timings without actually helping with delivery.
JohnnyDread@reddit
I've been doing this since long before Agile was a thing and I was an early proponent of it, I'm a consultant now (not an "Agile" consultant btw) and one of the biggest/most common mistake I see teams making is using Agile (Scrum) because "that what you do" without really having the people, infrastructure or commitment to actually realize value from it. They go through the motions and some of the ceremonies of Scrum while giving lip service to story development, sprint planning and meaningful retrospectives. As a result work slips from sprint to sprint and the team never really establishes any consistently measurable velocity.
Unless your group/company has a dedicated Scum Master or someone who can truly fill that role, just use Kanban. Otherwise, the overhead of Scrum is a just a waste of time.
apartment-seeker@reddit
Not really, me and my coworkers dislike Kanban and like sprints shrug
TheOnceAndFutureDoug@reddit
The only reason I like sprints is it makes it harder for someone to come in and go, "I have an idea, we need to be doing this..." Locking down the sprint means it can go into a future sprint but the current one is already in progress so we're finishing that work before we pick up your additional work.
That's kinda it. The rest I don't care about.
Terrible-Lab-7428@reddit
Yeah but you need retros or something so your team still has a safe space to bring up constructive criticism and improve the team workflow. Sprints make it easy for managers to squeeze in x amount of beureucratic meeting time which is a waste of time but also useful sometimes.
With kanban, that tends to get forgotten or made obsolete. Then it’s just everybody complain to the manager or each other which may or may not fix anything.
skidmark_zuckerberg@reddit
Every job I’ve worked at that had sprint cycles were really just doing waterfall.
ZukowskiHardware@reddit
I’ve noticed they really just want “I’ll get this done by Q1 and this done by Q2 etc”
rco8786@reddit
We've been doing a version of Shape Up at my company (small startup, 10 engineers) and I've been really enjoying it. It still looks like alternative planning and building ("sprint") cycles in many ways. But importantly, the engineers are actively involved in scoping and shaping, and help determine what can reasonably get done to move the needle in the build.
pm_me_your_smth@reddit
Could you give a tldr of this approach and how does it differ on a high level?
EkoChamberKryptonite@reddit
Or and hear me out- Use whatever works for you, and the context of your organisation. Stop prescribing an axiomatic paradigm based on your anecdote. There's no one-size-fits-all solution to delivery. If it's Scrum, Kanban, XP, ShapeUp, a hybrid of all of that or even Waterfall, use it as long as it helps you deliver robust, maintainable technical solutions that meets the need of the business in their expected, reasonable timeframe.
All this and your previous post is shaping out to be is arguing ad infinitum over which way to hammer in a nail when we're trying to build a house.
ninetofivedev@reddit (OP)
We're saying the same thing.
EkoChamberKryptonite@reddit
We aren't. You're advocating here and advocated in the previous post that people change their delivery paradigms to a different one. I'm saying let people use whatever works for them. Don't prescribe that they consider this or that. They'd do that if necessary.
ninetofivedev@reddit (OP)
No we’re actually saying the same things.
EkoChamberKryptonite@reddit
This is the simple indicator that shows we're not saying the same thing.
Some-Expression-5793@reddit
how do you handle management's concerns about losing clear start and end dates with kanban?
MaximusDM22@reddit
The way I see it is that these frameworks are meant to add a baseline and a sense of stability. It isnt meant to maximize productivity. It is a framework that can be applied to teams to get consistent output. Now if youre in a competent team or have very clearly defined work then you can squeeze out more performance by adjusting how you work, but that comes along with risk and overhead. Easier to just work in a stable framework that fits neatly into business processes.
FoolHooligan@reddit
thanks i'll tell my manager this again and they'll ignore me again
ninetofivedev@reddit (OP)
Ha... Fair enough.
sovietbacon@reddit
Multiple times I've been effective by reducing the duration of sprints. Without deadline pressure, tasks start to take longer. Forcing tasks to be broken up into 2wk or, ideally smaller, chunks leads to the tasks being much more clear and defined. With many small and defined tasks, you can start to do benifit from the law of large numbers and have reasonable statistic-based estimates for larger releases. You can also more easily measure the impact of process changes. I saw another commenter state that they shortened sprints until they disappeared, and I find that to be a good goal.
engineered_academic@reddit
You can disagree with OP's posts, but anyone calling anyone else an idiot gets time in the box for violating the "Don't be a jerk" rule.
stellar_opossum@reddit
I worked in a team that did this for a few years. It was a bliss. We'd have a feature plan presented by the product manager, plan it and give it a rough time estimation (small/mid/large or in weeks/month). Then we would just go and work on it. We'd have periodic refinements and retros but not really sprints. Periodically we'd review and update our estimations and reorder stuff as needed.
Keep in mind that:
- it was a rather large b2b app so we rarely had small features without a crap ton of moving parts
- we'd really care about quality, reducing tech debt etc
- it was a team of really strong engineers that didn't need any external motivation or even much management at all in order to get things done
- adding to the previous point the feature was planned and broken into tickets by the engineers based on management release plans
- the company was doing really well and had moneys
Honestly I miss it a lot, life as an engineer was so so much simpler than in an agile meatgrinder. Like idc if it was agile kanban or smth else, we'd just get shit done in the best way possible. I've worked in a few other, more traditionally "agile" projects since then and I seriously disliked it. I have a feeling many problems that agile is solving are not supposed to appear in the first place, and additionally it creates some more problems and limitations for seemingly no reason. E.g. setting sprint goals produces additional pressure on the team (more or less depending on the management) which can lead to cut corners, etc.
On another hand I realize stars don't always align this way, so agile is like democracy - the worst system except all other one.
light_fissure@reddit
Does your release schedule involve in a very ritualistic CAB meeting?
Low_Entertainer2372@reddit
its the people who stare at excels and jerk off when a number goes down that you should be talking to, not us
gamesterdude@reddit
The reality is people benefit from deadlines. Sprints help timebox smaller units of work and ensure teams are delivering working software and not spinning their wheels for too long.
Too often do I see teams switch to kanban and their velocity drops significantly as they waste time gold plating features or interventions don't happen in a timely manner.
Otherwise_Source_842@reddit
I tried and failed to make my team kanban based with minimal ceremonies. It broke my PMs brain to the point he cussed me, my manager, and my director out after assigning random arbitrary due dates on all the work
rcls0053@reddit
Teams should find the best ways to work, not try to shoe horn a specific method into it because someone said it's agile.
phoenix823@reddit
This is because most teams want to drop process and tools AND ignore the individuals who need interaction from outside of the team. This whole post reeks of "let us stay in our corner with our code and leave us alone." That does not work.
Infamous-Employ5487@reddit
This is just ignorant to me lol. Kanban is miserable, people just write random thoughts in Jira tickets and expect me to know wtf they were talking about.
Benefit of a sprints is a structure process for accepting or rejecting work, as well as regular reflection (retros) on what could be improved in the process.
dbxp@reddit
We're done that and it seems to work. Initially we did it by accident as AI pushed us to deliver with such velocity and with so much change to the plans that we just gave up with the whole planning thing as it couldn't keep up. More recently its been a a conscious choice.
However we do keep some of the ceremonies, we still do retros the same way and on the same cadence as before, same with reviews to present to other stakeholders.
TBH it's not really devs which are the opposition to using kanban, its usually other roles which demand predictability.
GronklyTheSnerd@reddit
The problem is, the predictability they want isn’t real, and the stuff they demand to try to get it doesn’t actually do what they think it does.