-
Interesting post, particularly based on a couple of conversations that I have had recently.
links for 2006-11-22
Leave a reply
Monthly Archives: November 2006
links for 2006-11-21
-
Finally, something that provides bittorent suport for iTunes
War Time Correspondence
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
The 3 Musketeers
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.
links for 2006-11-16
-
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
links for 2006-11-15
-
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…
links for 2006-11-14
-
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
links for 2006-11-11
-
Interesting observation relating to Waterfall methodology
links for 2006-11-09
-
Summary on some of the difficulties faced when adopting Scrum
-
Great article that defines Agile Development and which on the most part I agree with. It’s nice to see it summised in to the Agile Manifesto
-
A couple of good links relating to how Agile and standard Project Management Methodologies dovetail or not as the case may be.
-
An interesting pool on Flickr containing images suitable for desktop wallpapers
-
Podcast discussing whether writing tests up front actually saves time.
-
Homepage for the Agile Manifesto
Analyse this
I was impressed today when, having been away from the team for some time, I came back to the office where we’re currently located and found them deep in conversation around a whiteboard. Nothing noteable about that you say? Agreed. What I found impressive was that they had identified between themselves that they needed to start doing analysis for next week’s Sprint and had allocated a time (and for any future Sprints) where they would carry out that task.
This ties in very nicely with what I mentioned in my first Lessons Learned post about the Development Stream needing to be front loaded with an Analysis Stream. How analysis and Scrum fitted together had been bothering me for a little while, I’ve actually been constructing a longer post on the subject as I thought that it was worthy of a separate post. The team have chosen to do the Analysis Session on a Wednesday afternoon allowing the Analyst to then have 2 days to produce something for the Sprint Planning session at the end of the week, it also allows them Thursday morning to carry on if they need to overrun.
This means that the Analysis Stream would, in my mind, work ahead of the Development Stream (Similarly, if we had a test resource on the project I think they would work one behind the Development Stream), how far ahead is a little unclear to me though, too far and you could loose the feedback loop which I think is one of the main benefits of an Agile approach and not far enough would slow the developers down, I guess it relates to the timescales that you are operating under, 2 or 3 days suits us at the moment, on another project that may differ.
Anyway, I continue to be encouraged by the way the team have taken to the approach that we have adopted, so much so that I am going to try and introduce something else, at the planning session this week, I intend to take the work items that will be carried out and add them to a Kanban system (I’ll post a picture of ours at some point – it seems to be the done thing). I’m doing this for 2 reasons, my old boss always said that I should try and implement it and, up until now I have never found a team that I thought would take to it and secondly, we have another developer starting in the team and it will aid my tracking of who is working on what and the estimates. I’ll report back on how it works out.
braek for caek 