Back from an hot summer, I wanted to post about an article posted two years ago on Jeff Sutherland’s blog on Scrum: %u00abFuture of Scrum: Support for Parallel Pipelining of Sprints in Complex Projects%u00bb. I am by no means an expert of Scrum, but I’ve been on two projects using this methodology, and I’ve been introducing its adoption at |create|it|, my almost 6 year old company (link in PT-PT). This article apparently created some discussion when it was published, but I’m finding it extremely interesting. It describes 3 ways to do Scrum, by varying the intervals between Sprints and anticipating some of the work done at those intervals. What I found most interesting, however, where the findings related to functional and technical specifications:
[…] This suggests that minimal functional specifications should be clear at the beginning of a Sprint and that design and technical specifications are best done within a Sprint. […]
An interesting notion, and one that I’d already been resorting to, lately – writing detailed functional specifications, as well as overall architecture documents, and then just proceed to development. I guess this is what Fowler calls Evolving Architecture (link in PT-PT).
The following paragraph has more interesting information:
[…] MacCormack’s multivariate analysis showed three primary factors that lowered defect rate (early prototype, design reviews, and integration or regression testing at code checkin) and two primary factors that increased productivity (early prototype and daily builds).
Releasing a prototype to customers that is only 40% functionally complete increases productivity by 36% and adopting the practice of daily builds increases productivity by 93%. […]
Incremental and early delivery of working software is at the core of the effectiveness of Agile processes.[…]
I’d been discussing just this issue today with my company’s management team colleagues: how to increase productivity and lower defect rates? (yes, we’re looking for the silver bullet, I am well aware of this). This article gives us some very interesting feedback, however. We’ve been developing packaged components for SharePoint 2007 lately (here is one of them – link in PT-PT), and we’re considering structuring a Scrum-based process to handle these components. I found, surprisingly, very little existing books or documents on “modern” product development methodologies, encompassing from envisioning to production and support. Any recommendations would be welcome.
I still haven’t finished reading the article, so I’ll post more when it’s done.