Rooosterboys Agile observations

The problem With most agile projects, change is one of the few constants, its this paradox that makes traditional project management forecasting tools obsolete (if they ever actually worked in the first place). Gantt charts react poorly to change if it happens every day, chucking hissy fits and requiring far too much time to maintain. There is still a need however to be able to track project progress towards a goal, especially projects of many sprint lengths. I have started using Burn up charts as part of my end of sprint reports which are sent out to all the interested parties on a project including team members and other stakeholders. Setting up the chart There are some tools that have come into vogue for measuring agile project progress, of which the burn up chart is one of these. I first came into contact with burn up charts a few years ago. We had a very basic chart introduced towards the end of a large project by the amazing Angela Ferguson of Thoughtworks. This stuck with me an...

In my last role in my former life as an employee at Lonely Planet, I was Project Manager on one of the major projects running in Product/IT for that year. I understand that the funding process has changed a lot since then, and I like to think I and my colleagues helped contribute to that with our actions. Reporting As part of our reporting responsibilities we were required to do a breakdown on project spend, feature completeness and time remaining. All standard stuff, with the aim of retaining tight governance on a fairly large project with a substantial budget. There were however, a number of factors that made this a rather painful process. 1) The project had gotten its funding from a number of sources, both print and digital, as well as external clients. In memory, there were at least 6-8 buckets of money contributing to the overall project budget, and each of these expected something for their dollars. This was/is a fairly standard way to fund projects in organizations and wasn...

An idea for a release Retro Simon Bristow, my fellow engineering manager, and I sat down yesterday to brainstorm how to run a cross-organisational retro for a major release. This release was 8 development sprints and 2 Regression sprints long, a total of 20 weeks. Here is what we dreamt up, I'll follow up with a post on how it all went: Who: Representatives from the various areas of the organization (no more than say 25 in total) – Suggestions of key people welcomed, but at a minimum: Prod Ops, at least one member of each Sprint team, COPS (Client operations), Helpdesk, Triage, Marketing, UX Themes Rather than asking the groups to come up with Themes, we propose that S, H and I look through related Retro notes, information on the Sprint notes (from our Wiki) and canvass you other people in the organisation for Themes to pre-populate on the day. We’ll discuss and get say 8-10 themes for the day and place them around the room on butchers paper prior to folk coming in. These themes sh...

(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 ...

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