It's a component. It's self-contained, like, say, a database or search appliance. You're not telling me they have to be attached to the rest of the system to be tested, do you? However, what happens under realistic loads with the oddities of connectivity sometimes fall outside even the most comprehensive testing, especially when distributed concurrency rears its pretty head.

I don't recall if they actually had their checkbox marked off, but we certainly did, with several hundred tests, all written to the spec. Funny thing, there were 3 specs, with multiple versions that had occurred over time. Somehow, the "official" spec in my hands wasn't the complete spec being developed by the other team, they'd decided in a scrum that changing a couple of details would make it easier for themselves. They wound up undoing those changes, and rewriting half their component as a result, extending the timeline by 300%.

Integration is about 90% of what I do. It doesn't matter what project style is used, if the integration isn't properly spec'd and planned, you will be doing a second 90% after the first, and possibly a third and more. (NOTE: I removed waterfall from your quote, because it's relevant to all. Integration can be a real problem.)

It's never going to be cheap and easy in general to change requirements. That's as true of building bridges as it is for building software. There are changes that are easy - make the railing painted black instead of pink, for instance, vs expensive - gold railings vs wood. But changing the base structure, going from arch to suspension to truss in any order will never be cheap. (Think going from relational to Mongo to Hadoop) The purpose is the same, get a car from one side to the other, the car manages it the same way - driving on a roadway, but everything else about it is different. For data stores, the data is stored and comes back out, but the aspects of how its done and the implications for the application server are rather different, depending upon how you set them up. One or more may not even meet the base requirements used as a starting point for designing the application.

The team's always in the fire, but generally the "big" guy is the one that takes responsibility for driving the project. You can't have a 100+ person "team" owning a project. Someone needs to be the grown up.

the latter, and generally aptly described. Although on larger projects, they can be useful as long as they stay in their tracking role.

I've done some consulting over the years, mostly to rescue failing projects. But I've spent time in enough companies as an established employee to know the consulting experiences were by no means unique.

As you can tell from my posts, I pretty much consider Agile itself snake oil.

I guess my point is that Agile just generally doesn't work the way it's pitched for projects that I work on, and is highly unpleasant and/or inefficient when people attempt to use some or all of it. To me, the only person that really benefits from the whole thing is the PM (either one actually) because they can see the lack of progress that results, all the while selling it up the chain as an accomplishment. I've seen several directors on up fired over the years for doing precisely that, only to be replaced by another Agile proponent that immediately starts having hour long scrums, because, obviously, people aren't getting enough work done. This is fine when I can stay on the outside, but these things are usually black holes that take in everyone near them. Then it's time to bail.

You are clueless. There are cases where the original requirements missed a key bit of functionality that wasn't realized until a later requirement change caused a core change in the DB structure. In fact, I just finished altering a DB structure for exactly that reason. It took 4 days, but then, this current work is designed by a team that approaches software like me, so what's a relatively large change in structure and functionality was accomplished with relatively little effort and almost 0 affect on upper layers. We have well-defined application boundaries and integration API layers which by their nature are extremely loosely coupled. I have seen similar changes on other projects take months and teams of people to accomplish.

The person who "owns" the project. Generally they run it, as it's their ass in the fire.

I don't believe I've been on an agile project where PMs did not run the scrums. Most because they thought they should, and 1 that actually ran the project like I would have. That project succeeded by the measures stated when I joined, but failed by the original measures. I'm not sure I'd call that project Agile nor SCRUM, but more like a development sweatshop, unless that's what successful Agile devolves to. All the other PM run projects failed, due to missed deadlines, missing functionality, and/or cost overruns. I have missed on occasion in projects where I was responsible, as has everyone, but never by more than 20% on time and I've always delivered everything in the original requirements. (see below)

I always agree to a core scope that must be met, and then the nice to haves that are negotiable. This approach leads me to a much better success rate, happier clients, and successful projects. The agile approach has left disaster and/or disappointment everywhere I've seen it. Because the world is promised, and only some is delivered, on "successful" projects. Success does not mean delivering everything on time and within budget. You at an optimistic best get 2 of those 3 with Agile.

I did not, in fact, state that at all. What I said is "One of the many failings of Agile is that no where does it really say anything meaningful" and "Because no where does Agile say that mini-projects are part of the process"

Perhaps because I deal with projects that cover 100s of developers with budgets in the millions? And a business doesn't want to know in 8 or 16 weeks that their budget is going to be run over by 200%, or their timeline is going to be double? Ie, before committing to rewriting, lets say, an airline reservation or large shipping logistics system as examples, they'd like some realistic idea of the cost and time involved. Agile as the "manifesto" and in practice is incredibly inept at doing what I consider real work. It may work fine for small projects and teams, but that doesn't legitimize it any more than a working car made of paper mache is ready for 150mph on the autobahn.

That's pretty much exactly what you said, and now having been called out on it, you're resorting to name-calling. About as well thought out as the manifesto....

And yet that is wholly the same thing as winging it for the scope of what I'm discussing. 2 weeks, 2 months, whatever your window is, is irrelevant. I don't need to know 12 months in that the costs are going to double, or the time line is going to be missed by even 1 month, or that I'm going to have to cut half my features, which basically means I miss delivery. This is the real world, and people don't like driving cars with 2 wheels and no seats, or flying in a plane with no windows. If you still don't get it, you're a... well, you ask it yourself, so, wear the badge with pride.

And that attitude describes exactly why Agile projects fail and have massive cost overruns and are late, because, surprisingly, there are more similarities between building bridges and building software than most suspect. Change costs money and time, and a change in a fundamental core component, can have outsized effects on everything else, including instability and poor performance, which can be overlooked during the Agile development process. I personally witnessed such a project where a component was designed and built, passed all its tests, but once it was to a point it could be connected to the other portions of the system, it failed miserably and the next 12 months was spent "fixing" it, which really never got to the point it needed to because every fix led to the discovery of a new problem.

The blueprints is the requirements and planning stage, with API definitions. This does involve iterations. Coding is the building process, where checks (testing) validate the components before the next layer is added.

I design and build a data store, complete with an API in between. (the Foundation) It was designed with certain requirements in mind, because performance is a key metric I'm going to be measured on when it's done. Some Agile moron comes along 6 months later, and decides that he needs to filter with permissions in a new way that the DB was not designed for which works with today's traffic. Ideally this change requires a new foundation, because now, instead of an arch bridge, we're building a suspension bridge. The foundation requirements changed, and if we were doing it right, we'd tear everything down, but in the agile world we just slap some extra code (mortar) on the foundation, and voila, it runs/stands. Then traffic doubles, and the bridge fails.

You will pay the piper, sooner or later. Agile advocates later, which is why it's so popular with business types. That's fine if you never plan on being anywhere longer than a year or two, and don't really care what happens after that.

My last 2 sentences are how I run projects. It's not Agile in any way, although Agile did claim some of those features as its own, eventually. Do recall Agile, when it started, promoted XP, essentially code for how to take 2 developers and quarter their output. It's gone through several redefinitions since then, and just because it touts some ideas I've been following for years prior to Agile's conception doesn't mean those ideas are "Agile".

Considering I've seen US Fed gov software development contracts pre-Agile and still think Agile is crap, I guess that proves you wrong. Granted, waterfall isn't great either, but therein lies another fallacy, for Agile people, it's waterfall or Agile, for everyone else, there common sense project planning which is in between those two.

What you're describing is not listed in the Agile manifesto, and certainly not in the first few years of Agile crap. This is progressive project planning, and it existed decades prior to the Agile plague.

That's utter crap, and you know it if you're any good at all. You have no way to measure it that accurately unless you're doing cookie-cutter code where the next 10% of features are just as hard as the previous 10%.

Why weren't you 100% on target? After all, you updated estimates as you went. The better question is how close were you to the original estimate with allowances for the major changes along the way? I've been within 10% on a number of projects I was in control of. With a specific Agile project being run by a PM, a BA, and 2 stake holders we were about 500% off. Notice a problem there? Not a single technical person. Because Agile told them you didn't need a technical person running the project, and that costs would be contained, because, well, they were using Agile. They even had their Agile certificates hanging on the wall.

If I need a round peg....

So your version of Agile is create mini projects? Because no where does Agile say that mini-projects are part of the process. (One of the many failings of Agile is that no where does it really say anything meaningful) What you're describing is project planning, not Agile.

Um, no, this only happens in organizations that are small enough that everyone's involved in 1 project. In the real world, I may have 100+ people working on a large project. There's no way everyone involved with all aspects are part of all teams. All they'd do all day is meetings, which, btw, is another one of the major failings of Agile, it leads to meeting paralysis.

That's a nice fairy tale.

Agile is pretty much crap. You don't build a bridge that way, nor any other project, except maybe landscaping. If you have enough to sketch out a plan, you have enough to plan. You can't build something if you don't know what your target is.

When I have one of those... I just say - well, if it should stay the same, why don't we just change that one line back. There's no difference according to you.

Or a District 9 sequel.