This is nothing but a bad strawman from start to finish.
Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.
This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.
Nobody has to like it, this is probably not the best method and maybe it's not even good. But the author misses the point completely.
It's all about how everything is implemented. I've worked in places where sprints were hard deadlines and there was no acceptable reason for missing said deadlines. We worked 12-15 hour days, including working weekends to try and meet our release schedules.
Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.
We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.
It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.
Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.
I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.
Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.
> Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.
One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop.
Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.
Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.
When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.
I love how they pay people by the hour to massively waste that time with this kind of Peter's Principle nonsense. Like that's gotta be a major bleed on the bottom line at every company which acts like this.
And because you have sprints, you create lots and lots of small tasks, then focus on them, and then team members forget the "big picture" of how everything should fit together in the end (if they were ever aware of it). And when all of those small tasks are done, you notice that the sum of all those parts is not what you set out to build initially, and you need more time to shape it into something that resembles what you wanted to have.
To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...
Well yes it does require some dedicated PMs, owners and leads. If you are a smaller operation that does not have this, sprints might not be as beneficial. But if you are working for anything at scale as a developer, sprints aren't necessarily to track every hour of your day, it is to give you a structured path of things to do without having to know every detail about the bigger picture/compromises with product/prioritization. Also as a developer it gives you leverage because you were given certain tasks for the week so when someone comes along and tries to inject "high" priority item X, something else has to give.
I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.
This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine).
Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes.
Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI.
I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.
My experience from my previous $work was that things never quite got completed. I really tried arguing for a more sprint-based approach but they didn't like what they expected to be undue overhead. I disagreed since ... well, you can't have a conversation about overhead if $thing is not even done, can you?
There are a number of fundamental pieces of Scrum that are needed so all the pieces fit together.
In the Sprint, one of the fundamental elements is having a "Sprint Goal". This allows the team to see the big picture and add/remove work during the sprint to get to that goal.
Without a clear sprint goal, then of course it's easy to loose the essence or "big picture" of what the team is trying to achieve during the sprint.
Even if they remember the big picture, the tyranny of the sprint deadlines make it impossible to take the big picture into account - whatever gets the task done faster, no matter whether or not it creates problems down the line.
You're supposed to be integrating everything and evaluating the big picture every sprint. You run into the mindless sub tasks if you don't look at the big picture, sprints or not.
I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months.
It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.
At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.
Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?
What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.
Sprints are meant to correlate with frequent releases. Yes, sprints are a bit weird when we are talking about such large horizons. That sounds like a square peg, round hole problem.
Yeah, I've tasted all of those pain points myself. At $work our app developers expect a working API with all the new routes and endpoints from day 0. We manage this, of course, since we're all adults by simply talking to each other. But... yeah.
Pretty much every rant like this is a straw man rant overfitted to the writer's worst experience of what someone called "agile" in one of their companies once.
One of these days we might even hear of an example where following "agile" actually panned out. The question is - before year of the Linux desktop or after?
In the same way that few ReST implementations are truly ReSTful, few agile implementations are truly agile.
The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile.
We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc.
We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.
Yes, sprints on paper are what you describe, but in reality, they rarely ensure deliveries or predictability, they even tend to hinder productivity as they narrow the body of work of a whole team. Think about it, after a week, what is usually the distribution of work of your team? For me, it was always very unbalanced, where people where working overtime and others (best case scenario) would be looking for some work to do.
I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team.
I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do.
If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.
I guess all will agree that every successful product is an outcome on number of iterations and to perform progressive iterations there has to be a way / tool which can be one language across the board. That's why these tools such as Sprint exists. And I am sure if you are a good manager ( a future self ), you would sure not giving yourself a suggestion of using "post-its, emails, spreadsheets, large whiteboards , hang a TV screen, pdfs" as the preferred way of managing iterations.
I’d go further, sprints are defensive for devs. Don’t bother me or tell me to do something new during a sprint. I’m doing the work I said I’d do, leave me alone until the sprint is overs.
I love it when something needs to be done to unblock a large group of testers but the dev team says “the sprint is closed. Come back in three weeks and we will consider it”. Truly Agile.
In my experience, the “predictable deliveries” delivered by agile are based on behavior changes induced by the methodology. Specifically, focusing on stable point velocity per sprint focuses the team on creating sprint plans that safely deliver. This reduces the potential accomplishments of the team - they reduce throughput and delivery to a level that can be safely accomplished every 2 weeks.
I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.
Linear.app is an example of a startup that "successfully launched using agile" and focused on "releasing features to production", while working with 2 weeks cycles (not "sprints"):
> you are forcing people to make [very] conservative estimates
My experience is that once developers make conservative estimates they are ignored because business side of things would rather prefer to imagine they'll get the system completed this decade, not when estimates show. So instead of working according to estimates everybody is crunching and cutting corners and project gets delivered in some useful form in less than a year.
This is a strange law of human groups. Only caring about negative slip. That's why everybody inflates everything to shield themselves from the backlash.
Many (most?) software projects exist in environments that demand predictability. Businesses need to be able to make promises to clients and potential customers in order to make sales and garner trust. In any remotely competitive industry these are two absolutely essential ingredients to success.
I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.
There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.
> Nothing about building software, especially innovative software is predictable.
This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.
> Why do we need predictable deliveries?
Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.
If you’re post-launch, you need predictability so that you can ship the new code often. Otherwise your HEAD might be unshippable for weeks, which would be bad from
the “written but unshipped code is a waste like excess inventory” standpoint.
Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years."
Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!
OP doesn't care about building software (innovative or otherwise). He cares about getting his quarterly bonus, which is based off of meeting deadlines, because that's what can be easily measured. Delivering a quality product is much harder to measure.
Actually it is predictable, the majority of software engineers predict it at work every day (or every 2 weeks in sprint planning).
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Predictable delivery depends on the quality and not on the form.
Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish!
If one lives on and focuses on atomic deliveries only and cares no other then I agree.
But that is rarely a product, sometimes not even a feature.
Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles.
But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.
> Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits.
From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News.
I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.
Yeah as an ex-engineer and recent product manager I was very confused how the author expected things to get done in an predictable manner of nobody knows when it'll be done. Engineers also rarely interact with the sprint process. We do sprint planning with the engineers to make sure they know exactly what they're building, how much time it'll take, and give any opinions/questions they have on the ticket. That meeting lasts for an hour (maybe less) every 2 weeks. Our daily standup is 15 mins (usually like 8-10) and the point isn't to track engineers like an overlord. It's so that if you have any blockers we can reach out to the right parties for you so the engineer can continue coding without distractions. Plus, the product manager isn't your boss to be tracking you. Your engineering manager is your boss
I also sensed this piece to be an emotional criticism to sprints, backlogs and tickets, lacking structure, evidence and logical arguments.
For instance:
> (...) they’re designed for managers who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).
I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team.
From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum.
I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.
May be a strawman, but his frustrations are real and I share his sentiment.
Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period.
I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.
Sprints are for middle management to keep projects from getting out of hand, they aren't for programmers or programmer freedom. When you understand this simple principal it all makes a lot more sense. It's really no deeper than that. All the stuff grafted on top of that as "support for" is pretty much all feel good fluff and unproven social theory.
Sprints, at their best, are interruption buffers. They provide a preset time before which, engineers shouldn't be interrupted from getting stuff done by whipsawing to new priorities.
That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.
I absolutely have to 'like' it because I have to do it. Scrum masters and Product Owners love to inflict Agile bullshit, but they do not suffer from it. They have little understanding of the process of software development and imagine themselves to be capable of 'adding value'. Agile is a failed experiment kept alive by people who have no skill other than working the work.
Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2 weeks.
Sprints and planning are useful for organizations that attach a lot of value to planning and deadlines. It creates a lot of additional work and pressure, as you say, but I can also imagine that for certain types of organizations that may be worth it (eg when doing client work on a fixed budget with strict deadlines).
Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.
I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.
In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.
That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.
Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.
Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release.
It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)
I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)
You can value planning and deadlines and still not do sprints. The key is that whoever is managing the project, whether it's a dedicated PM or just the lead dev, needs to be fully engaged with the team and understand the work that is being done. Cards (beyond a basic todo list and record of who's doing what), points, sprints, standups, backlogs all of these are symptoms of bad communication and a lack of an overall understanding of the project. Unfortunately, or fortunately if you can put it in to practice, this means that the person leading/managing the team needs to understand software development as well as the current tech and tools being used. There is a place for non-technical managers but it is outside of the software development team where they act as an interface between dev and the other departments or interests in the company.
At a past job for a while we did Kanban with the sprint as a time box and it worked really well for the constraints we were working in. When we had work with deadlines, we'd flag that work as needing to be done in the sprint time box and put it on the top of the pile. Otherwise the team just kept picking up the next item, and we'd do a single review meeting at the end of the sprint to check in and see how everyone felt and what was accomplished. It was less of a retro and more of a temperature check.
It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out.
Also all the sprint planning and retrospective took basically 30% of our time.
Agreed. The differences of opinion during estimating are another form of pressure. Programmers work differently. I might estimate a task longer than a colleague, but I might be the type of programmer who tidies up and refactors along the way, or who spends more time communicating with the team on strategy and architecture. These are hard to quantify behaviors that Jira can't effectively track, unless you're going to spend half your day _in_ Jira writing down every action every day. Don't event get me started on the effect of context switching.
Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer?
My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.
My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.
Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity.
"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.
KANBAN is good at ensuring you do not have too many themes on your plate at the same time.
Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.
Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.
If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
From my experience sprints ensure that stuff is "good enough" and pushed out the door. Like QA having idea that some icon is not aligned - but yeah it is end of the sprint close it and fix in next iteration and get to work on other thing that has priority now - not aligning some unimportant details.
So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.
Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
Yup, that was the overall vibe at my last place.
Sprints are too micro and lead to tunnel vision.
Got a lot of stuff done, but the hard tickets were always underestimated & dragged across sprints. And was it the "right stuff" to be working on to start with?
Everyone felt like we were failing even as we got a lot of stuff done.
Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.
Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.
Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.
If you do scrum properly you shouldn't have a lot of meetings for "planning and ceremonies". We follow "scrum and xp from the trenches" quite closely. We have four meetings:
- scrum planning (max 1h/week of the sprint)*
- dailies (max 15 minutes per meeting)*
- demo (we like to call it sprint review, because it's interactive, not one-sided). takes about 30 minutes
- retro (takes an hour)
*most of the times we use a lot less
So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.
Every competent agile team i've ever been on ended up with vestigial sprints / iterations. There might be a weekly rhythm to meetings, but there is a continuous flow of stories, commits, and releases. Why on earth would you do it any other way?
After working with many methodologies, I think the most important thing is: regardless of which methodology you team is using, stick to the rules and deviate as less a possible from that, otherwise after some years, nobody understands the methodology in place, and people have real issues to follow it.
I get the hate for sprints, and the bastardisation of agile. I think however, the root cause of this is the way in which our society as a whole has been modelled, in a top down manner where control is wrested from the bottom, and perceived control is given to those in between. Each of these articles that make, valid criticisms in my opinion, always makes me think of Bullshit Jobs [1][2]. Most of our lives nowadays are inundated with menial bureaucracy, and each attempt to reform it within bureaucractic systems has simply lead to the red tape being rearranged. I think this stems from our hesitancy to have more horizontal models of ogranisation.
I really like your views on this problem. Never thought about it that way. I had some experiences where what you described was perfectly illustrated. It seems to me that the agile framework allows for each level within an organization (that perceives some sort 'control') to send the responsibilities to the level above, while making the decisions for the level below. Of course there are the daily meetings where this feeling of hierarchy is mitigated since everyone is included, but at the end these meetings really just focus on implementation details of the framework; and not on decisions to make the overall product better.
I don't think hierarchies are necessarily bad, I just think that we tend to implement them in a crappy way where they become the playthings of people who are solely focused on gaming the system for their own benefit. Flat organization makes sense in small groups but that group still needs a leader who can act as the agent of the group when dealing with other groups. It's the representative democracy model which is needed when there are decisions that need to be made on scales larger than that of the group concerned. A leader can also and should act as a tie breaker and moderator when the group is divided or finds themselves unable to make a decision.
Problems arise when those leaders are unaccountable to the people that they represent, you need to have very strong customs and procedures in place that allow you to immediately recall the leader and replace them if they start acting in their own interest rather than the group's. This also requires the group to have good knowledge of what the leader is doing, transparency and a public record of the actions taken by the leader.
I don't know that 'hesitancy' is the right word. It's just fundamental that people in power use it to seek more power. Even a small initial power imbalance will eventually lead to a large intractable one. Happens at pretty much at all scales of social (political, economic, etc) interactions.
The only solution I see is to set up systems that make power accumulation more difficult coupled with a constant struggle to rebalance when it inevitably lopsided.
I could not agree more, and I think this take is one of those mental jumps that the pro-Sprint crowd hasn't made yet, but would if they adjust their mental view of how organizations are structured to see it.
My long term pet theory (like, next 10-30 years) is: we have this cohort of "kids" growing up now in an environment where there's plenty of money to be made in non-traditional independent ventures; think YouTube, Etsy, Fiverr, or even professional consulting. Not millions for everyone, but a stable living. The internet unlocked this; it just took a couple decades for it to really blossom. Synthesize that trend with the growing "r/antiwork" "end stage capitalism" "quiet quitting" mindset that many people millennial and younger hold. Then you consider declining western populations. I think there's real potential that traditionally structured top-down companies will face challenges competing for talent in the coming decades; and we'll see an increasing trend of peer-driven organizations (you can think of this like worker owned or highly unionized shops, but its less about the ownership structure and more about the power structure and incentive/responsibility culture).
(I know I'm late)
Even though your pov is very appealing, I think you are a bit optimistic on the ability of workers to unionize, in any kind of setup. I personally don't believe moving all services workers from being employees to being freelancers and independent is going to resolve the imbalance of power in between capital and labour.
Taxis and food delivery are two domains that are worse for workers now than they were before.
It works for tech workers because they can just go somewhere else in a desperate market.
I believe most content creators are by and large submitted to the market, just a different one.
On top of this mall the jobs you mentioned are not for the crowd.
> I think however, the root cause of this is the way in which our society as a whole has been modelled
Yeah, so maybe it would be better if "hackers" simply start working alongside the rest of society, and give up trying to force misplaced and awkward hippie ideals into their planning meeting, that makes their work completely incompatible with the rest of the organisation, and society?
Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress. A good manager facilitates these items. A bad manager just throws tickets on a Kanban board.
Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.
So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).
> Are sprints bullshit? Maybe some of them. But for teams to be effective, you need communication, knowledge sharing and some form of tracking progress.
The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.
A sprint, be definition, is unsustainable.
It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.
Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.
I'm with you about holding management accountable and avoiding crap management, but I think it is orthogonal to sprints. Sprints might be a solution for some teams, but I have seen them fail far more than succeed. Actually ... I've never seen them succeed.
I've seen them succeed. I think the differentiating factors were 1. everyone worked on lots of different bits of the code; there weren't bits that were "owned" by someone, and 2. the end goal was pretty obvious.
10 years into my career I'm still waiting for this mythical "good manager". It's almost as if there's some intrinsic opposition between workers and employers, hmm...
There was some research that when MBAs were hired as managers for dev teams instead of other devs, dev compensation fell. Managers and devs play a different game.
Rich Hickey has a great joke about sprints, paraphrasing:
So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon...
Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
I thought "sprint" was dumb at first, for exactly this reason, it's not a sprint if it's week after week. But over time it's just become jargonized, a term of art for me. It's just a unit of organization.
My high school mentor loved to say "beware of inconvenient fictions!".
The most boring choice would be "section", and boring might be good here.
We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".
I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".
Marathon works perfectly to show how bonkers the idea of sprinting is.
I like the idea of thinking of software development more as orienteering, if anything, it doesn't go far enough.
To deliver full-featured software in time (note I didn't say on time, but there is certainly such a thing as delivering too late) is 10% velocity and 90% dependency resolution.
I'm still looking for a tool which thinks primarily in terms of dependencies, and treats time as it is: fixed in the past and speculative in the future. I don't care if the person who put the information into the computer thinks something will take three weeks, I care very much if there are three projects which need completing before the main track can get past the third step.
Right - I can't believe how so much of the programming community got suckered into spending their entire career sprinting like mad people from one deadline to another, as if it was a good thing!
Actually marathon runners are used to regular running. You might even skip the marathon and just run regularly. No need to be a superstar, just stay fit, with a steady progress. Same for software projects. Maybe the analogy isn't that bad.
Right but really, no one actually is sprinting. Devs aren't leaving standup to type as fast as humanly possible for seven hours straight. It's jargon that just means "week".
(side note: there are no crappy teams, only crappy managers)
is patently false unless the manager also has the power to add/remove people from their team or fire people.
lol, there are crappy companies, crappy business models and crappy industries - any of these can make it hard or impossible to attract non-crappy staff/teams...
Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly follow a methodology in religious fashion. They should try different stuff until something works for them.
I think the parent is coming from a place where projects have a defined start point and a defined deliverable at the end. In that situation, they might be advocating for spiral development [1], which isn't really that different to agile. It's a bit more process-heavy maybe, but as always these things are what you make of them.
The one thing agile helped here is to take that process and make it fast.
The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a programmer looking at a 3 year old requirements doc with a thousand questions that arise during implementation but the designers who wrote the doc left the company two years ago, etc etc
Waterfall was to me inarguably worse than agile.
At least with agile people try to do requirements, prototyping and iterating in a very short period of time, so the feedback loop with customers actually works, and you actually release something on a regular basis.
> Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release.
There are a lot of comments in here that imply sprints are a necessary evil if you want predictable delivery. I call bullshit.
We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning.
We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks.
We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape.
If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases.
The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team.
There are better ways to do reliable, predictable software planning than sprints.
Readit News
Sprints are not made to help organize things, they're a tool to get more predictable deliveries. Their very short nature forces participants to construct tasks that are easier to estimate and therefore complete on time with a higher probability.
This certainly adds overhead to an idealised scenario where people take the shortest reasonble route often enough and that is the tradeoff. Plus: people actually seldomly take the optimum routes in the first place.
Nobody has to like it, this is probably not the best method and maybe it's not even good. But the author misses the point completely.
Run into a blocker? Too bad, should have seen it coming during our scrum meetings and follow-up refinements.
We engineers had two business analysts, a scrum master, and two managers that resided "above" us in rank all working to keep the "flow" of the sprints alive to help ensure we meet our deadlines.
It was the most stressful tech job/environment I've ever been part of and everything was micro-managed by said 5 people to the point that they were blockers to our progress - scheduling multiple meetings everyday that would easily consume 3-4 hours.
Our backlog would grow everyday as everyone scrambled to finish tasks and our architecture was a patch-work of systems that only one person truly understood because he had been with the company since it's inception.
I was hired as a senior engineer along with three other mid-level engineers - all three quit within four months. I left after six.
Sprints/agile/scrums are generally a good thing IF and ONLY IF you have a capable manager/scrum master leading and organizing the team who truly understands time management and finnicky nature of software development. Otherwise, it quickly falls off the rails and leads to churn and burn.
One of the things that usually happen when they push and push and push for some feature to get rolled out in the next quarter is that it often turns out to be a gigantic flop. Engineers are forced to spend hours they can't get back at the whim of management for something that was a complete and utter failure. I could imagine few things more demoralizing than this.
Agile is really meant to be about self organizing teams that take ownership of their own work and deliveries. The scrum master and product owner are just there to facilitate that.
When a team hits a blocker on a tight schedule -- particularly across third party teams, it's up to the management to figure out a solution -- even if it means gasp delaying the release by one sprint.
To avoid this scenario, it takes really dedicated project managers, product owners and lead developers, and not everyone has those...
What specifically about not using sprints would help the team if they lack good planners and people capable of seeing the big picture?
Isn't such a team screwed regardless of how they allot work?
I found before I was on the planning/lead side, it was hard when you did not have this structure. People would still shove in "small" tasks without a sprint structure and then months later it is hard to explain why a big project did not ship on time. So if done right and not abusively by oversubscribing devs, it is a great too for both sides.
This is my biggest pet-peeve on my current project. I am a solo dev on my current project at work, and for some reason, we are still choosing to use agile/scrum with sprints and all that jazz (seriously, your guess as to why is good as mine).
Regardless, one of the more difficult issues I have encountered through out my current project is the usage of proper abstraction and avoiding redundency. I seriously have little idea of anything I build will for the project will ever be used again in a different part. Since, everything is given to me in sprints, I literally have no idea what is coming down the pipes.
Any feature I implement becomes an internal debate of how much abstraction is necessary vs. YAGNI.
I've since given up on even trying. Once the project is more or less finished, I'll properly just run back through it and then properly abstract, refactor, etc.. You know -- spend more time doing something twice than properly the first time, but whatever.
I guess, I'm asking, is there something specific about agile that makes a subpar team worse?
In the Sprint, one of the fundamental elements is having a "Sprint Goal". This allows the team to see the big picture and add/remove work during the sprint to get to that goal.
Without a clear sprint goal, then of course it's easy to loose the essence or "big picture" of what the team is trying to achieve during the sprint.
Even if they remember the big picture, the tyranny of the sprint deadlines make it impossible to take the big picture into account - whatever gets the task done faster, no matter whether or not it creates problems down the line.
It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.
At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.
Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?
What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.
Unwillingness to modulate the length of a sprint is one of the strongest "cargo cult" indicators in my exposure to Agile/Scrum.
You can just ship 2 days into the next sprint if you need to. You don't have to only ship at the end.
The Agile Manifesto came into style, then predictably a cottage industry of small companies grew up around it, with the business model of charging Fortune 500s huge amounts of money to train their Engineering departments. I've sat through such training before, and I can say without doubt that the day our company took "agile training" was the day we stopped being agile.
We overlaid an efficient process with a ton of bureaucratic busy work. We came out the other side of it with an army of PMs (read: Jira configuration experts). Engineers had less time to engineer, with constant flow-interrupting meetings where they became trapped in a morass of Gantt Charts, "deliverables" spreadsheets, etc.
We had many employees for whom English was a second language, and interestingly none of those I talked to realized that "agile" was an actual word, meaning "nimble, quick, dexterous." Nothing about the new process conveyed any of those qualities. It was basically classic waterfall, with stand-up meetings thrown in. Rigid project management methodology is definitionally opposed to agility.
I understand the author's heated post, because I've been there so many times, and I think THIS IS THE POINT of this article, the point that you are missing. Good manager shouldn't rely as much on a set tools that are broken or unfit for their team.
I my opinion, not enough people question Sprints and their viability and benefits. And he's right, backlogs are by far just a list of the things you wont do.
If your tool cannot fix your issues, the manager should. Use post-its, emails, spreadsheet, large whiteboards, hang a TV screen in the room, pdf, discussions... There is endless possibilities, be creative.
Scrum even has a ceremony for fixing this: backlog refinement.
I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.
https://linear.app/method
Tell management every project will take a month, and meet that expectation, then management will be happy.
While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective.
So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estimates.
For larger companies this might be preferred, but I would argue, smaller companies should try to move faster.
My experience is that once developers make conservative estimates they are ignored because business side of things would rather prefer to imagine they'll get the system completed this decade, not when estimates show. So instead of working according to estimates everybody is crunching and cutting corners and project gets delivered in some useful form in less than a year.
"Oh, yeah, the rewrite will be done in 1yr, no worries"
One year passes, and you haven't started!
Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.
I mean, think about the software you use. Of all the shops that produce that software, which ones do you trust more than others? I'd be willing to be it's the ones that delivery predictably. At the very least the ones that deliver updates reliably - as in they do what they say.
Granted, every industry is different and some rely on trust and predictability more than others. Building an organization that is good at that is very difficult - and that cost has to come from somewhere doesn't it? In my experience it's at the cost of time spent building the product. A tradeoff between reliability and quality, if you will.
This is basically exactly the point. It's incredibly difficult to predict building 'large software'. So, lets try a few things to help make it a little bit more predictable by trying to predict smaller increments.
> Why do we need predictable deliveries?
Say I'm building a piece of software - maybe an app the audience would use - for the Superbowl. It's very handy to be able to estimate our progress to see if we'll actually land that date. The Superbowl isn't going to move because of our app, and our app isn't very useful the month after the Superbowl.
Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!
Deleted Comment
Why do we need predictable deliveries? Because if Bobby from accounting doesn't have your piece of software ready by the 31st of November the company will be slapped by a fine from the IRS so large that you'll need to update your CV alongside all your colleagues from the now bankrupt company you used to work for.
Because your organisation answers to shareholders on a quarterly basis.
Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish!
If one lives on and focuses on atomic deliveries only and cares no other then I agree.
But that is rarely a product, sometimes not even a feature.
Also complexity (symphony of small tasks) has to live somewhere and unpredictability of the big project will not go away with week based planning cycles.
But I too know better actually. : ) Except probably all the others if everything is done with suitable care and attention.
From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News.
I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.
For instance:
> (...) they’re designed for managers who don’t trust their employees (if your manager needs to look at Jira to figure out what work you’ve done for your review or what’s shipped lately then they’re not paying enough attention to the team).
I disagree. Visibility and documentation of work are important for having everyone working in a project on the same page in an efficient manner, and definitely not a sign of lack of trust on the team.
From checking the author's information I found that he's a "writer and web designer". So maybe he comes from a different background that led him to develop this pessimistic views on scrum.
I'm personally more attracted to Kanban than to Scrum, even so I can see value in Scrum when run in a disciplined manner.
Sprints et al have been a mixbag for me, but the last 7 yrs (current team) have been plain utter BS. All the ceremonies too, retros are nothing but waste, because they only serve to praise undeserved credit with no product to show for most of that time period.
I credit the OP for his courage to raise his voice to shame those/any bullshitters behind the Agile movement.
That big new product is still going to take three months to deliver, regardless of sprints, but you don't get to pull the team off working on it for some new idea until next sprint.
No, they're a tool to get the illusion of more predictable deliveries. As always, comforting lies are more welcome than harsh truths.
> ...probably not the best method and maybe it's not even good
It doesn't sound like you believe in sprints either, but can't imagine something better.
Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.
I’ve felt the opposite. My team switched from “Scrum” to “Kamban”. Then after a few months the sensation of having an endless pile of cards, without a time frame, felt overwhelming.
In the other hand, having a short lived cycle used to help me manage my time. If for any reason one day I was not able to accomplish much, I knew I still had a few more days to compensate. The same was true for the opposite, I could be really productive a few days and then I could relax for the rest of the sprint.
That workflow really worked for me. With Kanaban I feel the pressure to always be “productive”, because I don’t have a clear reference on how “relaxed” I’m (or not), during the week or month.
Maybe I just need to find a different reference. I guess my point is that sprints don’t necessarily mean pressure for everyone.
It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)
I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)
It worked really well for a team that served a lot of different stakeholders and also had to field requests from customers since the priority of the work was always changing even if the deadlines for the work didn't.
Also all the sprint planning and retrospective took basically 30% of our time.
Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.
My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.
"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
Producing effort estimates is one of the many approaches to start talking about a task, and not doing it may mean that somebody else's better idea on how to tackle it gets ignored.
Having sprints is a good way to coax people in fully finishing things, it is often needed as many developers tend to jump to the next shiny.
If any of these three things gets used by a bad manager to get fake importance, to put pressure, push people down instead of pulling them up... then get rid of that manager.
So sprints are also good way to coax people into cutting scope instead of working till it is "perfect". Then pushing back on management to have breathing space and accepting changes only after sprint ends and not when they have a brilliant idea.
Sprints and ceremonies create touch points for business people to interact with dev team instead of constantly breathing on their neck or coming up with ideas. Business using JIRA and writing stories/tickets should make sure there is enough context in these so your tickets are living documentation "who,why,where".
It's just a 5 letter word, it's not that difficult.
Additionally, despite the attempt at predictability, wider project management was lacking, which lead to cross-team long running projects running over by 100-200%.
Often this was failure to capture actual requirements, making generous assumptions that a vendor would provide a magic bullet, allocating little to know time for integration / cross team work, etc.
Each team worked on the tickets in their sprint, from their backlog, according to what product management wanted. The fact that none of it tied together at the end was not devs fault if you want to institute such a tunnel vision process on them.
Teach the developers who estimate them to treat the process as the circle circumvent instead of the diameter and multiple by Pi. There you go - done.
*most of the times we use a lot less
So we have 2h of meetings in the first weeks, 2.5h of meetings in the second week if you do a two-week sprint as we do. the rest of the meetings is rather "working together" than having "meetings". If you have much more hours in meetings than this (which can be attributed to scrum) you're simply doing it wrong.
Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.
This is a weird take.
https://news.ycombinator.com/item?id=17154355
[1] - https://theanarchistlibrary.org/library/david-graeber-on-the...
[2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...
Problems arise when those leaders are unaccountable to the people that they represent, you need to have very strong customs and procedures in place that allow you to immediately recall the leader and replace them if they start acting in their own interest rather than the group's. This also requires the group to have good knowledge of what the leader is doing, transparency and a public record of the actions taken by the leader.
The only solution I see is to set up systems that make power accumulation more difficult coupled with a constant struggle to rebalance when it inevitably lopsided.
My long term pet theory (like, next 10-30 years) is: we have this cohort of "kids" growing up now in an environment where there's plenty of money to be made in non-traditional independent ventures; think YouTube, Etsy, Fiverr, or even professional consulting. Not millions for everyone, but a stable living. The internet unlocked this; it just took a couple decades for it to really blossom. Synthesize that trend with the growing "r/antiwork" "end stage capitalism" "quiet quitting" mindset that many people millennial and younger hold. Then you consider declining western populations. I think there's real potential that traditionally structured top-down companies will face challenges competing for talent in the coming decades; and we'll see an increasing trend of peer-driven organizations (you can think of this like worker owned or highly unionized shops, but its less about the ownership structure and more about the power structure and incentive/responsibility culture).
Taxis and food delivery are two domains that are worse for workers now than they were before.
It works for tech workers because they can just go somewhere else in a desperate market.
I believe most content creators are by and large submitted to the market, just a different one.
On top of this mall the jobs you mentioned are not for the crowd.
Yeah, so maybe it would be better if "hackers" simply start working alongside the rest of society, and give up trying to force misplaced and awkward hippie ideals into their planning meeting, that makes their work completely incompatible with the rest of the organisation, and society?
Sure, if you have a team that can do all the above without sprints, that's great. But I bet they have some other method or social structure that makes team management effective. Most software teams do not have that without some type of formalized structure, especially when new devs rotate into the team.
So, I say stop criticizing the concept of a sprint and start holding your manager accountable for proper communication, effective knowledge sharing and realistic issue tracking. You wouldn't accept crap code, don't accept crap management. Do this and your sprints will add value (and the meeting will be shorter too!).
The real problem, of course, is the word "sprint", which (whether you like it or not) implies something.
A sprint, be definition, is unsustainable.
It's Pythonic levels of hilarity that we adopted this word to describe software development. It's Shakepearean in the tragedy that so many defend it.
Choose another word, like, "jog", "amble" or similar, and you won't see the same level of backlash against it.
So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon...
Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
The most boring choice would be "section", and boring might be good here.
We could borrow from military strategy, not for the first time, and call it a "maneuver". More sporty, and pointing to the repeating nature, would be "round".
I wish the word "sprint" could be used for "this will call for an unsustainable amount of effort. we will be calling in dinner a few times. this isn't normal, and can't be normal, and everyone gets to rest after, but it's something we have to do".
Instead it's just a way of saying two weeks.
Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering
I like the idea of thinking of software development more as orienteering, if anything, it doesn't go far enough.
To deliver full-featured software in time (note I didn't say on time, but there is certainly such a thing as delivering too late) is 10% velocity and 90% dependency resolution.
I'm still looking for a tool which thinks primarily in terms of dependencies, and treats time as it is: fixed in the past and speculative in the future. I don't care if the person who put the information into the computer thinks something will take three weeks, I care very much if there are three projects which need completing before the main track can get past the third step.
(Sorry, I'm a bit grumpy.)
From what I have experienced, I think that is perfectly reflected in a lot of software too.
Many folks may be unproductive with one management style yet thrive in another.
Assuming you don't stop there and keep doing those things, I don't see why you don't like agile.
[1] https://en.wikipedia.org/wiki/Spiral_model
The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a programmer looking at a 3 year old requirements doc with a thousand questions that arise during implementation but the designers who wrote the doc left the company two years ago, etc etc
Waterfall was to me inarguably worse than agile.
At least with agile people try to do requirements, prototyping and iterating in a very short period of time, so the feedback loop with customers actually works, and you actually release something on a regular basis.
Deleted Comment
That is agile for me. What is agile for you then?
Anyway, Agile has that one principle that is focusing on people, not process... You can make any process agile.
We don't do sprints. We don't do Scrum. We don't do story points. We have predictable, reliable software delivery on multiple products with an ever growing product development team of 65 people. It's all about measurement and mindful planning.
We are strict about structuring epics vs. stories vs. tasks, and make the largest deliverable an epic. Epics set the scope of what we want to achieve. Then we describe user behaviors / experience we want to enable in terms of stories. The engineering, deployment, and design activities needed to enable those behaviors / UX are structured as tasks.
We say when we want to be done with the epic and try to determine if the scope we have outlined for the epic is reasonable given the self-imposed deadline. Then we measure the growth of tasks in epics week to week. Tasks are expected to grow fast in the first 20% of a project and then start to taper off as more and more of the engineering takes shape.
If we're not following that curve, we hold a retro. If we add stories or change the scope of the epic, we hold a retro. We adjust scope downwards or we change the estimate. We communicate the changes to estimates out to customer-facing teams early in these cases.
The last large-scope new feature we built on our product was scheduled to take 4 months. They were behind by less than 2 weeks, and half the team were rookies. Oh, and no-one was asked to burn the candle at both ends to get us there. No saturdays. No 10pm conference calls between engineering managers and the dev team.
There are better ways to do reliable, predictable software planning than sprints.