Architecture Spike Project/Iteration

I was listening to an ARCast episode this morning entitled Getting on the SOA Bandwagon when host Ron Jacobs mentioned something interesting.

He made reference to an experience in his past when the project management cycle included what he termed an Architectural Spike Project (or Iteration). The purpose was to use this as a learning exercise with the understanding that most, if not all, the work product would be throw away. It was used when there were new technologies that were strategic for adoption in the enterprise. Instead of burning up cycles of rework from mistakes made when learning the new technology within a normal timeline in a project, it broke out that necessary but all too often overlooked aspect to technology projects into it's own time-boxed period.

I thought that this was a fantastic idea. It doesn't quite work for grassroots level adoption of technology as often happens when management doesn't understand or appreciate new technologies, however, if you can pull it off, I think it will make the project cycle much more efficient.

Bottom line is, technology changes and with that change comes learning curves. By accounting for this learning time outside of the normal project timeline and given a block of time just for that, kind of like a mini-R&D cycle, those that need to ramp up will be able to focus with greater intensity on the learning instead of the learning AND production and therefore, I believe the learning will be of higher quality and quantity while the production will be likewise.

Interesting concept.

Now, if we can just get that included as part of the MSF Agile process template that ships with TFS as an optional step up front. By shipping it from Redmond, instead of modifying the process templates it will give it much greater credence in the community and with project management and business owners.