This was one of the first thoughts that crossed my mind while I was in Scrum Master training over a year ago.
How can a team accomplish so much (i.e. requirement docs, design, development, qa testing, etc) in 30 day iterations? It can take weeks to get a large feature just developed, never mind the extra days for testing, extra days for bugs fixes and more time for regression testing. I thought it would likely take a few sprints together, 60 or more likely 90 days, to fit all that in.
Those were my initial thoughts, both as a senior dev, architect and development manager. My experience in those roles were telling me, “wow, this is kinda crazy. Kinda cool, but kinda crazy.” It must work for somebody, otherwise Scrum wouldn’t be so popular, right? I think so.
It is becoming more obvious over time where we need to make more cultural changes, process changes and further embrace the idea of team empowerment. What would you do if you had to cram all that effort and tasks into 30 days, and still have a production quality product ready at the end of each Sprint?
We are still moving in that direction, and I think we have a clear path so far. We are automating a lot; CI builds, soon Unit Tests, and whatever else we can. Making the code self-testing, self-validating (read TDD for test driven development) appears to be the only feasible way of getting all the development done (and the testing), while maximizing the teams use of the full Sprint (i.e. no “code freeze” to fit in QA testing at the end of the sprint).
The rough part? How to quickly move toward TDD on a very large, complex application suite that has been under heavy development for many years. I will follow up shortly with some ideas on how we might address this issue.