Saturday, November 24, 2012

Always Be Releasing (Intridea)

In reviewing older posts, I came across this little gem that had never been posted but is always particularly relevant to development today. http://intridea.com/posts/always-be-releasing It's a short post but hits on a key point for developers and anyone involved in a project that seems to be going on and on:
I burn out when I'm not releasing.
One of my clients recently started trying some agile practices like iterative development. After doing three three-week iterations, the testing team felt like they needed more opportunity to test within those periods, so we switched to one-week iterations. Ouch --- that's tight and then I re-read
If you're feeling burnt out, take a step back and think about something you can release this week.
In a recent meeting, I was asked "do I feel the one week is too short a time?" Two things came to mind: 1. If you miss a day, you're 20% behind (this was actually a comment from another colleague on the same time who had just taken a day off). That means if you've got a team where members are used to working compressed work weeks or have a lot of other commitments, this can be very difficult. 2. The one week iteration ensures there are no "beware the man in a dark room" syndrome but it also allows for very little time for re-design and refactoring. Programmers that like to tinker and sit back and re-design over and over again really won't work well in this one week iteration. So it can be a challenge for dev leads to focus everyone on their single task. Our solution has been to say whatever you're working on must be done in an 8 hour period. If it can't be, it needs to be broken down into smaller pieces. So one thing to consider - if you are doing one week iterations, plan to have a few iterations where there are only a few things to do so it acts as a breather. Maybe plan an iteration that will be used for refactoring. (A caveat here: if you refactor in the middle of the one week iteration and break the code, that could be a problem - but luckily, if you're doing it in a week, you can always roll back).
it's not "what am I working on this week" but "what am I going to release this week"
A release has a lot of moving parts...but it enforces a well-oiled machine since everyone has to release their code every week. We are using a schedule that says: - Monday morning release , - Backlog Meeting Monday - Feature Go/No-Go Wednesday - Final check-in Friday (with time to fix stuff over the weekend or before Monday) From a consulting perspective, weekly iterations can be interesting. You're effectively preparing the client to be able to say "money's run out - see you later - but thanks for giving us a released product" at a moment's notice, whether because of funding or features. But that's a good thing. You're a consultant - you're there to HELP the business deliver a solution. If the product is ready to deliver in shorter time or the feature list has been cut, you can feel confident that it's ready to release. Every Monday morning. On the plus side, it makes Mondays much more exciting.

No comments: