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.
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.
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.
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.
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?
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 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.
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...
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.
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.
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.
> 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
Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.
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 next
In Scrum, the purpose of defining sprints is mostly, despite the name, to slow down between them, in order to allow for some planning and discussion; otherwise there would be only an endless stream of "urgent" tickets and requests.
You missed one of the most important: to provide slack time. Ideally, the team will only commit to less than they can accomplish, so there is built in slack time to do research, training, tech debt, and proof of concepts.
Sprints 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.)
[+] [-] hurril|3 years ago|reply
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.
[+] [-] gbro3n|3 years ago|reply
[+] [-] stingraycharles|3 years ago|reply
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.
[+] [-] LtWorf|3 years ago|reply
Also all the sprint planning and retrospective took basically 30% of our time.
[+] [-] polotics|3 years ago|reply
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.
[+] [-] steveBK123|3 years ago|reply
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.
[+] [-] RamblingCTO|3 years ago|reply
*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.
[+] [-] kixxauth|3 years ago|reply
Productive teams are primarily hackers solving larger problems. This stuff gets in the way, causing the team to morph into developers instead.
[+] [-] twic|3 years ago|reply
[+] [-] brightball|3 years ago|reply
https://news.ycombinator.com/item?id=17154355
[+] [-] pjmlp|3 years ago|reply
[+] [-] bkq|3 years ago|reply
[1] - https://theanarchistlibrary.org/library/david-graeber-on-the...
[2] - https://bullshit.ist/bullshit-jobs-how-our-modern-bureaucrac...
[+] [-] abricq|3 years ago|reply
[+] [-] throwaway4aday|3 years ago|reply
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.
[+] [-] rloaderro|3 years ago|reply
[+] [-] Eddy_Viscosity2|3 years ago|reply
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.
[+] [-] 015a|3 years ago|reply
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).
[+] [-] throwaway284243|3 years ago|reply
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?
[+] [-] SkipperCat|3 years ago|reply
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!).
[+] [-] lelanthran|3 years ago|reply
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.
[+] [-] gilbetron|3 years ago|reply
[+] [-] throwaway284243|3 years ago|reply
[+] [-] samatman|3 years ago|reply
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.
[+] [-] kortex|3 years ago|reply
[+] [-] Kinrany|3 years ago|reply
Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering
[+] [-] chrisseaton|3 years ago|reply
[+] [-] nedt|3 years ago|reply
[+] [-] JackMorgan|3 years ago|reply
[+] [-] GoToRO|3 years ago|reply
[+] [-] scld|3 years ago|reply
[+] [-] kortex|3 years ago|reply
Many folks may be unproductive with one management style yet thrive in another.
[+] [-] asah|3 years ago|reply
[+] [-] bbarn|3 years ago|reply
[+] [-] BirAdam|3 years ago|reply
[+] [-] jeffersonheard|3 years ago|reply
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.
[+] [-] prionassembly|3 years ago|reply
[+] [-] arnvald|3 years ago|reply
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.
[+] [-] lwhi|3 years ago|reply
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.
[+] [-] hankchinaski|3 years ago|reply
[+] [-] thenerdhead|3 years ago|reply
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.
[+] [-] dbingham|3 years ago|reply
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.
[+] [-] manmal|3 years ago|reply
Are sprints necessary for knowing what other people are working on, and for having a say? I thought sprints are only tangential there.
[+] [-] marcus_holmes|3 years ago|reply
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.
[+] [-] schwartzworld|3 years ago|reply
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.
[+] [-] azangru|3 years ago|reply
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:
[+] [-] HelloNurse|3 years ago|reply
[+] [-] JackMorgan|3 years ago|reply
[+] [-] onion2k|3 years ago|reply
[+] [-] benrow|3 years ago|reply
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".
[+] [-] smallerfish|3 years ago|reply
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.)