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

Eight points for one team is two points for another team

lloydatkinson.net

Post reply on HN
Print view View original

91–100 of 105 posts

Re: Eight points for one team is two points for another team

#91

Post by wellpast »

lloydatkinson wrote: post #64
wellpast wrote: post #29

> “Building the wrong thing on time and within budget doesn’t buy you much.” Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of t…

> all of which means nothing if you're not estimating It also means nothing if all your estimates are so totally wrong and not based in reality, as I mentioned a few times in the bullet points.

Same is true for every other aspect of your work. If your code is wrong, then you’re losing too. You’re saying a tautology.

Being able to estimate, being able to market, being able to code — these are all competencies.

Re: Eight points for one team is two points for another team

#92

Post by stephendause »

BaseballPhysics wrote: post #84
js8 wrote: post #12

This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.

> Kanban is essentially abolishing of any forecasting This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. Do you really think the car industry, where Kanban originates, doesn't care how many cars they're going to produce in a quarter, or whether they're ahead, behind, or on track on hitting…

> This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done.

That's interesting to me as I hadn't heard that about Kanban before. Do you have a particular reference in mind that you think describes this well?

Re: Eight points for one team is two points for another team

#93

Post by aaomidi »

thenerdhead wrote: post #7

This is so true. I've been on teams that did 100x work with like 3 engineers. I've also been on teams that do near 0x work with over 10. What I can confidently state is that you must work the people and then the process to improve anything. We need to stop adopting things just because other teams use them or because they are an "industry norm". If we just truly kept true to the original agile manifesto, there would b…

Our interview process literally selects for people who can spend 20 minutes+ discussing the various ways to approach a binary search.

If you're hiring someone who can...somehow make up enough content for 20 minutes about stalling binary search implementation your org is literally gonna turn into places that has tens of engineers and gets nothing done.

Re: Eight points for one team is two points for another team

#94

Post by pavel_lishin »

doctor_eval wrote: post #52
js8 wrote: post #12

This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.

I haven’t read the article (yet) but I came to the same conclusion many years ago. In a recent previous thread here on HN I was roundly criticised for saying that due-date driven management is not effective, but that’s what scrum has become, and todays thread is exactly what I was thinking about. My experience in a few businesses is that Scrum as it is generally practiced in industry has been an absolute disaster for…

> In a recent previous thread here on HN I was roundly criticised for saying that due-date driven management is not effective, but that’s what scrum has become, and todays thread is exactly what I was thinking about.

Do you have any recommendations for scenarios where there are due dates? I work in a field that is largely focused around dates that aren't really negotiable; the school year ends and starts and school budgeting decisions have to be made at a certain time, so if we're rolling out certain features, they really do need to be available in, e.g., August when school starts.

Re: Eight points for one team is two points for another team

#96

Post by BaseballPhysics »

stephendause wrote: post #92
BaseballPhysics wrote: post #84

Earlier quoted context omitted.

> Kanban is essentially abolishing of any forecasting This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. Do you really think the car industry, where Kanban originates, doesn't care how many cars they're going to produce in a quarter, or whether they're ahead, behind, or on track on hitting…

> This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. That's interesting to me as I hadn't heard that about Kanban before. Do you have a particular reference in mind that you think describes this well?

First off, it's important to understand that Kanban relies on a backlog built of stories that are all of similar size and complexity. Yes, that means you need to estimate. But those estimates come in the form of "is this roughly as complex as other work the team has done?" So it's a lot less onerous to assess.

Then you can measure throughput (number of stories per unit of time) and cycle time (amount of time a story takes from start to finish).

Using those measures you can forecast, with monte carlo simulation as a common method. Here's a book on the topic:

https://www.amazon.ca/Forecasting-Simulating-Software-Develo...

There's plenty of other resources about this if you bust out your google-fu.

Re: Eight points for one team is two points for another team

#97

Post by doctor_eval »

js8 wrote: post #86
doctor_eval wrote: post #83

Earlier quoted context omitted.

I’ve said this previously but I don’t agree that software estimating is possible in theory. It’s a form of the halting problem. You can’t, even in theory, know how long something will take until you do it. It’s certainly possible to estimate to a rough-order-of-magnitude but the problem is that the ROM quickly becomes a target, and then a commitment. I have a couple of positions that I take. First, the old adage stil…

I think in pure compsci theory you might be right, but in practice (industrial SW production), we usually limit ourselves to algorithmic solutions that do not involve halting problem, so estimation is possible. For example, an upper limit for a rewrite of a system is how long it took to create the original system (provided you understand the tradeoffs and issues of the original architecture).

I don’t understand. The halting problem says you can’t tell if an algorithm halts without running it - you can’t be sure any program will run to completion in a specific time. It applies to any non trivial program.

And it’s well established that a rewrite is dangerous. The second system effect suggests that rewrites will always take much longer.

Re: Eight points for one team is two points for another team

#98

Post by woojoo666 »

wellpast wrote: post #31
woojoo666 wrote: post #24

I use story points and estimation for my own personal projects. They are private numbers that only I can hold myself accountable for, so there's no reason to be dishonest. And they help me plan and gauge my trajectory and what I need to prioritize.

This is exactly what I do. I do this in my job as well, but privately. Making myself my own product manager. Do you use a tool to do this? Spreadsheet?

Plain text docs for now, looking for free open-source kanban in the meantime

Re: Eight points for one team is two points for another team

#99

Post by placidpanda »

notjustanymike wrote: post #13
21723 wrote: post #2

Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as…

Your anger sounds directed at the dysfunction within your organization. In particular if you hate product management then you've clearly ended up in a bad place. A good product manager is a joy, someone who is a partner to the engineering team instead of an antagonist.

I'm a product manager. His post doesn't seem unreasonable.

Product managers are often hired to be a cat's paw for an unsustainable and/or ineffective way of getting technical work done. This is what many businesses want when they hire into product, because this is a more convenient explanation for why things aren't better than any alternative (such as you're doing too much stuff, you're building the wrong things, etc.).

This selects for people with the skill and temperament to thrive in this role. Being a bullshit artist is a great fit. Being a pushover and repeating everything your stakeholders say is easy. Asking difficult questions and being a skeptic is hard and doesn't make you popular.

Re: Eight points for one team is two points for another team

#100

Post by ajmurmann »

randomdata wrote: post #50
ajmurmann wrote: post #40

Earlier quoted context omitted.

You can build your own processes around Agile principles. As long as you don't carve the processes in stone and revisit them you still can be Agile.

Reading the principles of Agile does not make what you're doing Agile any more than reading the words of the bible makes what you're doing Bible, even if you took something useful out of that reading. Whatever it is you end up doing is what you decide to call it. Agile is more like a checklist of things to remember if you're going to operate without managers. Like, stay in touch with the business people, keep your wo…

Did you mean to respond to someone else? I for one never said anything about reading Agile principles making anything Agile.
Post reply on HN