What happens when you can develop software faster than you can describe what you want it to do? I think the best analogy is a sonic boom or moving faster than the speed of sound.
Agile Development Practices
I’m a big believer in agile software development practices. For that matter, not restricted to software… agile practices in general where you have tight feedback loops. However, I’ve observed some circumstances where even agile practices seemed overkill and to slow things down. Don’t get me wrong, this is an anomaly, but it was more than a one time occurrence.
Beyond Agile
I was talking with a colleague the other day about agile software development practices. However, we’d recently had experiences with projects that were small to medium sized but that seemed somewhat frustrating when using Agile practices.
We started to describe some of the characteristics of these projects…
- The model was quite clear or simple
- Unit tests were easy to write
- We could code and deliver results almost as fast as we could write down the stories
- Coding patterns such as Model-View-ViewModel were well established
- The team had access to all the right people when they needed them
- Focus
- And most importantly, the people on the project were very sharp
The user stories were still valuable… but they were quite short and well formed – particularly the “so that” piece in the “As a [role] I want [feature] so that [outcome].”
Using Team Foundation Server (TFS) made putting the stories there useful from a traceability perspective. And this is not some sort of “free-for-all”. It’s clarity of vision. It’s very high code coverage. It’s tight and easy to understand code.
The Analogy – “Faster than the Speed of Stories”
As we continued to talk we described writing software as fast as we could talk about it. So rather than the “speed of sound”, we have the “speed of stories” – the speed at which a product owner can write and rank the stories and the team can read, discuss, develop acceptance criteria, story point, then place into an iteration. That’s actually pretty fast compared to traditional waterfall documentation cycles. Then when development occurs at a speed that is faster than the “speed of stories” we have Super-sonic Software Development (SSD).
This was a very exhilarating! But how could we sustain it?
That does pose a challenge. I think one trick is to develop software with consistent patterns and leverage the code reuse that’s been promised for so many decades. Another trick is to keep projects small. The unit tests let you refactor so that you can achieve the reuse.
Just as with super-sonic air travel, the conditions must be right – the right equipment and tools, the right people, and the right environment. It is not always possible. But what if we could increase the times that occurs? And somehow develop a process that would support and not hinder it?
I’ll Try to Nurture SSD…
This is a pattern that I’ve only recently started to see clearly, and while it will be a challenge I will do what I can to provide an environment that fosters such “Super-sonic Software Development”.