Hacker News Reader

> I have never once seen or heard of any Agile process anywhere actually working with any degree of success.

I ran a team were we shipped (firmware!) every 3 weeks.

After the first year of tracking all our numbers we were able to hit our estimates within a few hours +/- for the entire team.

3 week sprints, 2 weeks writing code, 1 week testing and bug fixing.

It wasn't perfect, and learning how to do it was painful, but once we got going it worked great.

We didn't adhere strongly to any one guiding principle, but being able to use sprints to align work across multiple teams, and as a planning mechanism for management was incredibly useful.

"Our breakdown of that feature means it'll take 3 sprints in total, the last of those sprints the work is split across 2 devs, if one of those devs gets reassigned it'll take 4 sprints."

Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating, and knowing how far to break work down. There is of course a trade off between gains from breaking work down, and time spent doing the breakdown! Several months were rather painful when we went too far one way, and then inevitably the next few months swung too far in the other direction.

But in the end? Yeah it all worked out. We figured out what length of sprint worked for us, what type of estimation system to use, and how much work to put into our planning sessions.

FWIW one of the huge benefit of doing the work breakdowns is being able to see opportunities to parallelize work, and also to see natural stopping points.

My team was lucky to have someone almost full-time dedicated to managing our workflow, without that the entire process wouldn't have been tenable. The tools just suck up too much time.

> “Being forced to actually plan work out, and then being held accountable for the hours, meant that over time we got good at estimating”

I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go.

But regardless it sounds like your process was fairly different from Agile. The only superficial similarity was having some notion of a regular sprint cadence, but cadence based scheduling is common to many project management strategies. It sounds like you had something very pragmatic for your exact situation, which is great — that’s the whole goal, the very thing Agile paradoxically does not conceptually support.

> I’m skeptical of this, because even working in a team that had many person-decades of experience of estimating software delivery, the consensus opinion was that nobody’s estimates are worth anything and that the business would actually be worse off using estimates even as mere guidelines than just working on things, hitting blockers, and adjust expectations as you go.

I usually agree, but we were in a bit of a special situation:

1. In house designed and built custom RTOS

2. In house designed and built custom hardware platform

3. Our entire UI framework was highly customized by us, for our specific needs

It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible!

> the very thing Agile paradoxically does not conceptually support.

Early on, a few of the more senior engineers wanted everything to be done as one big design up front. That is after all how embedded hardware projects are normally delivered. (And for hardware that makes a lot of sense, lead times are a thing!)

The idea of shipping embedded firmware every 3 weeks is considered insane by many people. Heck I think that throughout the industry it is still considered insane.

But if we had not pushed for "agile", users would have suffered. They wouldn't have gotten the incredible stream of features that they did, and the teams wouldn't have been forced to maintain constant stability and code quality.

That idea of "always ready to ship" is one of the tenants of agile. Of course having milestones is common, but "our code is always good" is not common, and it is one of agile's differentiators and adhering to that leads to systematic changes in how teams function.

1. In house designed and built custom RTOS
2. In house designed and built custom hardware platform
3. Our entire UI framework was highly customized by us, for our specific needs

It turns out, when you control all the variables, making estimations becomes possible. It isn't easy, but it is possible!

That's an interesting set of observations there. I've been wondering for a while whether we -- as a field -- have been systematically underestimating the cost of using libraries. To my eye, the anecdata definitely seem to be on the side of projects going more smoothly when the dependencies are few and well understood.

Does anyone know of anyone doing research into this kind of thing?

I'd personally say libraries save time in net, but they add unpredictability.

Especially for experienced devs who have written framework code before. "How long will it take you to write a graphics rendering routine that you've previously written on another project" is easier to estimate than "does this feature in the graphics library we are using work?"

The library probably works, sure, but when it doesn't the problem can become an almost unbounded time sink.

Yes, I think I'd agree with that. Good judgement can potentially help to avoid the unbounded time sinks. I've met a few people who's opinions I'd generally trust in that regard, but it seems to be a hard problem, and so far I'm unconvinced by any claimed heuristic solution (in particular, the approach of picking "active" libraries on the basis of lots of commits on Github seems more likely to get you churn, rather than support when you most need it).

I also think there are some break-points where adding libraries can change the nature of a project significantly. Think of old-school Javascript, loaded directly with a few script tags. In general "new style" JS (with many small libraries, a bundler, and probably some other tooling) brings some noticeable advantages (at least for larger applications), but you definitely lose something relative to the "no tooling, just hit reload" edit-test cycle.

I've worked on an agile team (specifically XP). The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those.

Also, XP was very into feedback. "How much did we get done in the last two weeks? How much did we think we were going to get done? Let's use that to adjust our estimates going forward." This was actually done with story points, so that when we "adjusted", the units of estimation stayed the same (that is, an item that was 4 story points before was still 4 story points), but we realized that the team was only doing 12 story points per 2-week sprint, instead of the 20 that we expected.

And yes, it worked very well for us, and it was truly agile.

And I disagree with you that agile doesn't allow something tuned for your exact situation. Or rather, agile allows that, even if Agile doesn't. We'd sometimes say "For the next two sprints, we're going to tweak our approach in this specific way. If it works, we'll keep doing it that way." That is, our process was one of the parameters we could adjust.

> I've worked on an agile team .... The idea there was that estimates diverge from reality past 3 weeks. If the estimate is bigger than 3 weeks, break it down into smaller pieces and estimate those.

That's not really all that agile. The agile teams I've worked on try to break things down much smaller, ideally half-days or less. Any estimate of how complex some task is, is often off by a factor of 2, sometimes much more. Only by breaking down tasks into small bits can you really start getting a handle on your velocity and complexity of a project.

Not true at all. Every increment is supposed to be shippable and better quality than the one before. So the chunks cannot be too small or you risk never shipping by never shipping critical functionality that is hard to chunk, or instead you end up with long stretches where software does not work and is not testable.

This also ignores the fact that there are evolutionary dead ends and digging yourself out of such a hole is hard.

> or you risk never shipping by never shipping critical functionality that is hard to chunk,

#ifdef is a thing and it solves this problem.:)

For more modern teams, branches also work!

> you risk never shipping by never shipping critical functionality that is hard to chunk

You don't have to be perfect at dividing up a big project, but you should at least try. Breaking down big pieces of functionality into smaller pieces is one of the core tenants of Agile.

In fact, your approach has far more risk. By refusing to try to break things down into smaller units, you risk not shipping anything because every feature is deemed "critical".

It’s so funny to hear things like this. I’ve worked in places where veteran, highly trained Agile coaches insisted that estimation had to be highly accurate at the quarter-long OKR level all the way down to daily programming task level.

It’s part of the problem with Agile. It means all things to all people, very much like denominations of a mainstream religion.

You’ve got your small estimates people, you’ve got your big estimates people. You’ve got your no-meetings people, you’ve got your tons-of-meetings people, you’ve got your every-iteration-has-to-be-shippable people and you’ve got your what-about-fundamental-research-(and-don’t-you-dare-say-spikes-or-timeboxing) people.

And all of them believe their way of doing it “is Agile.” So the term pretty much has no meaning in practice apart from some juvenile Ten Commandments sort of phenomenon where the only commonality in all of it is time-waster meetings like stand-ups and backlog grooming.

> all of them believe their way of doing it “is Agile.” ... the only commonality in all of it is time-waster meetings like stand-ups and backlog grooming.

Have you ever tried alternative approaches to software development? I suspect that the main reason you're frustrated with Agile is that you have never dealt with it's predecessors. There is undoubtedly wasted time in Agile, but with other processes, it seems like the goal is to maximize the wasted time.

I do believe smaller chunks are better than larger ones, but I'll happily take larger chunks over going back to a waterfall process.

I have worked on many Waterfall projects while at a defense research lab in the late 90s / early 00s. For several projects, it worked quite well, though none of this has anything to do with Waterfall being good. Waterfall is pretty bad, but success is at least possible because it allows for long-term commitment to a plan that can’t (as) easily be subverted by politics as in Agile, where politics doesn’t even need to do the pretense of coming up with an excuse because the built in excuse to mandate ill thought out context switches is ever present.

What I have seen really work are self-organizing policies where teams decide on their needs on a rolling basis. No prescriptive requirements.

For example, Agile might suggest teams can determine what type of sprint length matters for them, within some generally narrow range of sprint lengths.

But a good process will have no concept of a sprint or regular cadence, since it will be allowed to be different for each person and vary by project.

Another example may be that Agile offers flexibility to do research tasks as “spike” tickets or time-boxed regular tickets, so that the scope of a research task is forced to fit in with the iterative nature of Agile.

But a good process will not define a limit on the scope of a research task and will trust the engineer or implementer to choose when to curtail the scope based on the that person’s trusted understanding of the trade-off of probing more vs doing work on some other area, and that other people are likely not in a position to know better if more research investment is better than context switching.

Agile might suggest that at the completion of every sprint, the overall project is in a deployable / shippable state.

A good process would instead defer to the engineers or researchers to own the decision on a case by case basis about whether extended “partially implemented” states are better than the intermittent overhead of needing each change to satisfy delivery constraints.

Basically Agile pays lip service to infinite flexibility, but in reality is quite dogmatic about prescribed process. With Agile you are “free to customize” a series of prescribed global properties like fixed cadence, iterative delivery, etc., but you’re not actually free to arbitrarily disregard those things at whatever moments you need to disregard them.

The minimum condition of any good process is that the engineers and implementers are empowered to ignore and override any and all aspects of the process’s prescribed requirements at any time for any reason, and that the principle thing the business does is to trust the engineers and implementers to selectively disregard fixed processes at the exact moments when doing so is what’s best for the product & customer.

For example one way that Waterfall permits this where Agile doesn’t is to allow engineers to refuse scope change requests from customers. It can be crucial for making a customer happy to tell them “no” and refuse to change your existing plan in the face of new requests. You won’t always do this, of course. Often you will make changes that customers demand. But a good process leaves that freedom to veto a customer request up to the engineers and trusts that they won’t abuse that freedom. Agile on the other hand intrinsically revokes that freedom and takes the attitude of not at all trusting engineers to make that decision.

Agile, despite the lip service, categorically disallows this by its very definition, all the way back to the Agile principles themselves.

> I have never once seen or heard of any Agile process anywhere actually working with any degree of success.

We built Bioshock using agile.

We didn't use any prescribed agile methodologies like SCRUM, but we developed a process that worked for us based on agile core principles.

update: Sorry meant to reply one above.

I guess it would all hinge on what exactly is meant by “we developed a process that worked for us based on agile core principles.”

The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile, even though it may (likely) have nothing to do with anything that could be said to resemble Agile.

> The risk of No True Scotsman applied to Agile is that you go and find a process that works, and because it works, it gets labeled as Agile

That's more consistent with the Agile Manifesto than calling any of the concrete development methodologies that come out of the Agile community “Agile” merely because they emerge from that community.

Choosing the process that works in practice for your team in their concrete situation is pretty much the whole of the Agile Manifesto. The failure of the Agile community is that it has almost no literature or body of knowledge oriented toward how you do that, just a bunch of concrete development practices without tools for adapting them or choosing among them.

OTOH, tools operationalizing essentially the values of the Agile Manifesto do exist in the Lean community. (Which is why I sometimes, when feeling particularly snarky, call Lean “Agile, but for engineers” or “Agile, but usable”.)

If this is true, it means Agile has no definition, it’s a vacuous term. If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work.

It reminds me of a great LessWrong quote, “If you can explain every outcome equally well, you have zero knowledge.”

> If this is true, it means Agile has no definition, it’s a vacuous term.

No, it's just the definition is not in the space you (and to be fair, lots of other people) seem to want it to be in.

> If “Agile” == whatever works, then Agile’s not a thing, it cannot differentiate between what works and what doesn’t, and it can’t predict in advance what will work.

“Whatever works” is definitely a thing; however, the kind of thing it is, as you note, is not a tool for predicting what will work.

“Agile”, though, while not that kidnd of tool, is not exactly “whatever works”, either (and here I'm talking about the Manifesto; it's worth noting that the Manifesto, the Agile community, and the concrete methods labeled as “Agile” are not precisely in alignment); it is a critique of (accusation against? hypothesis about?) the status quo at the time it was written attributing its disappointing performance in finding what works to three errors:

(1) Failing to recognize that what works, at the level development practices were generally recommended, is not a universal across software development, but a function of the particular members of the team and their relations, which not only vary between efforts, but vary over time within one effort.

(2) Prioritizing written artifacts of the development process more than is justified by their utility to software development.

(3) Preference for arms-length negotiation and implementation to collaborative involvement of the customer with the development effort.

No, really, it would mean the term is literally vacuous, as in an actual tautology, Agile succeeds because Agile is defined to be whatever has succeeded. It’s not really possible to disagree on it.

> Our breakdown of that feature

> actually plan

sounds like waterfall with extra steps (like a lot of corporate agile)

Breaking down features into smaller chunks isn't waterfall. There seems to be some confusion that there are two ways of delivering: agile vs waterfall and if it isn't one then it is the other.

Waterfall is about the set of phases and the staggered project transitions. See https://en.wikipedia.org/wiki/Waterfall_model

Agile software development is about 'advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages rapid and flexible response to change'. See https://en.wikipedia.org/wiki/Agile_software_development

For a very large feature, agile deliveries will split that larger feature into chunks and deliver those. That reduces risk and can get feedback ('adapt') to how that 'chunk' has gone.

Edited for grammar.

There is one problem in that the design, vision or story (high level requirement) can get lost in all of this. This is how many agile projects end up, doing churn instead of satisfying the user more with every iteration.

Typically this results in a mishmash and never finishing. (instead the thing is dropped) Bioshock itself still has game breaking bugs nobody will ever fix - and its story wasn't too iterative.

The process is not immune to building the wrong thing at all - devs always want to side with easier vs better and agile pushes them even more by forcing things to be independently chunked...

>I have never once seen or heard of any Agile process anywhere actually working with any degree of success.

I worked on two internal tools at Etsy that used the most agile of agile processes (no product manager or project manager, no estimation, no timelines and burndown charts, just the people who used the tools and the people writing the tools, a big physical board with cards on it representing the work that needs to get done in priority ordering, and daily standups with the manager of the engineering team. The whole team would have retros every two weeks that were kind of social, kind of project management, kind of technical.

They were the two most wildly successful projects I've ever worked on and the tools were well loved and last I checked a couple years ago, at least one was still being used about 4 years on. They solved the users' problems extremely well.

It’s hilarious for me to hear this about Etsy. I live not far in Brooklyn and have several friends who have worked there. I specifically did not apply to a machine learning role at Etsy after talking to them about the software engineering culture there.

Maybe I received wrong data, but according to their reports anyway, it sounded like Etsy would be almost a case study in bad Agile processes.

I feel like you could be very right or very wrong, but have no way to tell because you are emphatic without being specific. What are the indicators of bad agile processes, and what would be better processes?

No process "causes success", so if that's your standard, nothing will ever meet it. Also, there is no single "Agile process" that is actually Agile. The point is for teams to continuously improve over time in a direction that shortens feedback loops, decreases waste, and improves quality.

Anyhow, I've used these approaches very happily in a startup context. In particular, I've used processes derived from Extreme Programming, so we used practices like pair programming, frequent pair rotation, test-driven development, small units of work, continuous deployment, weekly retrospectives, continuous process improvement, and a number of other things. A+++, would do again. And all the developers and business people said the same thing.

Part of the problem you may be having is that most of what people call "Agile" is what I'd call "mini-waterfall". It's where a waterfall-oriented organization decided Agile was fashionable so they borrowed a bunch of labels, cargo-culted some rituals, turned up their release frequency slightly, and declared themselves awesome. I agree this is shitty nonsense. But we didn't trademark the term "Agile" at the beginning, so anybody can use the term to mean anything they like. I think this slide began circa 2007, and in 2011 I wrote about what a mess things were: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...

> Agile prescribes so many things that are absolutely pushover, toothless concepts in the face of basic corporate bureaucracy

Agile prescribes exactly one thing; adapting processes and tools to use those that work for producing working software for the actual people on the team, working in their actual context.

> I’ve seen Waterfall used successfully.

And pretty much all the concrete methods sold as “Agile” are processes that have been used successfully somewhere, too, that's usually what motivates documenting them.

Moreover, Lean (which is essentially the system in which the values expressed in the Agile Manifesto are concretely operationalized, unlike what happens in the “Agile” community where you have the Manifesto reject rote application of canned processes, and then the literature of the community is almost entirely canned processes for rote application rather than discussion of how to adapt processes to teams and situations) shows how Agile values can work, as well as “Agile” canned processes.

> “And pretty much all the concrete methods sold as “Agile” are processes that have been used successfully somewhere, too, that's usually what motivates documenting them.”

Agile is a gimmick to sell. That’s what motivates documenting different examples of so-called Agile.

It’s similar to the age old scam of sending out mailers to 2^n different sequences of buy / sell advice for n different investment decisions, and then only focusing on the people who received the advice that turned out to be correct in every case.

Say that some organization “uses Agile” (whatever that means), but that the engineers deliver a product in spite of the processes that exist “because of Agile” and would have delivered better results with less risk had those processes not existed.

In that case, Agile will still be labeled as a success story and trumpeted around as a documented example for consultants to sell, despite Agile having a negative effect.

It boils down to a causal inference problem: what would have been delivered in the counterfactual situation of some methodology that did not impose any “Agile” processes?

I’m just pointing out that in every implementation of Agile I’ve personally worked in, heard about from friends or read about in HN comments (including this thread), all of the details appear to suggest it really is just this counterfactual problem.

Agile has a subtractive, hindering effect on a process of delivering software, and due to engineers doing extra work to overcome Agile and deliver things in spite of it, the end result is that, no thanks to Agile, organizations still ship things and make customer’s happy. Just not as happy as if they did not approach work with Agile process management.