I’ve just seen this very interesting chapter on 37 Signals which is part of a book that has been written titled “Getting Real, Discover the smarter, faster, easier way to build a successful web based application.”, the entire book can be read online, for free here, you can also buy a pdf version here and a paperback copy here.
The reason I think it is interesting is that the article suggests that for any v1.0 software build, 3 is the Magic Number when considering team size. They suggest that the team is comprised of a Developer, a Designer and what they call a Sweeper. The delivery team on this Skunkworks project started out with 3 members (excluding myself), a Developer, a Designer and a Researcher / Analyst. We have subsequently bolstered the team with another Developer though. The Developers here typically do the integration work once the designs have been finalised and developed as HTML by the Design Team so will carry out the Sweeper role, of course, with the new toolset from Microsoft, Expression, this role may be reversed somewhat with the Designers developing UIs in the same project as the Developers in future. In the meantime and as I have previously mentioned, we’re using a combination of Axure, a prototyping tool and a command line utility written by our Developer to minimise the amount of integration work we have to do, of course, when the designs are finalised we’ll be producing the pages in the standard way.
The last paragraph in the article ties in nicely with a post that I read yesterday in which the author describes what he perceives as the 5th Agile value. He thinks the main focus of any project should be it’s desired outcome and that that is often lost sight of when the Customers are considering their desired feature set. I’ve found this to be true recently and feel that I, perhaps, was slightly to blame. I’ve been very keen to play the “let’s get a list of all the features that you require and prioritise those” and the “you can always add more” cards without truly asking whether this was absolutely essential when considering the 2 objectives that we as a Delivery Team have been set.
Interestingly, in our Analysis Session I was challenged by one of the Developers whether we had lost sight of the objectives. An interesting conversation ensued. As I stated in the post about our objectives, we’re aiming to deliver on the second objective more than the first, the problem is though that whilst the steering group here will want a feature set that gives the Wow factor (which is why I’ve been keen to play the cards mentioned above.) the Developers on the delivery team are naturally concerned that whatever code they release needs to be stable and that the way in which they have been working until now they haven’t necessarily been focussed on delivering fully tested code, let alone code that has been reviewed by a Tester. Now, I stand with a foot in both camps, I come from a Development background so I understand the desires of the Developers to release well architected and tested code, however, I also understand that from the Steering Group’s point of view and in the context of this project, which is an 8 week engagement at the end of which the intention is to have something to put before the sponsors with a view to securing further funding, the feature set must be sufficient to sell the idea. Throughout the last 4 weeks one of my favourite sayings has become “do the simple thing first”. I ended up reiterating that to the Delivery Team yesterday but also relaying to them that the understanding has always been that the first release of the application we are building may well have bugs in it, indeed, one of the sponsors commented at one point to me that he had used a couple of other applications which occupy a similar space in the market that were full of holes.
On that note, the Steering Group told me that they had reworked the Proposition document in to something a little more concrete that afternoon and so I took the opportunity to suggest that we go through the Product Backlog and move anything wasn’t absolutely essential to the delivery of this application to a list that would be highlighted in the business plan for a potential second phase should it be given the go ahead by the board.
braek for caek 