Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don’t believe in sprints

robinrendle.com

Post reply on HN
Print view View original

141–150 of 459 posts

Re: I don’t believe in sprints

#141

Post by mekazu »

phailhaus wrote: post #121
kixxauth wrote: post #56

Earlier quoted context omitted.

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

Apple comes out tomorrow and announces the new iPhone 15. "We do not know when it will be ready. It might be tomorrow, or just as likely it will be in a hundred years." Who will hold their breath? Who would invest in this? Software needs to be used by people. Software deliveries that cannot be estimated cannot be relied upon for planning. It may as well never be announced!

But they wouldn’t announce it until it’s pretty much ready.

Re: I don’t believe in sprints

#142

Post by sswaner »

hurril wrote: post #6

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…

In my experience, the “predictable deliveries” delivered by agile are based on behavior changes induced by the methodology. Specifically, focusing on stable point velocity per sprint focuses the team on creating sprint plans that safely deliver. This reduces the potential accomplishments of the team - they reduce throughput and delivery to a level that can be safely accomplished every 2 weeks.

I have yet to find a startup that successfully launched using agile. I am sure there are examples, but most seem to be focused on the true goal of software development: releasing features to production.

Re: I don’t believe in sprints

#143

Post by quadrifoliate »

mihaaly wrote: post #102
hurril wrote: post #6

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…

Predictable delivery depends on the quality and not on the form. Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits. If the breakdow is carried out badly or the big picture is formed carelessly then the chain of sprint breakdowns will also deliver rubish! If one lives on and focuses on atomic delive…

> Good quality planing, good quality execution will make a delivery predictable regadless of the projecy management style and how we break down a big task into smaller bits.

From some hard-won experience working with a variety of different teams, I have unfortunately found that good quality planning and execution are far harder to attain than you perhaps imagine. Some of these articles seem to paint software developers as magically perfect beings, with managers being pulled straight from Dilbert. The reality is far more complex. Sometimes one of the people on the team is being an asshat and hoarding knowledge. Sometimes they have overly-strong opinions on languages and frameworks that they're super familiar with, or go to the other extreme and work on only bleeding edge ones that were posted on Hacker News.

I strongly suspect that Agile is used at companies because it's a mildly effective way of curbing these dysfunctions in a team. If you spend time and money hiring the perfect team, then you probably won't need Agile. Think of a situation you do find somewhat commonly where you often have hackers smoothly churning out work with a team they selected perfectly for – early-stage startups. Good early-stage startups are often very picky about who they bring onboard, because an unproductive hire can literally cost you the company. It's possible to reproduce that on a team, but imagine telling your next boss at a run-of-the-mill that you're going to hire slowly over 18 months and very selectively.

Re: I don’t believe in sprints

#144

Post by agumonkey »

melling wrote: post #116
hurril wrote: post #6

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…

Yes, people like predictable. Tell management every project will take a month, and meet that expectation, then management will be happy. While someone else who takes the same work and says it’ll take one week then is consistently 2 days late will be viewed as less effective. So, by squeezing people into a guaranteed timeframe, in a mini death march aka sprint, you are forcing people to make [very] conservative estima…

This is a strange law of human groups. Only caring about negative slip. That's why everybody inflates everything to shield themselves from the backlash.

Re: I don’t believe in sprints

#145

Post by sarchertech »

ejb999 wrote: post #100
kixxauth wrote: post #56

Earlier quoted context omitted.

Why do we need predictable deliveries? Let’s boil this down to first principles. Nothing about building software, especially innovative software is predictable.

There is nothing unique about software - building almost anything has a certain amount of inherent unpredictabilities - would you hire someone to build your house with no commitment of when it would be done, what it might cost or what it might look like before it is completed? I doubt it.

If you give 2 builders a set of blueprints for a house, they will build essentially the same house.

If you give 2 software developers the same software spec they will give you 2 completely different pieces of software.

The code is the blueprints.

If you’re building a new innovative house that is different than what currently exists, the design phase is very similar to software development, and is likely to take an amount of time that is unknown at the beginning.

Re: I don’t believe in sprints

#146

Post by jjarvis »

bsima wrote: post #93

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.

This! I am fortunate enough to belong to a small team which has mostly adopted Basecamp's "shape up" method and it has been a breath of fresh air.

I think the biggest game changer is the notion of using the "appetite" (number of weeks per cycle) to drive the design of the solution. This is opposed to the usual approach of coming up with a solution and then estimating the points/time it will take to do each part of the project. SE's are bad estimators and the product manager rarely uses time as a design constraint. This is why most projects run past their deadlines IMO.

Re: I don’t believe in sprints

#147

Post by EugeneOZ »

hurril wrote: post #6

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…

Nice way of arguing: “this is nothing but a strawman” - and 0 counter-arguments, 0 quotes, 0 attempts to be polite. Brilliant.

Re: I don’t believe in sprints

#148

Post by PaulHoule »

hurril wrote: post #6

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…

I've worked in places where the cycle to integrate work was more than six months. In a situation like that you often don't really know how to build the product at all and the six months can stretch to anywhere between 8 months and 18 months.

It is true though that springs bring in their own problems. For instance I worked on one project with two week sprints where it took a 2-3 day batch job to generate a database/a.i. model. This had a bit of Gannt chart character in that it had to be managed in terms of calendar time instead of punchclock time. If you didn't start the database build early enough you would predictably blow the sprint.

At the same place there were a few different teams with their own sprint schedules and the system was able to turn a 1 day delay into a 4 week delay as one blown sprint caused another blown sprint.

Another problem is how you organize work that has a pipeline structure. Is a tester expected to test work in the same sprint it is being developed in? What does a developer do when a feature is under test?

What really kills teams is a lack of trust. With the six month build cycle you can put off conflicts that a sprint cycle forces you to confront every two weeks. I think sprints are popular with some because it gives developers some space to be inflexible, but it is harmful for the business. Sometimes there is a feature the business needs right now and it could have it right now if you add 2 days to the sprint.

Re: I don’t believe in sprints

#149

Post by bluGill »

stingraycharles wrote: post #24
gbro3n wrote: post #11

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…

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…

Kanban is still better than sprints. You organize things that are most important at top, and what is done by the deadline is done and ships; what isn't done doesn't ship. Deadlines may mean you branch so can make the release stable, while feature work that clearly won't be done one time can continue if the team working on it isn't involved in the release.

It doesn't matter if you have sprints of kanban, if there is a deadline is project managers need to do the same work to verify things are progressing fast enough for the release. This work is estimating how much time remains, and if there isn't plenty take action. The plenty part is where most management goes wrong: they want everything done on time, but the only way to get that is have everything done early. That in turns means you need to have at least 20% (the higher the better) of the things planned for your deadline things that you are willing do allow to slip to the next release. Of course working against that is the human tendency to polish things until the last minute, but that shouldn't be managed by the deadline (even though it often is)

I'm against the web release early and often model - don't make your users your beta testers. I'm in favor of spending several months of test after the branch to ensure everything is stable even though this is a lot more expensive. I do agree with the web have automated tests for everything model, I just don't think automated tests alone are enough quality control - automated tests ensure that everything you can think of didn't go wrong, manual testing is about noticing things you didn't think of. (you will note I work in an area where my code can kill people)

Re: I don’t believe in sprints

#150

Post by HelloNurse »

azangru wrote: post #120

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 wor…

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.
Post reply on HN