Rooosterboys Agile observations

(Note, this post was originally written in October 2010, and than I got distracted by actual work and never got to post it) Extensions team had a new BA/Product Owner starting soon. Agile is (now, relatively) new to her, but already I see her asking some really great questions as she attends our Stand Ups and Retro’s. These have actually starting me thinking about the answers beyond the usual parroting from what I was once taught. Below are some of them: Q: I understand that “Velocity” is a way of measuring productivity, but how do we measure it? What units do we use (stories? Story points?) and over what timeframe – is this what we are doing with the start dates we now assigning to stories? My A:Velocity is a measure as you say. We use the term to denote how many points a team did over a given time period, typically a sprint. We can than average out how many points a team does over a number of sprints to get the average velocity of that team. This allows us to do some planning

As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are

The what and the why The team I am Scrum Master on at Aconex, Extensions,  has been moving further away from Scrum 101, and towards a version of Kanban over the last few sprints. We have also inherited a new Product Owner/BA and this led me to decide to attempt to document our process. I say attempt, because the longer it takes me to document, the less like the process the document becomes, not because I am rubbish at documenting, but because our process evolves constantly (as it should) But, I’ll give it a go anyway, and in the process, there should at least be some truths in what I record, as well as an insight to someone new to the Agile process/experience. What is “Extensions” Extensions is a agile development team within Aconex that deals primarily with the add on modules to the main Aconex application.  The team consists of Product Owner, Java engineers, UI engineers as well as QA engineers. Over the last few sprints, the Extensions team have noticed a lot more issues from Triage

Following on from my original post about Kanban I went on to 'horror of horrors' put together a slideshow on the topic for my new workplace. This was presented to a new team as an introduction. The team than went on and started a Kanban process to manage their work. They are still using a derivation of this process today, 8 months later, to mixed success. Here is the slideshow on Slideshare, I havent looked at this since I placed it up there in February, but once again I'll use the 'historical context' disclaimer here: http://www.slideshare.net/rooosterboy/little-bits-of-cardboard-a-kanban-case-study

This post originally appeared on the Kanbandev group on Yahoo groups here: http://finance.groups.yahoo.com/group/kanbandev/message/5629 I thought in the spirit of aggregation I would cut n paste it here to this collection of posts. Big thanks to Simon Harris for the first summary of what we did in this project. Please note, I haven't changed anything in this post to preserve its historical accuracy. Maybe I'll review it someday and write how I feel/what I've learnt since about mistakes and other things I've learnt since, perhaps not. I have since moved on from Lonely Planet, and we have run a number of Kanban (esque) projects here at my new place of employ (Aconex). I'll write those up soon and get them up here. Hi all, Long time reader / First time poster Just thought I'd share with you our implementation of Kanban work process at Lonely Planet in one of the teams we have here; Here's how I recently "summarised" our development process as it has e

I call this retro the "Post It Note and Vote" retro Time needed: 1 hour For: Small teams and best used as an end of iteration retro. Props: 4 Sheets of butchers paper, lots of post-it notes, List of retro actions from the last retro if available Sharpies (or similar marker pens for writing on the post-it's so people can read them) White board markers (so you don't accidentally use the sharpies on the white board) Index cards (for writing actions on) A watch to time the retro Print out of the " Prime Directive " Timing: Intro: 5 minutes Set up: 5 minutes Post it phase: 10 minutes Discussion 10 minutes (includes grouping) Voting: 5 minutes Final discussion: 30 minutes - includes agreed actions Wrap up: 5 minutes Intro Thank everyone for attending the retro and read out the Prime Directive, making sure everyone hears and understands the principles. Review any retro actions from last sprint and briefly discuss whether they were carried out,

This is a transcript of a team discussion we had around 'estimation', why we do it, what its for etc. The format for estimation is 'Relative Effort' using a fibonacci scale (1,2,3,5,8 etc). We had a team meeting to go over our estimation after we had 2 sprints with wildly different points delivered. Transcript and outcomes we summarised by me, below (in a team Skype session) Yes, the decision yesterday was to continue estimating, we just use certain estimates as triggers for further action, i.e. 5/8's are indicators that the story needs to either be preceeded by a spike, [Ed's note - this is a team decision, we have agreed within the team to try to standardise card sizes as much as possilbe, and our team standard was a '3'] or broken down if possible, we will try to get stories to be round about the same size wherever possible No 2's as per current (team chose to drop 2's as they spent too long quibbling about whether somehting was a 2 or a 3, an

I was about to start recording some observations on Agile in a word document to transpose later into a company blog, when I realised I might just be better off doing it here. So this 'Hello World' post is really to get me over the dreaded first post phase.