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.
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.
[1] - https://theanarchistlibrary.org/library/david-graeber-on-the...
[2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...
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!).
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.
(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.
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.
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.
Eh. If you get ahold of a bucket of true geniuses, best thing you can do is not even give them goals and just feed them until Nobel prize/Manhattan Project level work surfaces. As you go down the scale, crisper and crisper goals are needed. This isn't an absolute either; I've been both the smartest man in the room, bogged down by scrum poker and similar inanities, on the one hand, and (elsewhere) someone with a vague understanding of the work needing some supervision to even add value to the team.
I agree with the title, but the article fails to deliver on the essence - saying "points are bureaucracy, backlog is bureaucracy" does not really say what is the problem, it does not explain what's an alternative to backlog that helps to solve the same problem (visibility of the work to be done, predictability, etc.)
For me the biggest problem with sprints is that they force a continuous flow into discrete boxes. An extreme example I've seen was when as a mid-level developer I was told not to pick up any new tasks, because everything we start needs to be finished by the end of the sprint, and if I start a new task now, testers won't be able to complete it before the end of the sprint.
Of course it was an abuse of the concept, but I hope you see the point - we shouldn't try to start every sprint with an empty board, because software development is continuous, and the fear of tasks "spilling" to next sprint, which I've seen multiple times, is just ridiculous.
I don't want to be rude; but this essay really isn't useful. It's a rant.
To the author:
You don't like sprints or backlogs? Okay. So what's the alternative?
Take step back, think about the problem that agile tries to provide solutions for. Now start thinking about new solutions .. spend some time; then write an essay that makes a difference.
Worked in many teams and company sizes. I prefer Kanban to scrum hands down. My hot take is that Sprints are a good tool for an incompetent manager who cannot exert pressure or plan work without a fixed structure.
I don't care what anyone believes in, I respect your perspective. I think sprints and modern agile practices are an anti-pattern as practiced today especially in big tech. I've seen very few teams who operate like a well oiled machine using them though.
What is important however is some type of shared vision or general plan. Not all teams are lucky enough to even have that. Some people treat their job as a job. Some people treat their job as their life's mission. Much of this definition gets lost in translation in the middle.
In theory a team full of product-minded engineers / self-managing individuals don't need much to be impactful because they will know where to add value and make progress while being looped into the industry/customers.
(Sigh) This is just a religious pronouncement in a religious war. There are many processes out there - not just sprint, kanban, water fall, or "no process". Pick the process that works for your team.
As an engineer and an engineering manager I have worked in strictly controlled water fall, "no process", well structured sprints, kanban, and scrumban. They all have their pros and their cons, their costs and their benefits. It's a question of what works for the team.
Personally, I developed a preference for scrum style sprints as both an engineer and as a manager, because I prefer to work collaboratively where everyone knows what everyone else is working on and everyone gets a chance to have a say. Sprints with a heavy planning component work very well for that. But that's just my preference.
Teams should decide what method they're going to use and commit to making it work. They should also be open to recognizing when it isn't working for one reason or another and be willing to try something different occasionally.
The only piece of process I will always insist on is some sort of regular check in where we can introspect about the process and determine what aspects of it are and aren't working.
Agree mostly. Jira is a nightmare. Sprints are pointless.
But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.
I loved working in sprints. My last two jobs have used the term, but not the ceremonies, and it's not unusual for tickets to be quietly moved from sprint to sprint while in progress.
Without agile ceremonies, the quality of tickets can really vary depending on who is writing them. I think there's something to be said for a group of devs looking at a task and deciding if there is a clear AC and discussing how difficult that task is. Without these sorts of ceremonies you can get into situations where you work at a task for days, put the PR up and then get told "Oh we probably shouldn't do this". This has happened to me multiple times at my current and last job.
I also think that for certain types of people, the model of committing to a certain number of tickets for a certain block of time makes it easier to structure and plan that time. Certainly it does for me.
Oh my god! No, no, no, the author does not understand the purpose of sprints.
Assuming the originator of the concept of a sprint is Scrum (and it's a big assumption; normally I'd check, but I am lazy and somebody is clearly wrong on the internet), then the purposes of sprints are:
- to set a regular cadence/rhythm to work, and to set up periodic checkpoints for inspection of the done product and adaptation of the work that follows
- within a sprint, to produce a done increment that brings the team closer to the product
- by the end of the sprint, to allow stakeholders to inspect the done increment, to observe if anything is being done wrong or in the wrong order, to collect the feedback, and adjust, if necessary, the plans against the reality
- and then to repeat the same over the next iteration, and the next, and the nextSprints are like cogs. They enable teams to organise dependent tasks. If you're happy to just say "We'll write the code for this when the designs are done, and we'll finish the designs when the requirements are agreed" then you don't need sprints. If you want to say to people "We'll have this done in 6 weeks" then you need to have 'slots' where you can organise when the work is done. Those are sprints.
Sprints really help at our place. We have a lot of different priorities and themes. Stakeholders have a variety of requirements, and cross team projects need to be aligned in time somehow.
This is all hard to do IMO if there's one running backlog.
The benefits of sprints I see is they're a useful time container for planning purposes. Eg:
- we can allocate larger pieces of work to upcoming sprints. This is done very loosely just to get some idea of what we can take on, and when
- we can allocate a fraction of each sprint to tech debt or platform improvements etc
- set a goal for each sprint which is some observable step forward. This has taken practice to break down the work into appropriate chunks which can be verified done
- record velocity across sprints just so we have a rough idea of what we can get done in a sprint (it will vary of course)
Yes, there is overhead from the planning meetings. But this helps all of us get involved with incoming work, which I think is better than tasks coming from nowhere without context.
I think the right methodology depends on the context of the business. If product teams need to work together towards something, or if there are competing project priorities, then sprints can help protect focus and provide finer structure than just "Q4".
I believe in having QA as part of your software team. While developers need to own the quality of what they're shipping, a good QA person bridges the gap between engineering and product, and serves as a gating function for what gets shipped. You can't automate testing of everything, although certainly you need automatic testing where it is required or pragmatic. Blue/green is great, but when you're relatively small then avoiding any users having a shitty experience is a reasonable goal.
Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)
I tend to agree (prefer Kanban myself), but the article is full of assertions going in circles, without any claims to back them up.
The only thing that comes close is "every efficient and productive team I’ve worked on has ignored the concept of sprints altogether".
Okay, but why don't do scrum meetings, pointing, retros, or keeping Jira up to date, work. There's nothing in the article to address that.
Sprints are a good tool to transform bad teams into better teams. No amount of process and tools is going to convert a good team into being a great one.
Great teams do not need additional processes to deliver value and they usually are more of an obstacle. Clear goals and a vision are much more important, as well as having an environment where the decision makers are the one implementing the solution.
I've been bemused watching the rise of agile over the last (10?) years since my background is in building software for large/multinational non-tech companies. They have VPs and accounting departments with budgets and they want to know exactly how much they're spending before they spend the first dollar. Whether or not they should, they don't see the uncertainties in estimating software development as their problem.
My solution to this is waterfall, and charging for a rigorous requirements analysis process up front, which I, in turn, estimate the cost of by having the client submit their requirements (as they know them so far) in detail in writing up front.
I've been surprised in (the practical version of) agile how often time is wasted revising the same feature 5x that could have been done once if a modicum of time and thought was put into business and technical requirements.
I am however a believer that people do things for a reason, it does probably have advantages for R&D or inside technical product companies.
Sprints when used correctly are invaluable to a development team. Source: My own experience as a junior dev and a lead dev on teams working in this methodology.
Note it's not useful in all (most?) scenarios or in all stages of a product's development.
When you are in support mode for a product that's stable, standing up something from scratch, working on a POC or experimenting with frameworks or libraries - it's not useful, use kanban or something else.
But when you are working on a/b tests or adding features to an existing product it's extremely useful.
When done correctly: You get a two-way promise between leadership and a dev team. The dev team commits to getting stuff done within that <sprint-length> time - therefore they must carefully decompose work where that makes sense. Leadership commits to LEAVING THE DEV TEAM ALONE for that <sprint-length> time - no priority changes, no "Product Manager Chad had a dream if we implement X we get 1000% more revenue!", none of that nonsense. This means for bigger efforts, you get <sprint-length> chunks of working code "done" at time. This in practice means the devs drive how much they can get done in a certain amount of time - if a PM wants an earlier date out the door, that's <x> fewer sprints of decomposed work that gets done.
The tricky thing here is the use of the term "correctly" above. Sprint-based methodology isn't a tool for management to dictate or predict performance and it's not a tool to micromanage tasking. If leadership DOES have this distorted view of it, then it is useless overhead to no benefit for anybody.
It's also not useful at all if only the dev teams practice it - everybody has to respect the commitments required to do sprint correctly - if they don't, use kanban or something else.
> side note: there are no crappy teams, only crappy managers
I disagree. There are, in fact, crappy teams. You might argue that it's a crappy manager that either allows that team to continue in its current form, or simply doesn't recognize that the team is crappy, and does nothing, but... there are crappy teams. There are combinations of personalities and skills that are simply not suited to solving the problem at hand, and nothing short of removing actual people and replacing them with different people will 'fix' anything. Again, you can say that's down to management, but it feels like a word game. The team itself is 'crappy' for the goals at hand - management/owners (crappy or not) need to recognize and fix that.
My team switched from Scrumban to full Kanban last month, and it's the best thing we ever did. Everything just feels so much more natural and fluid now that we don't have sprints anymore.
FWIW, Scrumban wasn't bad either, and it was way better for us than full Scrum would have been. The reason we switched was because we were basically operating like a Kanban team already, and the sprints were just arbitrary lines in the sand. We regularly had either a) tickets crossing over into multiple sprints or b) sprints we cleared out so fast that we had to start pulling tickets from the next one into the current one. And even after the switch to full Kanban we've kept the few Scrummy stuff that we like, such as biweekly retros.
Disagree. In one of the companies I worked for. Management decided to adopt safe agile. We had a dedicated agile coach for the whole department. Each team went to learn the safe agile principles and framework. The main focus was how do three teams get more aligned when building a solution: edge software, cloud software, application layer. I can say after 3 months of sprints. The productivity improved, people were happier and now we know which feature is used by whom. The requirements were forced to become clear so it be translated into designs and then dev work with the definition of done. When properly applied with the right intentions it is transformative.
I've done waterfall, I've done Agile and I've done a couple of forms of "let the devs do whatever they want because they're really smart and only managers are crappy"
I rank them as 1) Agile 2) Waterfall 3) Whatever it is this guy wants.
Personally, I also dislike sprints. I much prefer a kanban approach with just a big, prioritized to-do list, where devs just pick the top ticket and do that. Preferably a tech lead prioritizes the list together with the PM.
But to be fair, I've worked like this mostly in places that have also enjoyed a continuous deployment way of working, with possibly multiple releases per day. In other places I can kinda see the point for "this is the stuff that needs to go into the next release" kind of sprints, but even then I'm not sure it's an improvement over straight up kanban.
I kinda feel like Ockham's razor would cut the sprint from the ideal work method tbh.
Even just the language we use to describe it all is depressing isn't it? 'Sprint', 'tickets', etc.
> Sprints don’t help organize things…
You can’t talk about sprints unless you talk about the sprint demo: It’s the proof that the closed tickets actually represent completed work.
> … they’re designed for mangares 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).
That’s one take, but managers are just as likely as anyone else to B.S. their way through the tickets: “oh yeah that’s pretty much done”. The sprint demo clarifies what “pretty much” means.
> … When you’re on [an efficient team]… then it’s easy to see how everyone else mistakes the bureaucracy around the work for the work itself.
This is extremely true, and probably the main failing of any project management method.
> … the backlogs, the sprints, the points—is pure bureaucracy. It gets in the way of productive folks…
Again, we can’t talk about the sprint unless we talk about the sprint retrospective: It’s there to help the team identify tools and processes that are inefficient, and adjust incrementally through automation, elimination, or modification. One of the things that might get eliminated is the fixed interval sprint. Or replacing relative-size estimation techniques (“story points”) with something more rigorous.
That “sprints” are used mindlessly is frequently true, but we should not dismiss them mindlessly either.
Team members that are motivated by pressure and deadlines, and whose output varies day-to-day, greatly outnumber team members who diligently work through their list of tasks at a consistent and optimal pace.
This is the fundamental reason why sprints exist.
If you exist in an environment where all team members are highly motivated, consistent, diligent, and pulling in the same direction then yes, sprints are a distraction, but it is my experience that teams that are genuinely like that are rare as hen's teeth.
I agree to a large extent.
For myself, I'm the most productive when I
- Am able to influence what I work on, and choose how I solve a task
- Have tasks lined up in a front of me that I can choose to work on
- Am in a state of flow, where the tasks in front of me roughly corresponds to my skills.
In other words - to me - a good project manager makes sure that there are plans for what to work on next and that the tasks roughly corresponds with the teams strengths.
Now, that roughly corresponds with good "backlog grooming", but not sprints.
Basically, I think Kanban works much better.
I'm frankly puzzled how SCRUM sprints are even expected to work with a development + QA cycle.
When a sprint starts, what QAs people are expected to do ? When the developers finish, and QAs start testing, what developers are expected to do ?
It seems to me that this forced synchronization is just pointless and harmful.
Where I work, we handle "sprints" just like checkpoints. This is in developing stage, this is in testing, this is done. It's expected that almost everything spans more sprints.
Like every trade, software engineering depends on a set of tools designed to help 'get the work done'. These tools can be hardware (e.g. laptops, servers, test equipment), software (e.g. languages, compilers, source control), or methodologies (e.g. agile, waterfall).
Each tool should be evaluated (and periodically re-evaluated) to see what its 'leverage factor' is for your situation. For every unit you put into it (time, effort, money) how much do you get out of it? The best tools give you a 10x or better leverage factor. If a tool gets in the way (i.e. it has a 1x or lower leverage factor) then it should be ignored.
Some tools are just bad (they take more time and effort to learn and to use than they save you) and are generally weeded out. Some are great for certain situations but bad for others.
If sprints (or any other tool) are not helping you and your team, then try to figure out why. Is the tool just not a great fit for our situation (e.g. using a hammer to try and fix a car engine)? Are we using it wrong? Is there something better?
Too many companies and managers go for the 'one size fits all' approach. "This worked at my last company so it must work here too!"
Sprints are a container of fixed size to put work into. This container can be useful sometimes, but that depends on the nature of the work being done, the humans involved, the group social dynamics, and a myriad of external factors. There are combinations of those parameters where the sprint is almost always the wrong container. As an example, take pure or applied research. I've seen such work shoehorned into sprints to the detriment of productivity, to the point of killing it almost completely.
Related to this is that sprints and their associated concepts mechanize and formalize something that may or may not need such. Applying something like Scrum almost always has one engaged in motions that are disconnected or even counter-productive to the local environment. That said, it sure is a lot easier to pick a methodology off the shelf than it is to engage in sober, thoughtful, and rational assessment of your situation's organizational needs. There's also risk inherent in that too, but one effective counter to that is to incrementally add/subtract process as needed.
Given the above, I consider process-heavy management to be a signal for prospective employment -- on the very much negative side. It tells me a few things, mainly about the way management's group mind works and also about what my future role in such a group would be (i.e., more part of organizational machinery than a creative agent).
The last point I'll make is that I just find the experience needlessly draining. A job typically lasts years. It's more of a marathon than a sprint. If it was a marathon with a few necessary sprinting periods, that might be bearable. If you really are sprinting constantly (the next sprint starting immediately after one concludes), that's a good way to generate burnout.
Article seems more about management and tooling than anything else. No amount of frameworks or toolsets will solve a bad/broken management style. Agree with the other comment here about forcing cts into discrete flow. I've always seen sprints / scrum as a babystep to a kanban based method rather than the end goal from an operations perspective.
But a bad management style would still trump this.
"Sprints" are a very bad name, giving the impression that the team is always running, which is a bad for morale and quality. In reality, they are just "cycles".
I see them like CPU cycles, but for a team. They are a heartbeat keeping team members in sync. It's all about answering what's my next task when I'm done with the current one. If you I work alone, or in a very small team, with no external stakeholder, then I can answer that "just in time" and don't need cycles.
But if I work in a larger team and/or with external stakeholders, then it's not practical to do this "just in time", gathering everyone to decide what should be the next task, every time a team member completes a task. In that case, we need to batch the planning work. That's what cycles are for.
I agree with the author that too often the process feels unnecessarily bureaucratic, and I really dislike the "sprint" terminology, but I wouldn't throw the baby out with the bathwater. Cycles still have a purpose.
The problem with stuff like sprints and agile is that you - the organization - need to understand why they are useful. If you don't then it is just cargo cultism.
There are some great, as in large, problems with software development, as a result of having multiple parts developed by different groups, or even by one person at different times. The parts have to work together.
It is easy, and I have seen this happen in multi-million dollars companies (plural) for groups to go off, develop their parts and for the parts not to work together. Boom. A sprint is designed to ensure that detecting this failure happens early rather than late.
Can you have a sprint that does not help this situation? Yes. And if you do then the sprint is just foofaraw.
The other problem is that it is easy and somewhat natural to write 90% of the code. Which does nothing. 90% of the code is meaningless. What works is the issue. No one needs or wants code. They need or want functionality. I have written some really really cool code that does nothing. It was 90% of something, but unfortunately had to be rewritten in order to be functional.
The second use of a sprint is to show functionality. A sprint to have 92% code completed is nothing. Can you show (to me or yourself) that 90% of the functionality is there? The difference between 90% of the backend API's being functional (and being able to prove it) and 90% of the backend code being written is monumental.
There is a final use of sprints. As a manager you can appear to know what you are doing by organizing sprints, when in reality you have no clue whatsoever as to what you are doing.
If you want to be a good programmer, you will use sprints with yourself. I'm a sole developer and when I use sprints by myself I am much more productive. Much. [updated for spelling and clarity]
This is just a bad hot take. It does not even propose anything that's better. Just do work and it will be there? How? I'm confused. And, i, my self, don't believe sprints are 100% the best, but for us it helps to manage load, see how much we can do, and make sure everyone is on the same page. It's not a bible, it's just another tool in the chain.
In one of my past job, we were mostly pragmatic and humble engineers with strong ethos to solve most problems from first principles without ego or dogmas. We didn't have a company-wide mandate to use any particular methodology. Every week, a bunch of leads met to share their retrospectives and learnings. Without any corporate diktat, most application and platform teams were following a lightweight form of sprint. You would find whitewalls filled with vast end-to-end system flow designs and besides them there were sticky notes which roughly looked like Kanban board. These things just happened – no dogma driven push from anyone.
In an even earlier job, I saw an overzealous 'scrum master' certified engineering director trying to ticketify everything with Kanban boards and burndown charts etc. Engineering teams under them hated it. It was the least productive period for a division of 100+ engineers I ever saw.
Moral of the story: methodology matters a lot less than culture and talent.
The problem that a lot of people get to with Agile/Lean is that the actual practices deviate from the original goals. The powers that be can't actually handle agile in it's truest chaotic form. So it gets bastardised from the top down (and at times from the bottom up as well).
Worse still some of the things that are advertised as 'agile' actually violate the principles. The card wall was supposed to be about as light a representation of ongoing work as you could get and facilitate the interactions with the teams. Unfortunately, tools like Jira change this to be an over-engineered process and tool (which violates point one of the manifesto). Remote work has not made this better.
Sprints and pairing become tools to keep devs on a hamster wheel. Always productive, in theory at least.
Leaving this to the side, I've seen sprints done well and badly. More often than not teams can't manage to point cards effectively. I've had a couple of teams where things just end up in a middle ground constantly (everything is a 3). The exercise of comparing this card to some previous representative card is too hard (and is itself prone to problems).
Retrospectives, can be a useful tool, or they can be a back patting exercise. Showcases without a customer in sight (put your hand up if you're the "customer proxy").
Having said that, some of the behaviours can be really useful. Breaking down overly complex cards as a part of planning helps define the work. There are other opportunities to do this, but backlog grooming / planning sessions are one place.
Having the team discuss cards and talk about complexity often reveals unknowns. I've seen a bunch of examples where things will be caught because of a dev/designer/product manager can see something that wouldn't have been identified if someone just started working on it.
One of the biggest problems with sprints is they’re organizationally orthogonal to CI/CD. Kanban is a much better process for an organization who’s goal is to continually deliver business value to stake holders. And it’s been my experience that pragmatic Scrum teams that just roll over unfinished work are essentially using Kanban.
I think the author completely misses the point or never worked in a proper agile team.
Imagine running a marathon without mile markers. Sprints are like mile markers they help you know and adjust your velocity and capacity to reach the end goal.
Without these sorts of tools you are just running without any sense of achievement or tuning to your teams performance.
I’ve said this for a while now among friends: If I were running a company, there would be no shared ticket or todo list. Everyone can manage their own work and keep their own todo lists. The best employees already do this anyway.
Basecamp’s “shape up” method is a nice way to coordinate work when everyone has their own todo list.
For me this article joins a long list of "I don't believe in X" where the author has apparently only experienced bad versions of X.
Most of the time with the articles, the answer to "X done poorly" is to switch to "Y done well" but doing X well would have likely worked too.
Personally, my most enjoyable job as an engineer was when I worked on a project by myself in 1 week sprints. I spoke to my manager twice a week: 15-30 minutes Monday morning for "sprint kickoff" and 15-30 minutes Friday afternoon for "sprint wrap up" and how I spend the rest of the week was up to me. When a second more senior engineer joined the project it was even more enjoyable to work on it together in the same sprint format.
Having a great manager also helps a lot!
There is this notion that Scrum is supposed to automatically fix problems. It is the complete opposite - it is designed to DISPLAY problems quickly and ensure they are not hidden underneath a layer of fog. In other words, teams using Scrum will see more problems than the one that doesn't, but it's much better to see those problems than to hide or ignore them.
Sprints ARE a tool used for planning, but not just by managers. A team can use their historic sprint data to PUSH BACK against their managers and say "No, we won't get this done in time. Now go away and fix your plans.".
Other people mentioned this is a bad strawman...that's an understatement. But I think that's what the author wanted.
I think organizing software work is hard.
It's easy if there are only maybe 2-5 people involved, objectives are clear and not conflicting.
Usually though, you can't afford to implement every idea you have, you need to maintain old stuff while also making new stuff, teams have non trivial dependencies on each other's work, and time predictions are nebulous at best. Also software managers are generally software engineers first, not managers.
Is sprint good at these things? I don't think so (though I never managed a team with sprints, only saw other teams do it badly). But is there a better blueprint? I'm not sure either. It's a hard problem, and hearing about what doesn't work isn't so insightful.
I hate the word to begin with.
Sprint.
I do not want to rush through the work and squeeze into arbitrary time period but do it properly in the timeframe necessary (and not more). The hastle and rush atmosphere surrounding this word is repelling to me. As well as the 'stand-up'. Are we on exam in the school or what? Not being adult coworkers but people in entertainment or support group to present to each other?
In other hand a flexible communication and progress tracking system - especially in a fairly unpredictible business like making a novelty product - is essential in teamwork and I know no better than something like this. But this childish naming makes me suspicious about the intention and goal of those coined it...
Sprints provide natural alignment for multiple teams trying to coordinate. They also provide data about how your team makes software, frequent (scheduled) points when change is acceptable, and repetition that allows habits to form. And for teams that struggle with it, they provide a great excuse to push back on a requirements team that refuses to provide details and struggles to break down requirements into chunks that can be addressed in the duration of a single sprint.
That said, they aren’t magical. They are often misused. Not every team and every project needs them or is faced with any of the problems sprints set out to solve. And there are lots of ways to build good software.
I feel most of the criticism towards Agile coming from devs misses an important point: how it’s used to show the progress of a project to the people outside of the team.
Unless you are part of a completely autonomous team, you need to communicate progress in a way that’s more informative than saying “trust me and leave us alone, it will be delivered in X months”.
Spending time in meetings or writing down and discussing what you think that should be done next indeed can create an overhead (even more when the frameworks is abused or done wrong), but epics, stories, sprints and demos provide a more detailed way of communicating and demonstrating progress to whoever it is relevant.
Good teams don't need sprints, ergo sprints are bad is not a good argument. I'm not the biggest fan of SCRUM overall, but it exists for a reason. I saw in another thread/article here someone describe SCRUM/sprints as "training wheels for managers", and I feel that is incredible accurate. If I'm going to come in and start leading a team, I'm probably going to start with SCRUM just to get my feet under me and learn how the team works. After that, switching to kanban can be discussed, but there needs to be /some/ tracking to communicate timelines to the business at large.
I think the (unpopular) reality here is that there just really isn’t a lot of traction for one-size-fits-all project management. Methodology and even terminology has too much marketing budget attached to it to be trusted.
There are some general guidelines, there is some amount of this that can be taught (not enough to sell a course or certificate), but mostly project management outcomes are dominated by the terms of understanding the domain in detail and the people involved as holistic human beings.
Paul Graham said that the management of hackers for someone who isn’t a hacker can be summed up as “give up”.
Don’t shoot the messenger please, but I agree with pg.
I think the author got the right answer, but checking their work, I'm not sure they got it the right way. Sprints are actually really simple. You know how you work on something for a year, and then Google I/O is coming up where you're going to show it off to 3 billion people, and it's not done, so you just say "ya know what, I don't even CARE about these features we said we'd have" and you launch whatever you happen to have checked in on launch day? That's sprints! Except with sprints you do this every two weeks instead of every year.
My view as a customer: a simple change, could be changing ine character in one script will be delayed for two weeks or however long the sprint is. I would usually do all the troubleshooting and testing and basically handover the dev team a solution so that they won't keep delaying simple things for months.
I like the concept but dislike the rigidity. Perhaps it might help if sprints were retroactive, that is you get shit done, create jira,etc... and it will be reviewed as things done in the sprint, instead od micro-managing tasks, set goals like "complete feature X and bugfixes".
Sprints and (point-based) estimations on tickets are not to improve software quality, they are to improve manageability of the software development process.
If you work at a product shop, you might well be able to do without them.
If you build software for clients, the planning is VERY important in order keep the client happy. Knowing ASAP that the project is going to miss a deadline/budget/feature is key to whomever manages the relation with the client.
This is why we do sprints and estimations: to know how the project is going so we can update the client ASAP (or find another solution) when things are off.
I probably agree with some of the points of the article. However, when you're in a management position, you need some kind of measure that gives you previsibility. Not the best, not the worst. Serves a role.
Here is what works:
1. Maintain a To Do list for the project.
2. When a developer is available, he/she/it will pick the highest priority task to work on.
3. Use the To Do list when negotiating new features with stake holders. They have to decide where in the priority list the new task is added.
4. Break very large tasks into smaller step by step tasks that can be developed independently.
It’s simple. It works. I have delivered successful projects most of my career using that method. As a single developer and when managing large teams of developers.
One could write a solid critique of sprints and how they help or don't, and where time is wasted, but this article is overzealous and comes off as motivated more by anger than reasoning.
If you want a well-reasoned discussion of where the waste is and isn't, I highly recommend Allen Holub's talk #NoEstimates [0].
I'm a PM and PO. I have a scrum team of 5 engineers and 4 QA. Sprints are killing me. It's so exhausting. No rest, ever. And the retros are almost purely negative.
Yeah, I don't believe in sprints either. IMHO the worst is actually the commitment for the sprint, the team shouldn't have that. They should just do the job, in their own pace, without being bothered by the end of the sprint, the beginning of the sprint, or caring about spillovers. I appreciate that deadlines couldn't be done away, as they are a fact of human life, but I don't see value in adding further overhead on top of that.
Before sprints there was waterfall scheduling at the project level: requirements, design, development, testing, delivery, and maintenance. Often tasks would be late and delays would propagate resulting in the old adage for estimating how long a software project would take: think of a an amount of time it should take, then to get the actual time, double the number and then change the unit to the next longer time unit.
My experience with agile:
Sprints and standups are degrading tools to enable extremely subpar management to maintain their role.
Tell me why a properly functioning agile shop even needs a manager.
Sprints are a great way to always have reasonable goals to work toward. They work best when there's a product team, or product manager and product owner, carefully managing the task. If you have a bad PM, or don't have one, then you're probably in bad shape anyway, and sprint might not help.
I've worked with two-week and one-week sprints, and generally found them very helpful, but more helpful with better PMs.
While I appreciate the value of timeboxing, one issue I have with sprints, at least of the 2-3 weeks variety, is that they make the process feel like an endless churn, because after the sprint-end is before the sprint-end, and the next sprint deadline is always close. It makes for a very uniform schedule with little variety, and the outlook of an endless stream of same-shaped sprints can be soul-crushing.
Sprints are good to force a cycle of feedback on dev team vs customer.
But they are not the problem you are trying to solve, just a tool.
I like the concept of false idols in christianity: you must orient yourself toward truth and love (building something good and truthful).
That must be your highest value. Money, prestige, UML charts, Sprints, those are all false idols, they will lead you astray if you worship them.
Only worship truth and love.
i think it's funny how speaking of Agile is like speaking of religion or politics. everyone has an opinion and it's always a spark to fiery conversation.
like religion, I've seen Agile done poorly (extremely damaging and counter-productive) and done satisfactorily (not harming anyone with some mild benefit). theory is only half the equation, a big part of the equation is methodology and execution.
> Good teams don’t need sprints to get good work done.
I agree. Most teams are mediocre though. A lot of processes have the goal to limit risks due to bad teams.
If you think Scrum is the "universal method for making software", you clearly haven't worked outside of applications software...
> software engineering has accepted as its charter "How to program if you cannot."
Looks like this Edsger Dijkstra's phrase never gets old :)
People hate on anything and everything.
It boils down to needing a form of alignment, you can't have team members running around making it up by themselves as they go.
How you achieve alignment and shipping things customers love is irrelevant, just fucking achieve it.
I don't believe this is a strawman...at least from an outsider's perspective. As someone who has only ever written software independently, the very idea of agile and sprints (at least reading about them here and talking to friends) has kept me from ever wanting to work for a company that uses them. It seems like it would suck all the fun out of writing software.
Sprints actually can help to do much less. If you don't do sprints, you can always be unsure if you did enough or take on more ambitious plans. With sprints, you agree to some more or less fixed delivery, so you can get it done and chill.
Also helps that companies love to employ clueless people to organize the sprints and those tend to care more for jira to look good, than actual work.
I get the sense that the OP has never worked on a large team or massive product with a large surface area and competing goals. I get it, for a lot of smaller endeavors that only have a few devs then sprint ceremonies would be overkill. But if working on large project with many teams, the lack of structure would be almost certain death. Entertaining tirade though.
Seems like the author is ranting hot air.
I’ve worked in sprints. I’ve been a facilitator and an IC and now manager (aside from sprints).
A bad team won’t improve with sprints.
Similarly a good team might not always benefit from sprints.
Almost every team I’ve worked with has improved with iterations and interactions.
The best team I’ve worked with used sprints and communicated with stakeholders well… which in turn spoke true to the agile manifesto.
< rant >
I want to see the code produced by this non-system; and to learn its longevity, particularly beyond when key early contributors have left. I want to see the applications produced by that code and to learn the size of the teams, departments and companies around the products. This article carries little weight without some of that context.
There's no meat to this article, just a rant about some management style the author doesn't like. The author goes so far as to say that only the managers can fail in software. This sounds unbelievable to me because we're all humans.
Sprints, and points, are not JIRA. Points are not Sprints. Jira is not Scrum. These are all orthogonal tools that can work well together, in my experience. They don't always work well together. If you're doing Scrum well, you'll inspect what's working and what isn't, and change it. It's possible to change so far from Scrum you've moved on from it... but I haven't seen that happen and yet still found it useful in most places I've worked.
People who dislike Scrum often complain that the defenders regularly say "well, you're not doing Scrum if you define it like that". They throw away the whole argument. Scrum that isn't Scrum, isn't scrum. You can't not-do a thing and then claim that thing doesn't work.
< / rant >
Ineffective standup and planning meetings are a waste of time, a lot of the time.
But how do you truly know WHAT you should on focus and deliver without having a clear understanding of the broader picture and without breaking apart work for the week, especially with a team where everyone is at completely different steps and working on completely different things?
in my experience - if you have a good team, it makes zero difference what methodology you use, they will deliver a decent or better product - conversely, if your team sucks, it also doesn't matter what methodology you use - the end product will be poor, if it works at all.
All the ceremonies in the world aren't going to change either of those things.
I lost 3 minutes of my life on that article and will lose 5 more to let you know you can skip it.
It's just a rant from someone that thinks they're too good to be managed, probably that kind of engineer that has 10 conflicts a week with everyone in the company because they won't budge on their unfounded personal opinions.
If you have a high performing team, great, do what the fuck you want.
If not, then chances are the team will need some guardrails, that’s what agile and scrum offers. It’s a place to start.
Just because you don’t believe in having a system to break down work doesn’t mean it isn’t useful.
Personally, I’ve seen the alternative in action and it always leads to burnout.
How is a backlog useless? Every company doesn't have an infinite supply of engineers. They can only work on a subset of the tasks you have planned. Backlog is simply the set of tasks that are not the most important thing right now. If you finish your spring early, simply pick up something from the backlog.
[Michael_Jackson_eating_popcorn.gif]
From the dev team's perspective, sprints are a good tool to force the business people to pay attention to you. Booking a few hours of your prospective end users' time each week helps ensure they focus on collaborating with you, think about what they want, and understand what you want to tell them.
Sometimes sprints are the right tool to accomplish what you need to accomplish, and sometimes they aren't. It really depends on what you're trying to accomplish. You probably don't want sprints if you're building something. You probably do want sprints if you have a release cadence.
Ah yes another article that says we don’t need management tools, if only, our team was a small handful of smart people.
And if the work gets too much then I guess we just work harder to the bone —- because woe us if we should possibly have to grow and delegate, let alone in a scalable, organised and structured way?
Ok. You don’t believe in them.
You’re the lead of an 8-person team. How do you get everyone rowing in the right direction and shipping software? It sounds like you’d just leave everyone to sort it out themselves and believe they will build the right thing and ship it on time.
I don’t think sprints are a required practice. I’ve used them with teams simply to help shield them from micromanagement and get them used to iteration cycles. They were held up on releasing anything until a huge batch of features was perfect. Only every deploy into production was met with a week or so of overtime fire fighting because the amount of change they were introducing to the production environment was too large and their staging environments were always under provisioned and didn’t have the same load. Sprints helped them break down work instead of crunching for months at a time.
After a while they didn’t need it anymore. So you change things up.
Where it goes wrong I think is when people start copying the practice hoping that following the rituals will grant them good software.
You still need something though. A little planning goes a long way.
I don't like sprints either, but this take is so engineer-centric that it doesn't stand up on its own for one second.
His ideal world works for a team of engineers that have no manager, no deadline, no collaboration with other teams, etc.
Basically it works for a personal project. That's it.
I have come to like sprints by not caring if the teams I am on succeed or fail. I can then collude with other devs to water down the amount of work done a sprint.
Use their crappy tools against them and make sure your projects fail. You’ll be getting another job next year anyway.
It's true. But then also it isn't. Sprints (or Scrum) are useful when trying to force an Agile process within an organization that isn't Agile. If you're working in a true Agile company there's no need for sprints (or Scrum).
the writer assumes that sprints are adopted to help the developers, while in fact its a tool so that product owners track progress in a way to have a shorter feedback cycle than in months.
Of course its more convenient not to worry about sprints and time/points and "just work", and that is usually the case in startups or backend teams where the stakeholders are all always present in the same room, but once you add more layers to the organisation chart it becomes harder to track what everyone is focused on right now and that they are planning to do next without sprints or something similar.
Someone my team either had a second job or quiet quit, but according to Jira he was really productive. The reported metrics can’t be trusted. The worst part is that our manager was the only one that didn’t figure it out.
I read as "I don't believe in spirits". Then replacing as I read was somewhat humorous.
"Spirits don’t help organize things, they’re not a useful organizing tool"
"Good teams don’t need spirits to get good work done."
For a more cogent and compelling analysis, I recommend Florian Haas' Fragile Development talk.
I thought it said "Spirits" and I was like I don't either.
Me neither. Unfortunately my boss does, though.
I wonder how in the author's world teams communicate? How do they communicate progress with other groups (potentially other teams they need to synchronise with for the release of features), how do they communicate with managers (ah those pesky managers, always wanting to know when a feature will be ready), how do they communicate with customers (ah those pesky customers. always wanting to know when a feature will be ready)? “Good teams don’t need sprints to get good work done.” No, and that's not the idea behind sprints and backlogs and tickets. It is primarily about communication.
Does “pointing tickets” mean “assigning story points to tickets”? I’m unfamiliar with that usage (probably blissfully so).
My Project Manager's Response: "Nice rant. Sounds like he works with mystical unicorn teams."
I generally avoid rants on HN, but I can't resist this one because this post is particularly irking.
I absolutely hate useless opinion posts like this. They're incredibly vain. There is zero substance to the authors argument beyond "sprints are inconvenient".
I can only assume the person who wrote this lacks much real world development experience, because anyone who has worked at multiple companies will tell you there is no one size fits all way of doing development. Post like this are pure Dunning-Kruger effect.
How else do you think a person that doesn't have any hard skills can control a team of experts?
Why do people excuse ideas they don't like as "bureaucracy"? It makes me sad.
Obligatory Rich Hickey:
I am surprised at the fact that there's so many PMs on Hacker News
Why is this stupid “opinion” bubble up to the top of HN?
Product in customer hands is your best sprint.
He had me in the first half, not gonna lie.
To each their own, but...
This blog post is my love language.
sounds like it's not the sprints, but the managers that the author doesn't like.
Just read title. Me neither.
I reject most of the agile rituals, including daily check-ins and weekly or two week sprints.
If I personally have to check with someone, each day, to get good work from them, then my preference is to fire that person and hire someone else who I can trust. If I need to check in with a person every day, then I'm micro-managing this person, and I have to wonder why they need to be micro-managed.
This is different from me being available, every day, to help them, when they need some specific help. If they are being blocked by something, they should feel free to reach out to me and ask for my help. But a daily standup assumes that they won't ask for my help when they need it, and therefore I need to force a moment of conversation each day. Again, it is easier to fire such people and hire someone else who I can trust. I'm working in the USA where it is easy to fire people. If I was working in Europe, where it can be difficult to fire someone, then I would instead seek to get people traded away from my team, and I'd see if there were others in the organization that I could get to move to my team.
With senior level software developers I find it is often enough to meet with them on Monday and ask "What will you accomplish this week?" and then chat with them as needed during the week, and then on Friday check in with them and ask "What did you accomplish this week?" If they didn't accomplish what they thought they would during the week, then we can talk about why. With junior level software developers, I usually have to check in with them more often, which is fine. Usually, with each person, I figure out what is the ideal level of support that is needed. Every human being is a unique individual with unique needs, which is why the daily standup is a bad idea. It's important to figure out who is working for you and tailor your support to the needs of that individual.
Direct, honest communication cuts down on the need for rituals and ceremonies such as a daily standup meeting, or grouping work in two week batches.
Often, when I speak to managers of tech teams, they say the main point of two week sprints is to offer transparency to the leadership above them about what progress can be made during those two week sprints. But again, direct, honest communication with the top leadership typically does a better job of explaining what to expect, as well as to explain why something is delayed, if something is delayed.
To the extent that two week sprints serve a mostly political goal, I'd rather address the politics directly. I expect people below to reach out directly when they have something to say, and I do the same to the folks above me.
None of this precludes tracking how much work is being done every week, or every two weeks. If the work is being tracked in a tool such as Jira, it is still possible to add up the number of points that are being done each week. Nothing that I say here suggests that I'm against gathering metrics and trying to improve those metrics. But many of the rituals that are currently advocated for Agile development processes waste time on meetings that could more easily be worked out informally in a series of quick one-on-one conversations -- a style that is actually agile, rather than burdensome and officially Agile.
In general, meetings that waste time should be reduced to a minimum. Conversations that have specific purposes should be encouraged. Large group meetings should be reduced, and one on one meetings should be favored. This style has worked well me over the last 20 years that I've been doing this. As to the details, and nuances, of getting the most from one on one conversations, I develop this theme in my book "One on one meetings are underrated, group meetings waste time."
good for you dude
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.