Thinking Inside a Bigger Box

Hi, Jerome

More great insights!

We have also automated our testing and release process and this helps a lot. But sometimes we run in to minor or major snags along the way. For example: We can have failed to stabilize the code after a bug was discovered in a late automated test. Or maven-release-plugin can act up.

And our PO doesn't want to meet all that often. Or at least that has been what we thought. We do suffer from unfocused iterations, though, and your point of one-week iterations been more focused could apply to us as well.

The main point of my 10 % of business case is that the first delivery of a system often is at the 50 % or higher point. At this point, there's little opportunity to exercise control. Indeed, many of the people I talk to still pursue projects with a delivery date a year or more into the future with a single release. I have had some luck with waking people up when I talk about 10 % of business case, as the rationale for this is so obvious from the goal itself.

As you point out: The first release is the hardest.

But if we could release even more frequent with the certainty of good enough quality that the customer wants, that would be even better.

I skipped over the inception of things on our side in the post; in fact http://showbiz.sky.com site was built internally from scratch without a weekly-live for the first few months.. We'd built up a good deal of 'inventory', which was unleashed in one go at 'launch'..

The subsequent projects massively leverage re-use in all areas (code, testing, infrastructure and deployment) and were delivered to live with an accepted minimal scope within 3-4 weeks each, then followed by our standard practice of pushing new features to live weekly to grow site functionality.

That we demo always weekly has always been the best way to keep iterations tightly focused, the scope of story cards compact and acceptance criterion on those clear and unambiguous.. We've experimented with two weekly iterations a bit and noticed we were more likely to get dragged deeper into the blinkered coding abyss due to greater scope on cards.. That said, everyone has reasons to roll their own :)

I fully see your point about regularly failing to release.. releasing can be hard, but with several years experience and hard work as a team automating every single part of our process, the dev, testing, infrastructure and deployment we're fortunate enough to deploy with ease and confidence weekly... Which is not to say there haven't been issues at times!

So in fact we go live weekly only with projects already live.. Any project being born is the exception to that - much as it is for you

Hi, Jerome

Thanks for the comment.

You are indeed right that my context is greenfield projects or at least projects that have a long projected cost before any revenue. A more constant revenue flow can possibly be much more aggressive.

My experience is that even projects with frequent iterations often fail to actually deliver those releases. If you don't experience the same, I'm very happy for you. :-)

My project currently demos and simulates production once every two weeks, but we notice that larger projects often need more time to come together, so the "once per month" goal is a tolerant one.

I've added AgileInAction to my blog roll. Very interesting post (although I am not sure I see the immediate relevance).

You could go further, being braver as we say here. We're deploying and demoing every weekly code iteration.

An outsiders view of our process from a days time spent here is commented on here. http://www.agilemanagement.net/Articles/Weblog/...

As for the money part, sounds like your on a greenfield project? Here its an already established budget being spent on bringing an existing property up to date, so perhaps not comparable.. However theres some interesting work in the throughput accounting side of things which Simon, who heads up the aforementioned, is doing..

http://www.agileinaction.com/2008/04/womens-men...