I've taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn't quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox.
I explain that to the participants, and they nod sagely. Then I ask them to do a simulation. Practicing in a workshop is a safe place to practice. If they don't do something quite right it's still ok. Normally this part proceeds well. Some folks have a little trouble, but most people start changing how they work by the third iteration.
At a recent workshop, things didn't go so well. One group took five iterations to complete the first part of the project when I'd expected three iterations (when designing the simulation). But take a look at a chart of their first project's velocity.
They couldn't predict what they could finish–or not–in an iteration. One of the reasons they had so much trouble is that they did not implement by feature. They attempted to build the architecture first. But as soon as they started attempting features, the architecture didn't quite work. Instead of throwing away a not-quite-right architecture at the end of iteration 2, they decided to stick with it, because of all the time they'd invested.
They had a different experience in the second project. 
In their first iteration, they decided to do an architectural prototype, but not deliver anything. Ok, I could live with that. They had a working architecture, and if they'd put things together, they could have been halfway done with the project. They chose to leave the first iteration as a prototype.
In planning for the second iteration, they told me (senior management), they were going to work on the prototype more. I asked what they would have to show me. It wasn't going to be product, so I told them that was unacceptable. They didn't plan much for that iteration, but delivered plenty. Same thing with the next two iterations.
They never did have a predictable velocity, because they were caught in the trap of pre-planned architecture instead of seeing the architecture evolve as the product grew. I asked them if this ever happened in their organizations. Predictably, it did.
This may be the most difficult idea to help people see–that they make more progress implementing the most valuable features one at a time, and letting the architecture evolve. Big Design Up Front (BDUF) slows down the project. You can't predict what the architecture needs to be.
Labels: architecture, BDUF, implement by feature, timebox
Hi Johanna,
Hi highly agree with your statement that you should let architecture evolve.
However, I don’t agree that you *always* can’t predict what the architecture needs to be. When you are building a system that is similar to systems you’ve built in the past, you can have a good notion on the major architectural decisions. This is not to say that you shouldn’t implement the bare minimum of it and that you shouldn’t allow the architecture to evolve. ( I called that JEDUF (http://www.ddj.com/blog/architectblog/archives/2006/07/jeduf.html) just enough design up front)
By the way, unless you only did some spikes to test architectural decisions, I expect an architectural prototype to end with a few user stories working. These stories might not be the top priority ones from the users perspective (since hi-value ones stories are not always the most risky technologically or architecturally ) but they are real stories