A Django site.
May 7, 2009
» All Kicking Off

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.

Early Enthusiasm

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

Virtually There

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.

Wrapping Up

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.

November 19, 2008
» Cucumber Stories

Cucumber is a replacement for Storyrunner. David Chelimsky has a good writeup of the history and the plans.

UPDATE Theres seems to be some work on creating a repository of common scenarios and stories at the aptly named Cucumber Stories

Why is this interesting?

Well, the theory goes that once the feature requirements are written in the featurename.feature files then the coders write steps that correspond in featurename_steps.rb files. This is where code that actually does the things being described lives. By defining features in this way the coders are clear what exactly is required and the time consuming back and forth working out what people mean is reduced. By writing down what is meant it gives people a solid starting point. If the stories need to change then they can, but this aspect of the project is a clear way to get clarity from the clients on what they want.

Thats’s the theory.

To get started you can see that Craig Has some instructions and background on how to get it up and running.

And once you’ve done those things you’ll be itching to get cracking and write some features and scenarios. Craig also helps us out here

What it feels like to write them

I’ve been doing this for a couple of days now and to be honest am still struggling a little about how much detail I need to be going in to in the scenarios. So i decided to describe the behaviour in broad terms. If that is acceptable to the coders in the team that is fine; if they think that more detail is needed then they can define that or any other member of the team.

Here is an example of what I’m talking about.

Feature: Provide News
In order that news is relevant and timely
As an editor
I want ability to add news

Scenario: Add person to system
Given They are allowed
And they have been trained
When an editor is added
Then they have ability to add, create and edit news

In this example, the business value is the provide news from my area. The role is defined as an editor and the action is ability to add news.

So, I then go into a scenario which is to detail how the feature actually will work. In the example we describe the behaviour needed to add a person to the system. Given is a reserved word which sets the context. In this exammple it assumes that the user only arrives at this step once approved. Note that it doesn’t specify how that is done, just that it should have been done (We will come to that in another post.)

And is also a reserved word that allows us to add the the behaviours. IN the example above I am requiring that have been trained. Again, how we verify this is for elsewhere; all we need here is that it has taken place. When those steps have taken place we define that the next step is to add the editor, and to verify that has taken place we use the reserved word Then to check that the previous step has been completed.

The next stage

This is the first part of the process. The really clever bit is that steps are written in corresponding step files to make the behaviours we defined here a reality. Steps are beyond the scope of this article, but there are some good examples and explanations

I’ll let you know how we get on with this method.