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

Less is more agile

beny23.github.io

Post reply on HN
Print view View original

61–70 of 174 posts

Re: Less is more agile

#61

Post by ilaksh »

zac23or wrote: post #27

> Don't estimate I agree. But in my experience, the real problem is out of the developers' hands: 1. On a project, my team worked hard not to miss any deadlines. it worked, but the project was delayed for other reasons, and the PO told his superiors that the project was delayed because of the development team anyway. 2. On another project, my team didn't need to estimate or have a deadline. BUT at every meeting the b…

So-called agile methods. The manifesto is the only thing I know for sure is really agile.

Re: Less is more agile

#62

Post by soperj »

dhasso wrote: post #56

I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal an…

Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue isn't the estimating, it's that once you give an estimate, you're held to it even if everything around it changes.

Re: Less is more agile

#63

Post by quickthrower2 »

tpoacher wrote: post #37

I don't agree with the "no estimates" sentiment. My own view is that estimates are useful, but should be treated less as a fixed point-estimate prediction, and more as a single step in a kalman filter, with the understanding that the output at each step is probabilistic, and the number of steps is unknown.

I also don't agree with no estimates.

The problem is I see estimates like this;

$COMPLEX_REQUIREMENT: 12 days BACK END - 3 days FRONT END - 3 days UNIT TEST - 2 days

...

Which is almost certainly gonna be wrong, so it useless. But "12" is a number and number can be added.

We have 274 man days this quarter, and of course we allow time for bugs and leave and stuff, so sum of estimates is 263, so that's our plan for the next 3 months.

Never works.

Estimates are useful for making branch decisions though.

So knowing is it 1 hour or 1 day or 1 week or 1 month or 1 year (which is closest) is useful for deciding if it is done (hint if it involves code at all then not 1 hour!)

For each category, accept it might take up to 5 times as long. So 1 day = 1 to 5 days. 1 week = 1 to 5 weeks and so on.

Is it a disaster if the thing took 5 weeks?

Id there another "1 week" tasks that is more urgent than the one you are thinking of doing next?

That is the level.

Then don't track too closely how long it takes .. BUT ... maybe have a team leader flag at 2.5x estimate to discuss in depth if it is worth carrying on. In addition to standups/whatever to get unblocked or report the estimate was way off.

In a nutshell treat the estimate as a decision heuristic. But not as a developer skill measurement tool, or a timeline delivery.

If you have a real deadline, then presumably you agreed to it (some contract) and hopefully when coming to that agreement technical people were consulted, and loads and loads of buffer was included. It is like agreeing to host people on Christmas day - it will probably need say 20 hours of prep, but arranging it 3 months ahead of time and slowly working on it the whole time is a surefire way of success. Starting the project on 23rd Dec is a surefire way to fail. Common sense in real life (because we use common sense not trying to "optimise" every last second).

Also in real life if other things mean you can't host Christmas ... you don't agree to the deadline. Let's book a table at the pub. That is what you do. Companies tend not to do that, they agree to all kinds of silly things. And you get silly deadlines, and bullshit estimates as a result.

Re: Less is more agile

#64

Post by ilaksh »

jesstaa wrote: post #58
hannofcart wrote: post #43

Earlier quoted context omitted.

This is how we do estimates. Nothing set in stone, all just a rough guide. However, the "don't estimate" school is just a little crazy. In no other discipline would this be acceptable as a doctrine. Imagine a contractor you hire to build the house shrugging when you ask him how long or how much it will cost.

Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.

Architect designing home is the wrong metaphor.

Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes.

Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot of unknowns, new concepts, many moving parts, unsolved problems, to build a new invention.

Re: Less is more agile

#65

Post by ineptech »

quickthrower2 wrote: post #59
ineptech wrote: post #42

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular tha…

Point 2, even with CI/CD multiple times a day, with zero flaky tests and a sweet build time and automated test time, it sounds like you still need almost zero time between the final git push and merge to $BRANCH causing a deployment. What about review? Code review? QA? Showing off to stakeholders? These things add a delay, and there is a 'crunch' around the end of sprints where things are artificially urgent. I am no…

Obviously not all projects are the same, there are certainly pieces of software that would be disastrous to do that with, I'm just speaking generally. For reference, my (very not-startup) team is ~20 engrs in 3 teams responsible for ~30 services and we deploy stuff ~25x/wk.

Also a 'crunch' around the end of a sprint sounds like mini-waterfalls.

Re: Less is more agile

#66

Post by shade »

whynotminot wrote: post #55
shade wrote: post #33

Earlier quoted context omitted.

> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…

Who knew coordinating development work could be easy with one developer?

That definitely simplified it. :) That said, we could (and for a few weeks, did) bring in a second developer with no issues.

My last job had me on a ten person developer team and I would not try to use that process there - although I'd consider splitting that into a couple of smaller groups focused on a specific product/system and using a very lightweight process for those groups.

Re: Less is more agile

#67

Post by shade »

karmelapple wrote: post #54
shade wrote: post #33

Earlier quoted context omitted.

> The biggest difference I’ve noticed between Agile and agile shops is that ceremonies or lack thereof make no difference. The best project I ever worked on: one developer (me), one project manager on our side, one QA/test person at the client, and one manager at the client who was what we'd call a product owner on a scrum team. No ceremonies, no pointing, very little backlog grooming. Shared Bitbucket repo for issue…

Have you read Team Topologies? This sounds like a stream aligned team, albeit a small one, and sounds like you had great success.

I have not, but thanks for the recommendation - I just put it on my to-read list.

Re: Less is more agile

#68

Post by FpUser »

abacadaba wrote: post #53
FpUser wrote: post #32

When I hear agile and SCRUM I just want to puke. Luckily I've been agile free for all my programming life.

Need a job board for dev jobs that don't do scrum, seems pervasive.

>"seems pervasive"

Sort of. I find real businesses with real needs who hire me as a contractor to design / develop software. They have no extra time and money for propaganda. I work either alone or hire subcontractors for help. How I actually do development is my internal business. They do not go into that area.

Re: Less is more agile

#69

Post by pillefitz »

soperj wrote: post #62
dhasso wrote: post #56

I'm always very confused about this kind of statement: "Don’t estimate". To me, projects without estimates tend to take way too much time. It's also federating a team to have deadlines. But I agree that estimations often become a joke when your manager asks you to estimate something that you have no idea how long it will take. How to reconcile both? Being more flexible on the estimation? Taking them as a team goal an…

Estimating is a bit of a joke though. It's dependent on too many unknowns. Example: How long will it take you to get to China? It entirely depends on how you're getting there and where you're coming from. I can give you an estimate, but if the only known is that you're starting in North America, and you're going to be held to your estimate, you'd better give the estimated time it'll take to walk there. The real issue…

Then use ranges instead, problem solved

Re: Less is more agile

#70

Post by ineptech »

dfee wrote: post #46
ineptech wrote: post #42

I generally agree, couple observations: 1. If the people on the team can't change the process, it ain't agile 2. Sprints aren't a failure of agile, they're a failure of devops. Once you start deploying multiple times a day, nobody will care when one sprint ends and the next begins and it'll be fine 3. Estimates aren't literally the devil, execs need to have a rough idea how big it is, just don't get more granular tha…

Point 2 is very interesting. Any anecdata to corroborate?

Sure. I worked on a legacy (monolith, >5 years old, no automated test coverage) thing and managed the teams that turned it in to a modern (microservices, ci/cd, full test coverage) thing. So, kind of a naturally occurring A/B test.

Five years ago, we deployed once per sprint, and it was a big deal: the test pass takes this many days, the change management team needs this much time, etc. So quite often, finishing a story on day N might mean it goes out on day N+4, but finishing it on day N+1 means it'll take two more weeks, day N+18. That's where the urgency came from: that "tax" of lost time due to infrequent deploys. So there was a lot of pressure to get things into a given sprint. Hence, sprint commitments.

Now, on the same platform but with frequent deploys, we still have pressure to get a story done by a certain day sometimes, but the sprint cadence no longer affects our ability to do that. It goes when it goes. Without that pressue, we realized that sprint commitments didn't serve much purpose, so w stopped doing them, and we haven't missed them.

That's what I was referring to - it's not the sprint that matters, it's the "tax" on deployment time, which varies depending on where you are in the sprint. Take that away, and you stop caring where you are in the sprint, like a teenager in summertime losing track of the days of the week.

Post reply on HN