Interesting post, particularly based on a couple of conversations that I have had recently.
Finally, something that provides bittorent suport for iTunes
I had an interesting conversation with somebody on Wednesday who I had highlighted my blog to. He gave me some good feedback which was encouraging.
He mentioned that my posts came across as though they weren’t really aimed at anyone which I accepted, I’ve said to a couple of people now that I see this blog as a learning aid for me, I don’t really expect many people to subscribe to the feed nor to develop a loyal following of visitors to the site, it’s just something that I can revisit at some point.
He went on to tell me about another member of staff here that had recently attended a Leadership Course that was run in conjunction with the Army. One of the Officers explained to that person that when he was stationed in Iraq he always ended the day by writing home to his wife, a, to keep her up to date of his experiences and b, to consolidate his experiences of that day to himself. This is the point I empathise with the most.
Some time ago now I spent some time in the Terratorial Army, part of my commitment was that I had to go away on Weekend Exercises. These normally meant being stationed at a Transit Camp somewhere in the country and then partaking in various exercises to form part of our training. One of the things that struck me during these weekends was just how quickly everyone slotted together as a team, particularly considering that unlike the normal Army they didn’t necessarily work together on a daily basis. Obviously the Army is very well organised, every had a job to do and they got on with it, we knew our reporting lines and were made aware of the consequences if the tasks weren’t carried out.
The Delivery Team that was assembled for this project have exhibited very similar abilities. They were all put in a room on the first day and presented with the Proposition as it stood and were allowed to feed in with their ideas, on the second day they all had some tasks to carry out which they did with minimal fuss. On the 3rd day I presented the way in which we would be working and described peoples’ responsibilities this brought the team together a little more I think and at the end of that day when we did our first planning session everyone on the team was more than willing to take on their share of the workload, even if it wasn’t what they would normally expect to be doing.
To my mind over those first 3 days the Delivery Team went from a group of individuals assembled to do a project to an effect unit of people. I’d like to say that I was directly responsible, I wasn’t. It will be important that this is replicated on a future Skunkworks style projects, may be it is just the small team ethos that facilitates this maybe not. If there is anyone out there that has any examples of how they set teams up to ensure they are effective from the outset I’d be interested to hear from you, leave a comment if you would. Continue reading
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.
Really interesting post focussing on the advantages of keeping the objectives of the project in mind as opposed simply focussing on the feature list.
Whilst I’ve not read it yet this document promises to be a really useful resource
Really liked the analogy used in this article to describe how SCRUM differs to normal Project Management approach and also how the Product Owner role fits in
Resistant to change? Never…
Interview with Esther Derby who wrote Behind Closed Doors, Secrets of Great Management book speaking about Agile Teamwork
I had an interesting discussion with a colleague earlier in which I suggested that the way I saw things working in a Scrum approach was that the Development Stream would be front loaded with an Analysis Stream and that it would have a Testing Stream after