A few months ago, we started complaining seriously about the Rails assets pipeline. We did everything we could to bypass some problems, fix others, speed up deployment, compilation or precompile. We had to find an alternative that would work and actually improve the development process. This is not a story about how we decided to replace a Rails component. It’s a success story about how we managed uncertainty in an agile way.

As the application grows, the challenges or problems are growing too. And it’s not always possible to define stories for a proper scrum, Kanban or any other agile method. If a story can be defined, it’s almost impossible to estimate when there is too much uncertainty. As a developer, you don’t want to commit to a 21 points story in a sprint when you don’t even know if it is feasible in the first place. That’s when you do spikes.

Our team has a very special agile methodology. We’re improving our process continuously (well, you’re supposed to if you are agile) and we ended up with a mix of Scrum and Kanban. We don’t have artificial deadlines with sprints but we still estimate stories with poker planning. We also love our carefully chosen tools to help us organize, communicate and achieve work without friction. So spikes fits in our process in a very powerful way. But we had to define clearly what is a spike, what is its goal and how to complete it.