The IKO today seemed like a good to take stock of how I think things are going with our recently adopted agile approach, and to see what I’ve learnt along the way. We’ve been agile since the start of September 2008 and the time has really flown by. I’ve looked back through some of the things I’ve written about the process.
Back on September 2, I wrote
Now that I have a book describing the practices of an agile developer, I’m quite exited by the possibilities of following a method. Boundaries and Structures are good to work within.
The book in question, The Practices of an Agile Devloper was a good introduction to the tenets of Agile Development. Particularly good were the ‘What it feels like’ bits in the book, that softened the often technical and rational ideas on show. Even if the Agile Manifesto seems a little overblown, I was convinced that the realistic attitude that seems prevalent in Agile development is far better than unrealistic and unwieldy project planning that I have bumped up against in my time.
How we got the ball rolling
An external contractor was appointed to help us out with a chunk of the making IT personal project, and this was an opportune time for someone with practical experience of Agile to get us started. We initially decided that we would use physical cards, as it was suggested that they gave a strong sense of the reality of the work and the at a glance nature of the whiteboard would be an advantage. So, on September 11, I began the first story card of the first day of our first sprint.
I’ll just quickly say that in Agile, there is the concept of an iteration period, during which a team commits to a body of work to be done by the end of the period. Some teams choose longer, some shorter. We chose a week as the best fit, enabling us to report often to the customers (more of which later). This period is called a sprint – I guess no methodology is without it’s jargon.
I can clearly remember enjoying the novel sense of achievement engendered by picking up physical cards, which in Agile results in points towards the teams total. This method is to help the team get better at estimating how long it is taking to do the work that is coming in – Something that Hofstader’s Law suggests everyone is pretty bad at. The jargon for this in Agile is ‘Velocity’. In truth I think we struggled with the scoring system, based as it is, on a relative measure of how long something would take, and using a Fibonacci sequence of numbers, but I think we have since simplified that as a consequence of switching tools.
Initial Kick Off
Phew! Started our second sprint today after a pretty exhausting Initial Kick Off meeting.
Then it was a good buzz having a large stack of tasks to get through, and the atmosphere was really focused.
September 18, 2008
The Inital Kick Off (yet more jargon) is the name given to the meeting that we have at the start of the sprint where we look at all the work we have and our customers are asked about which work is highest priority for them. This is a great for concentrating minds and gettinge everyone to realise that not everything can (or should) be done at once. It’s a good time for the people who bring jobs to us to communicate how important it is to them and in return they get really realistic and useful information that they can then feed into their own planning processes.
Central to Agile is the idea that we do the work for customers, and rather than making them wait for a grand unveiling of a product, there is an incremental approach where they have a weekly opportunity to give us feedback. What I find refreshing is the idea that it’s natural for things to change, and much easier for people to discuss things that are shown rather than the abstract ideas thrown up by specification documents and wish lists; Because the sprints are short the theory is that the work is kept close to what the customers ask for.
All the work that can’t be done during the current sprint is put in a backlog, for all to see, again, making planning easier and as new work arises it is placed in the priorities in the backlog.
One problem that we have come up against in this process is the way the we estimate and frame the work so that it can be broken down into manageable chunks. It can be quite easy to be vague when writing the card for the work, which then can come back and bite you when you realise that the job is too big for one sprint. I guess the good thing is that the it’s becomes clear pretty early in the process when that is happening.
This can be a particular problem when bringing more design based work in to the process. By it’s very nature there’s a little more subjectivity and consequently how one defines the completion of particular parts of a design process can be tricky. Cenydd Bowles has written a nice article about this very thing
During the first 4 months of the process we tried physical cards on a whiteboard,the a google spreadsheet, then a ticketing system similar to the system we’ve used for years, before finally settling on our current tool, Pivotal Tracker, at the turn of the year. It’s been a good step forward. It gives us a good set of tools for managing our workload, and developing in full view of our customers is initially quite scary but turns out to be confidence building.
I’ve found the structure of developing this way suits me. It’s probably not for everyone.
- I enjoy the short turnarounds where things are not allowed to drift.
- The discipline of having to make an estimate (even if it’s wrong) feels worthwhile.
- The (mostly) daily updates we have where we (quickly)communicate what we’re individually working on are useful.
Hope you’ve enjoyed your tour of our silo.