On the other hand, the fact that agile teams develop products incrementally, deliver frequently and work in short iterations mean that the feedback cycle is very short, giving the team the chance to adjust to new information more regularly. This ability to respond can make it more likely that you’ll deliver the right product in the end, even if it’s not exactly as it was originally envisaged.

Kelly.

What concerns me is that some agile dev teams would conduct interviews, write a user story, which they don’t validate, go away, come back w/ the software product. And claim that agile has enabled them to define the actual scope based on the user stories they collected and develop the final product as delivered.

Is this how agile is supposed to work, or this team got it wrong big time?

That being said: blueprints can evolve. However, once the compiler or the builders set them in stone, the acutal installed program/skyscraper cannot change anymore (unless rebuilt/reinstalled).

What we are arguing about is a methodology to make the blueprints.

Car manufacturers make many sets of prototypes and blueprints before they get to the final version. Archtiects and civil engineers less so – they test each piece individually.

But kitchen appliances makers do little of either. They may make a few models, but for them it is essentially a talented industrial designer designing something smart.

IMO, it's more or less the same with software. It all depends on what precisely we are doing.

Now, there are only very few skyscrapers designed each year, when compared to car models, and even car models there are few a year, when compared for instance with coffee makers – a coffee maker being one of the more complicated kitchen appliances. While the skyscraper designers may need an agile process, because the costs caused by them iterating several times over the whole design are neglectable when comparted to the benefits the skyscraper will bring in, somebody designing and building a custom kitchen furniture for a new house will probably not get financing for doing the design ten times over, with three prototypes thrown in between. Therefore, agile is less of a choice there. Besides, there are highly skilled architects and civil engineers working at the plans for the skyscraper, and possibly just a carpenter working by the advice of an interior designer furnishing the kitchen, so probably there won't be the skills in place to try out several variants, besides the customers not wanting to pay for more than just the minimum cost required to get the job done.

Nevertheless, all that agile methods advocates talk about are skyscraper plans. Which is OK, as long as they don't try to get me buy into agile methods while I'm doing my custom intranet database interfaces for paying customers.

What we need is an agile methodology that allows for THE ENTIRE PRODUCT, and that includes the user-training material, to be delivered on schedule. Then folks cannot complain later that functionality is not documented.

I think this precludes an old-fashioned user manual, and requires creative people in the documentation community to come on board.

We need to think through some kind of knowledge web that can capture the changing requirements at a user level and still be right at the end.

Firstly, I have worked on may waterfall projects where the spec is barely a good reflection of the finished system by the end of the project, and where commercial constraints prevent us from having the time to go back and update it all. In this case, having a document that is believed to be true and accurate is potentially dangerous and misleading. As a consequence developers learn not to rely on it and base their decisions on the code anyway. I do accept, however, that the documentation can provide some useful context, as long as it’s not taken as gospel.

Secondly, the above comment is yet another comment that suggests you didn’t really read my post and that you’d formed your own view before you read it. I stated that requirements *are* captured. It’s just that they’re lightweight and visual, e.g. wireframes/storyboards, at the outset, and details are captured per feature as you go. Why couldn’t these feature documents/use cases/user stories, (or whatever you’re using) be kept together and provide the same context as you’d have got if you’d written it all up front? The only difference is, writing them as they are needed and not all at the beginning many months before they are developed, they’re more likely to be in line with the finished software.

Kelly.

Like all things in life, as this broad philosophy exists, it needs a name. It needs a name so we can differentiate the approach from the more traditional (waterfall) approach to development, i.e. analyse, develop, test, etc.

If you want to call that name a “catchphrase” that’s fine, but the term seems to undermine the fact that there is such a thing as an “Agile” philosophy.

Agile *disciplines* are those methodologies that materially support these philosophies, principles and values. For instance Scrum, XP and DSDM, etc. “Agile” in itself is not a discpline.

The reality is that developing software is nothing like developing a building. The waterfall approach is, and always has been, a square peg in a round hole. As for “ultimate job security” taking 12 months to finish a project that can be completed in 6 by over analyzing and over documenting sounds like ultimate job security to me.

Not sure if you actually read my post? I certainly didn’t advocate jumping straight in. I was advocating high-level visual requirements at the outset, and defining requirements on a just-in-time basis per feature rather than all up-front.

Unlike a building, software can evolve…

Kelly.

Let’s look at the well-used analogy of building a large office building.

Obviously there is quite a bit of planning that has to be done before you start construction. In fact, if you look at most projects in the real world, they work the same way.

It is only with so-called “agile” development that we think we can get something for free.

But it is a lie.

For even if you have everyone on your team that can build skyscrapers in their sleep, THIS PROJECT is not the same as the last project. It means a lot of planning and communicating has to be done to get all the experts on the same page for the current project. You don’t get to write a few stories and then just jump in your heavy machinery and build the building. Unless you want to build something horrible.

In many ways, “agile development” is about ultimate job security. There are no real requirements, no real specifications, nothing except some ad-hoc workflows amongst a specific group of individuals. If you want bug fixes or a new version, you are beholden to your “agile” developers.

Maybe it should have been called “crafty development”. A little honesty wouldn’t hurt, would it?

In short, the advice that Kelly provides is pretty much dead on to what the AM community has been promoting for the past six years.

- Scott