Friday, May 3, 2013

I like to spike.


One of the hardest parts of moving towards an agile delivery approach is guiding teams to build functionality in thin slices. We've been so accustomed to building using traditional design techniques that it's hard to let it go. 

With technology projects, so much of your design is based on assumptions and unknowns. When you eventually build it out, you've usually deviated from the design in multiple places due to things encountered during the project. So if the design is more of a "guide" why spend so much time on it?

A spike is there to help you discover those unknowns, whilst delivering a thin slice of functionality. 

This allows you to show something to the business to validate whether you're on the right track, understand whether the technology can do what you want and whether your initial WAG is accurate.

Always keep a spike in the tool belt.