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 be amazing results everywhere.
Sadly most EMs have the training of a scrum master and never want to work to actually improve their process/discipline. The solution of getting rid of everything is a sound one because at least you can focus on the core agile ideas that make shipping software successful.
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.
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 productivity. Kanban is awesome because it doesn’t force us to spend hours and hours every week on ceremonies which don’t change the outcome one whit.
In my own business, after 2+ years of scrum - including hiring a CSM - I tossed out our entire process, and replaced it with backlog management and kanban boards. The only thing we kept was the (short) daily standup.
Productivity went through the roof for a number of reasons, not least of which was that because we could now spend the ceremony time working on actual code.
The killer is that if you try to tell people this, they think you’re inexperienced or did scrum wrong or you don’t know what you’re talking about. But to me Scrum is a two year black hole of stagnant product development that I will never get back.
> 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.
I guess my position is that we should assume our software engineers are professionals who are properly motivated to succeed, and with this in mind, we should take a priority-based, Kanban-style approach to building and deploying software, with significantly less emphasis on estimation and significantly more emphasis on prioritisation. I don't think anything I do is novel or special; it's just not widely adopted as far as I know.
I've been using a backlog-driven, priority-based approach in my own practice for the last 5+ years, which has been extremely successful at delivering products, but remarkably less successful politically. Non-technical management seems to have come to the conclusion that we ought to be able to accurately estimate the time it will take to build stuff, despite decades of evidence to the contrary. Loads of people argue that this is the "only way" but the processes commonly implemented are more about making management feel good than about actually getting work done. Unfortunately, I've found that making management feel good is often more important than actually doing the work.
All of that said, what I suggest is very boring: instead of spending the (significant) time estimating the effort required to implement each task, instead you should spend the time working with the client on prioritising the features, and internally spend time prioritising the decomposed tasks. What features/tasks absolutely must be ready by the deadline, and what can they live without? Can some features be shipped "incomplete" from your perspective? For example, can you deliver a veneer over a manual process on launch day, and automate the process later? If, upon inspection, a feature turns out to be extremely complex and time consuming, can it be re-prioritised? Can you spend time working on reducing the total amount of actual effort that's on the "critical path" to the deadline? Obviously some things just need to be done, but when you drill down you often find that a lot of time is spend on features and tasks that are not critical (by whatever definition you choose to use).
The idea is simply to make sure that the important stuff gets done first, so that you are in a position to launch as soon as possible. You can and should continue to work on the project after the launch day. This approach has many well-known carry-over benefits like the ability to start user and automated testing very early. Unfortunately, as mentioned, this can be very tricky to pull off politically, which I think is why it's not more common.
Once you get to this point then reporting upwards should be about features delivered, features we're working on now, and features that have not yet started. Somewhere in that list is a red line that says "we can launch now". You can directly measure velocity in terms of how many features are left until you are in the green.
I want to be clear that I think rough-order-of-magnitude estimates on work-in-progress and future work are perfectly fine and reasonable for internal use. What I am against is the use of deadlines and dates to manage the project as a whole. The goal is to deploy features, and that will take as long as it takes, and no amount of stomping of feet is going to change that, assuming you have a good team.
Ultimately what everyone wants is for the project to launch successfully. Software is very complex, and history (and theory) suggests that it is impossible to estimate accurately. The more time we spend on estimating, the less time we spend on working, and the more likely we are to miss our deadlines.
One final note. If you use JIRA, the backlog sucks (or at least it did when I abandoned it a few years ago). You need something that you can manipulate, that you can create different views, and that can collect information that helps you manage and prioritise it, since the backlog is orders of magnitude larger than the in-progress work and in my opinion is the actual problem that needs to be solved. I've personally used ProductBoard for many years but AirTable and even a spreadsheet is good.
I am keen to hear criticism and other ideas. My key thing is that saying "this feature should be finished by THIS DATE" is an absolute killer of productivity because of the amount of effort required to determine "THIS DATE" and the fact that the date is always wrong anyway.
> 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 their targets?
Come on.
The idea that "forecasting" and "agile" are somehow at odds with one another is a gross misunderstanding of both.
Edit: As an aside, that article's use of Google as somehow the paragon of software development superiority really dates it. Google is notorious, at this point, for being an unreliable software development organization. They fail to listen to their users by building features people don't want, canceling projects that vocal users do want, and shipping incredibly buggy products (Android 12, anyone?) All of this is, at least in part, caused by many of the problems the blog post highlights but claims have been resolved, including a lack of strategic cohesiveness and issues with building and maintaining staffing for projects that are no longer sexy.
> 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:
Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a priority-ordered list and velocity will let you give a "forecast".
Kanban doesn't "fix" this -- it just changes the frame through which deadline-buzzards get to look at it.
I would say, if you absolutely need an estimate on how long a project will take (and often you don't), do a proper study on it, don't just pull a number out of your a*. Software project estimation is doable, but it takes some effort. It (IMHO) cannot be replaced by a clairvoyance seance, AKA planning poker.
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 still applies: “better, faster, cheaper - choose two”. If you set a deadline then you have to be willing to drop features or quality, because Brooks already demonstrated you can’t add resources after you start.
Second, if you do need to set a deadline then prioritise it, stick to it and celebrate it. Too many times deadlines are used as a whip, and my or my team have wiped themselves out to meet it, only to be told it wasn’t really needed. This is insanely demoralising and strongly affects productivity in the long term.
My personal (and unpopular) preference is to prioritise completion of stand-alone features rather than building to deadlines, which means you can release a product at almost any time with fewer, but better quality features. This approach has a demonstrable positive impact on the ROI but because it’s more complex and provides less short term certainty, it’s frowned upon.
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.
My point was that OS dispatchers don't spend time working out how long things will take to compute, to allocate resources (such as CPU time) properly into the future; what they do instead is they just put the stuff to compute into a dispatch queue and go from there. Then if it's a novel thing or million times repeated thing doesn't really matter.
BTW, one indication that Scrum is bad is that nobody is doing its analogue (syncing everybody once a day?) in computing. Sane project management practices should be universal, and should also work for operating system schedulers.
Kanban was originally designed for production lines in car factories, so it works. If you go to any McDonalds and look at the screens in the back you'll see orders represented a lot like tickets.
In Agile, "points" are just an abstraction around work to try to normalize it in the same way that every burger+fries combo should be roughly equivalent.
This post is starting to fill up with what sounds like a kind of hopelessness mixed with anger against Agile. It's possible to do sprints, pointing, demos, and retros well, but you have to own it as the engineering team.
This means understanding and adapting the process to your needs. Agree on your definition of done. Set boundaries for pointing. Prevent confusing or unfinished stories from being point. Communicate how you work to the greater org, and get buy in. Use retros to constantly iterate and improve your process.
Oh management absolutely needs to skill up. One of the major reasons Agile annoys engineers is because the process is owned by an individual who doesn't understand why they're doing it, or how it can be changed.
Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.
"Just demand the respect that the business isn't giving you. What's the worst that could happen?"
You didn't say exactly that, but that's kind of the undertone of what you wrote.
If you live in the US and you demand your right to a fair trial, well good on you. But if you live somewhere perhaps less committed to such a thing, making the demand doesn't mean anything other than you're naive and foolish.
So it goes in some companies as well. If they don't have the values the demand isn't you being courageous. It's you painting a target on your back.
The country analogy is to point out that not all places have the same values. Standing up for yourself might work at some companies. At others it might get you fired.
My experience with Agile has been that it is a powerful equalizer of everyone on the team. The degree to which a person's productivity is equal to others on their team may impact whether they consider that a net positive.
> “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 things, they're fine - or at least engineering isn't going to be the deal breaker.
Estimates or no-estimates in these context-- who cares. Literally anything you do on the engineering side means nothing to the upside of the specific product line you're working on, and if you look around you in these contexts, you'll find gross and massive inefficiencies abound and none will have anything to do with your dev process, agile, estimates, no estimates, what-have-you.
For the rest of us, you live and die by execution, which includes your ability to prioritize what you're delivering, all of which means nothing if you're not estimating - however indirectly or directly you are estimating.
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?
The funniest agile system I've worked under was with a totally incompetent manager who graded us on number of tickets. Despite supposedly having a technical background he knew almost nothing about software engineering, and didn't care to learn, but needed to feel some sort of control so he would count up tickets each week and berate anyone who hadn't done enough.
Once I got over the initial horror it actually worked out pretty well. I would keep a stack of trivial work on standby for any time I needed to show some board progress and then used the majority of my time to dig into whatever work looked most interesting.
I've worked on about 10 different teams using some variant of Agile, and I only recall one which was able to achieve accurate estimates for a complex software product... What's the secret?
Story points are only the beginning. They are an estimate which must be updated during the planning meeting. Our planning meetings for a team of fewer than 10 people took the better part of an entire workday -- 8 hours.
What we did during those meetings was pick apart the user stories into small developer tasks until there was no task larger than 3 story points on the board, ideally all of them one-pointers, with one point being an estimated 1 hour of work.
We also spent most of an entire day for each retro meeting.
Edit: Our definition of done was signed off by the QA Engineer.
The (very real) problems the author cites are problems with management, not story points. "Pressuring or coercing... Immediately discounting... Comparing and judging..." It doesn't matter what project management tool/technique is the object of these actions; the actions themselves are the problem.
I hesitate to play the "you're just using them wrong/misunderstanding them" card, but it's worth at least alluding to its existence. Like any other tool, story points are powerful and helpful in the hands of people who want to and know how to use them to improve things, and difficult or even destructive otherwise.
The fact that this is an issue all of the time amazes me. Yes, teams have a different measure of how much work they can get done every sprint, but as long as that measure is accurate, it doesn't matter.
Here the thing: two teams may operate at completely different rates: One team (more experience devs with more mature technology) are going to be faster than a new team with new tech, even if they have the same number of devs. You can't just assume that both of them can do 25 story points of work every sprint. The teams can only go as fast as they can go. It's analogous to the fact that two different people have different rates of walking or running. You can't make them the same unless you are willing to lose efficiency of your fastest walkers/runners.
The fact that one team expresses the quantity of work they do (i.e., English vs. Metric) isn't important as long as they actually hit their estimates most of the time, and improve their estimation accuracy.
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 possible, leaving no concern for quality) in general with extreme prejudice.
If the people who started the computing revolution last century knew that their descendants would be attending daily standups and debating "story points", they'd never have done it--in fact, they'd have blocked it from happening in the first place.
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 have, at a truly well-run engineering team. She was fun to bounce ideas off of, and quick to rope in relevant experts, business or techincal. She also understood the value proposition of each feature, and could easily spot if you were wasting cycles on something unimportant.
Probably not coincidentally, this was the only place I've worked where KPIs were truly a useful way of framing our place within the organization.
I've spent a lot of my time helping ours grow into a collaborating by walking them through my expectations of a product brief and what we need from our user stories. They're also really good at helping with the release, managing story sign-off and communicating changes with the other teams (customer success, account managers, sales team, etc). A good product manager manages... the product. They also collect all the user feedback, validate feature requests with data, and act as a guard for the rest of their engineering team.
I don't believe this is true. Having any separation between engineering and product is a defect in the organization. I think the best you could argue is that it's a necessary defect, since it is too rare to find someone who can do the engineering and also keep a perspective on the product. I would argue the opposite, hiring engineers who can't make smart product decisions is like dealing with a shortage of bus drivers by splitting up working the steering wheel and working the pedals into separate jobs. There is some kind of rational thinking behind a strategy like that but it is obviously doomed to be a disaster. Hiring PMs is less obviously stupid, but just as inevitably it is a disaster. If you don't agree, I'm afraid you are like someone who has been on fire their entire life, who will calmly explain how being on fire is fine, and really it's a benefit especially on chilly days. If you ever had the chance to not be on fire for 5 minutes you would stop defending it.
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.
Big A Agile is what happened after management consultants got hold of little a agile and its manifesto.
Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
I came to think that the whole Big A Agile and small a agile is also just an excuse to put the blame elsewhere.
We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process.
And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh
'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.
Author here, yes, I fully agree about all you said especially certifications and dogma. How can you have a certification, in something that is a list of half a dozen goals? By getting a certification in something else, that isn't Agile!
> managing people instead of about satisfying customers.
I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?
I’ve been feeling a similar sentiment. This sprint some higher up agile coach or whatever their title is has been observing our team and making sure we follow the agile law to a T at the cost of real work efficiency.
> 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,
Author here, this was one of the motivations for writing this and the other article linked at the start. I've seen agile actively harming maintenance and quality more times than I've seen it ever help maintenance or quality.
You know things are fucked up when you need to put technical debt, refactors, library updates, etc down as "stories" (erm hello, where is the customer story in "fix that giant performance TODO") instead of just doing them. Sure, we can just carry them out to avoid the wrath of the scrum master and co, but then you have to balance time between doing the stories, and fixing bugs.
Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers.
> Fuck user stories, fuck sprints, fuck Jira, and fuck product management
That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization where process flows down from management at the top to the developers at the bottom that you speak of is what is colloquially known as 'Waterfall'. This 'Waterfall' organization structure is what many believe the Manifesto was written to counteract, so it is interesting that you’re now calling it Agile.
That is Agile of the noumenal realm. You will never meet it, just as you will never sit upon the Platonic ideal of a chair. Agile, if one deals with it, is Agile-in-the-wild. Compare the original teachings of a religious leader with what you find in the followers.
Ah, but you could say, "That's not Agile's fault that people don't live up to it," but in a sense, it is, because Agile did not bother to anticipate that people would fall off of the path. Agile has no orthodoxy. Agile does not suggest punishment for bringing up deadlines. This has allowed people to pick-and-choose.
> "That's not Agile's fault that people don't live up to it,"
"Not living up to Agile" is one of its principals: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." That's not what we're talking about, though.
> Agile did not bother to anticipate that people would fall off of the path.
This isn't a case of falling off the path, it's a case of not even being on the same planet. Agile is written about the things you need to think about if developers don't have managers overseeing a project. The OP was talking about what managers are doing. They are at completely different ends of the spectrum.
If you want to use a religious analogy, this is like there being a religious leader preaching about God and a group of people who believe God doesn't exist. Logically, you wouldn't lump them together. They would be seen as distinct groups with opposing thoughts. Exactly how we treat this situation in a religious context: For example, Christianity and atheism.
Agile is the No True Scotsman of development methodologies. It claims not to be prescriptive but if you don’t get good outcomes, you’re doing it wrong! Meanwhile you should follow these 5 rules, but remember there are no rules.
Look, when a job req goes out and it says "experience with Agile development methodologies" what it means is "experience doing Scrum with Jira". The Manifesto has sweet fuck all to do with what is meant when companies say Agile.
When a job requirement says "20 years experience in Rust", we know that businesses make things up. On HN, however, we can talk about reality, not what is made up for advertising purposes.
It's not just advertising. Once you join the company, they tout how Agile they are to themselves while still doing Scrumfall. And if you protest on the grounds of Scrumfall not being in line with the Manifesto, you could be fired for not being Agile enough.
So, in the corporate world, pretty much Agile==Scrumfall (and SAFe). Executive management wouldn't have seen any benefit to Agile otherwise. The only reason why companies adopt Agile is because of the fine-grained measurement and control promised by Agile consultants.
Now get back to work on the stories planned for this sprint. You have sprint commitments to meet, and others in the release train are depending on those deliverables.
Author here, I too have never seen it mean anything else either. Occasionally replace Jira with Azure DevOps at some places, but overall yes the sentiment is the same.
Much of the usage of the term Agile now refers to Scrum which took Agile and made it into something digestible mb large corporations and business people and made it easily sellable and reproducible. It's a corruption of Agile. Even the term "sprint" makes me angry. We aren't sprinting! This isn't even a marathon! We are running forever and I want to run fast forever, not sprint and burn out after a short time.
That is not at all what waterfall means. And calling "Agile" as the same thing as whatever the Manifesto says is like calling any other religion whatever their holy book "says".
You’re right in your second point, at least. Whatever you develop out of the thoughts of Agile won’t be called Agile. It is its own thing, with whatever new name you decide to give it.
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 work available for other developers to see, work with people who can be motivated without a manager hovering over them, etc. All obvious when you think about what role managers fill and what you need to do if they're gone, but still a decent reminder if you're serious about going down that road.
It's not something you do, rather something you can think about if you've decided managers aren't the right fit for your project.
Agile is assuredly garbage but having every development company use the exact same process and terminology is too valuable to give up. It reduces training times, increases tool familiarity, and gets the process out of the way of developers.
> Agile is assuredly garbage but having every development company use the exact same process and terminology is too valuable to give up.
But...Agile doesn't involve that. Even when the same words are used, they don't have the same meaning, often, and the substantive processes even within vaguely Scrum-ish methodologies vary widely.
What has been said so often on HN, AGILE started as a great tool that turned into a cult with no knowledge of why the things being used were being used. Its terminology and practices became mysticism and ritual, with common sense thrown to the wayside.
There are exceptions, but in far too many companies AGILE has become a religion that slows the workforce down with high priests who insist that their ritualistic practices be followed and their tithes be paid =[
We should be fighting against the standardization of the industry because it allows more competition for wages.
On the other hand, damn near every company seems to only want to hire 'senior' developers who can deliver working software in spite of process, which I assume is somehow related to all the nonobvious process skills being commoditized.
Here's one to add onto your list: pair/mob programming is bosses weaponizing employees against each other to "prevent goofing off".
I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-shareholders--that it not be done.
Software is the only thing I can think of where the input effort of creating it is completely divorced from the output work it can churn through. The right program at the right time, written in 10 minutes by just the right person, can save hundreds of years of otherwise manual labor.
There's a sort of sense that arithmetic got us out of the stone age, calculus fed the world, computer programming gave us the stars. That sort of power is far too important to imbue into corporations.
When you get a large group of people together, they start to think of themselves as Important. And when people think of themselves as Important, they start to think the work they do is Hard. And when they think the work they do is Hard, they start to think the software to help them do their work should be Complex. And none of it comes out of anything other than "we have a large group of people together."
Like, microkernel operating systems have a reputation for being slow based on early experiments with them from the 1980s. There are modern microkernel systems that are perfectly fast and efficient and yet people still think "monolith go brrrrrr" and not "all my software lives here" is the reason Linux is any good.
Like, I've seen people pitching blockchain-based solutions for municipal information and issue-reporting services, like anything beyond the most basic, not-completely-incompetent, traditional RDBMS is really necessary for such a project.
Like, there's a serious cohort of economists that think that the best way to handle social safety benefits is to just give them to everyone who asks, no questions asked, because otherwise the management of welfare benefits gets to be so expensive that it eclipses any potential savings against "fraud". And I'm inclined to believe them.
I see people talk about "there's no such thing as a 10x programmer". I think these people have been stuck in ossified institutions so long that they have no idea what it looks like to see a person fly. Cut away 90% of the currently employed software developers. Dissolve the Googles and Facebooks of the world. Don't replace them with anything. Leave us with the 10% of crafstpeople who can actually work through a problem on their own. And make them report directly to the C-suite. No more middle managers. No more grunt work of CRUD forms. If it can be done on paper than it's a waste of time to write software to do it.
[0] AKA this is a feeling, not something I've created a double-blind randomized trial to study, dear pedantic HN reader.
I agree with most of this. I’ve done some stupidly complex things using microservices, and I’ve come to similar conclusions - that there are few or no cases where you need a huge monolith, and it’s much better to have small teams working on small tools. Once you get things working at this level, everything becomes easier.
Setting aside the Linux kernel, this is how Unix itself works, and one of the reasons it was successful.
I don’t agree that we should shut down all the “1x” developers though. I think everyone deserves to love their work and people will excel when given the chance. But throwing them against a massive monolith that takes years to understand is dead certain to make them feel stupid and go slow.
Yes. I don't really think that anyone should be artificially prevented from doing the work they want to do. But that said, most of the work that people are engaged in is just a complete waste of time. And that's mostly because Large Corporations are the ones telling them to do it.
There are a great many products I don't use, or use much less often, due to numerous bugs and painfully slow performance. Those qualities are highly correlated with engineering quality, in my experience.
I worked at a company where the scrum master told us that a story point had to be a fibonacci number. Has anyone heard of this?
The original Agile Manifesto demonstrates the collective wisdom of people who have written a lot of software. Note that the Agile Manifesto doesn't mention a certified scrum master, or any role similar to it. It says that business people and developers should work together. It does not say that a certified scrum master should leave the stand-up meeting every morning to spend an hour giving a status report to the CTO.
Fibonacci story pointing is good, at least in my opinion.
It removes a lot of the granularity of pointing, and forces the larger points to grow very fast. You still have some nuance between 2, 3, and 5 pointers, but once you start getting past that the numbers jump to 8, 13, 21, very fast. You don't need to spend time with your team debating whether something is a 5, 6, 7, or 8 pointer, it's closer to a 5, or its closer to an 8, if it's higher than an 8 it jumps up to 13. Less time spent circling around an exact number and quicker to get to a "is big" "is medium" "is small" "is trivial" decision.
Author here. Glad to see my article resonate with so many developers, both on here and reddit. I was expecting a lot of anger and spitting of feathers but as it turns out many people are really not happy with agile (or as I like to call it sometimes, badgile). I think, as an industry, we're all a little frustrated and fed up of this whole debacle.
Yeah, it's all a garbage dump. The only thing that matters in most cases: roughly how much time is this going to take and does that amount of time change the task's priority. If there are external teams who need to have the timelines communicated to them, communicate it to the degree you are certain, and then calm down and do the work.
It is worth noting that Scrum, for one, does not require (or even recommend, at least according to the latest Scrum Guide) story estimating or pointing.
I would agree that in practice all of those anti-patterns related to story estimating/pointing can work against the values of the Agile Manifesto.
Scrum, Kanban or more general Agile are like recipes. They describe the process and ingredients exactly but everybody does it their own way anyway. It is just a theory, you have to execute it and adapt it to whatever you have available.
I have never seen a ton of value in the exact number of story points, but they are a good way to have the "30 minute debate" that the author decries. If a task is so unclearly written that the team can't get a rough idea of the complexity in a reasonable amount of time, then it's a signal that the story can't be done or that something needs to change; more knowledge sharing, clearer success criteria for the story/task, etc. I get that the meeting is annoying, but not doing the discussion is just going to hide other problems. The longer you hide problems, the more severe they come. Having no idea what the "done" condition is in any of your tickets is tech debt just like long dev cycle times or code that breaks production every time someone touches it; at the project level instead of the code level.
If the only problem is deciding between a 1 or a 2 though, I'd just remove "1" from the list of options.
Not having good definitions of done is also a great way for a team to feel like it's treading water eternally. Small, achievable goals are a hack for team morale. (The trick is making sure that the small, achievable goals roll up into valuable long-term work.)
I think the author was saying the 30 minute debate is a problem when deciding between 1 and 2. 30 minute debate over a "100" might be worthwhile, as long as you're doing it as part of refinement and not during planning.
Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had votes split between 1 and 2 a number of times. That's a 2.
(My planning poker algorithm is:
1. Vote without discussion.
2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13).
3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..."
4. GOTO 1)
This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own.
I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!
1 point per ticket so you can see the jira metrics and try to break down tickets enough that everyone feels they have enough information to get started and understand why the work is valuable.
"points" are just a way to avoid being held accountable. If we were to use hours (even buckets of hours, aka: 1, 2, 4, 8 hrs) we'd be better off. It'd be more transparent and while it may differ between team members, we can hold people to account who over / under deliver based on their estimations. The entire point is to estimate velocity (supposedly), so why not have a feedback mechanism that's let engineers learn to estimate better; instead of using an abstraction.
I for reference, have multiple agile certifications and just don't understand.
That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug.
If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than producing the _right_ work. This will last for a few months, at which point I will realize I'm burned out, working inefficiently, and writing bad code, and I'll find a new job on a different team that doesn't treat its employees like train conductors.
True.
But on the other hand an experienced developer usually can give a reasonable estimate. An if he says: "about two days maybe a week" then that is you best estimate. Using story points is just another complication.
And points do not stop anyone from holding you to account, if that is what they want to do.
Because now your guessing on minutiae and will inflate the hours to reduce pressure. Or spending enough time to solve the task "estimating" the work due to the need to derisk it. Thus alleviating the pressure of being accountable.
Complexity points has value since they can be used in aggregate to estimate what a team is capable off, assuming the estimations on average are consistent between cycles.
The point of the numbers is to be a tool for the team, not management. If they get reported up it should be at most one level (immediate supervisor/lead, not middle or upper management). The information provided, assuming that the team is moderately consistent in their point assignments to tasks, is: Are we holding steady, slowing down, or speeding up?
Steady and accelerating are the good cases, slowing down leads to questions. "Why did we slow down?" "Oh, that task we gave a 1? Turned out it was actually huge because it involved X which none of us noticed or was more broken than we realized. Took up the entire time." Or "We brought two new people onboard and were spinning them up. They aren't productive yet and our experienced people were spending the time bringing them up to speed. We should get back to the normal flow in a few weeks." Or "We have no idea" which drives more questions. Or "We brought on two new people and spun them up, but now their estimate inputs are changing how our tasks are scored so it will take a bit to figure out our new baseline."
All of that assumes the team tries to be consistent in their scoring and is reasonably stable in its composition. If you're changing out team members frequently, then there is no value from points (because they won't be stable). If your team decides to fuck with it by rolling a die and using that for each one, then there is no value either.
When you change your processes in some way (and assuming a stable team and scoring), then you can also use the velocity over a series of sprints to evaluate the effectiveness of the change. If it hurts, you'll see a long term decline, and if it helps you'll probably see an initial decline (learning) and then improvement.
The point of "points" is nobody can estimate how long a task will take and it gets worse the larger it is. So it's better to have reference tasks of a certain size and complexity that you do know how long they took and compare to those to get a general idea. You could use hours in that context but it's trying to make you think is terms of size and complexity not hours.
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 be amazing results everywhere.
Sadly most EMs have the training of a scrum master and never want to work to actually improve their process/discipline. The solution of getting rid of everything is a sound one because at least you can focus on the core agile ideas that make shipping software successful.