Last week I gave a presentation on Agile Development for an event hosted by Codeworks and Sunderland Software City. This blog post is a brief review of my presentation and the event itself.

The event was titled, "An Introduction to Agile Methodology - Get a Head Start in 2010", which was suitably broad for my liking! I have experienced heavyweight, formal methodology in the shape of the Rational Unified Process; At Scott Logic, we prefer the Agile way, keeping it light. However, we have a wide range of customers, each with their own preferred development process, so we must exercise further agility by adapting to their way of working. For this reason, I did not want to highlight a single Agile methodology, rather, the common themes held by all Agile methods. My talk was titled "With Agile Development - Communication is the Key", which pretty much sums up my own opinion on what makes the Agile approach so successful.

To summarise my presentation in a single paragraph; requirements and estimation are probably two of the greatest challenges to any software project. Requirements are hard to capture and as a result most people would agree that it is better to allow them to evolve. Estimation is something that most software engineers would rather avoid! the most common approach is to turn to the most senior member of the team and go with what they suggest. Agile, iterative methodologies promote communication between team members, and between the team and the stakeholders. In this way, the stakeholders are engaged on a regular basis, hastening the evolution of requirements. As the team learns from their previous iterations, their estimations improve. Furthermore, estimation becomes a team exercise, with the team communicating / discussing the tasks. This provides a far superior estimate of effort and team buy-in. In short, the iterative cycles of any iterative methodology promote communication, and it is this which makes them successful. Or, even-shorter, my last slide pretty much captures what I am trying to say:

Following the talks, which included mine, an introduction to Agile Development from Andrew Rumfitt (Perfect Image), and a discussion of the application of Agile techniques to non software projects by Colin Ashurst (Durham Business School), everyone played the "Ball Point Game". This is a simple training exercise where small teams are formed, the goal being to pass as many balls between the team members as possible in two minutes. However, the added twist is that before each 2 minutes "iteration" the team has to estimate how many balls they will pass. Interestingly, most teams got better with each iteration, passing more balls, but more importantly as they found their natural velocity, their estimates improved.

The Q&A session followed the game, with myself and Andrew fielding questions. This was certainly an interesting challenge! A few of my favourite questions were as follows:

"If you allow requirements to change, what about the project budget? I cannot see how this would be workable?"

Great question! and not an easy one to answer. The problem with projects where the price and requirements are determined up-front is that one of the two parties involved is probably going to be unhappy with the end result. If the requirements are set-in-stone, forming an immovable contract, their natural evolution is stifled. The customer may get exactly what the described at the start of the project, however, it is probably not what they want now after they have used the software and had a chance to think more deeply about the problem. With an Agile, iterative approach, the requirements change and improve as do the estimates. And, as a result, the original budget (or scope) may prove to be unworkable. However, this extra information empowers the customer, allowing them to make a decision about the financial impact of this change in their own requirements. Although, this will only work if their is good communication and trust. To quote the Agile Manifesto, "Customer collaboration over contract negotiation".

"I am sure that you getter better at estimating after a few projects, however, if you start a project with an Agile approach, and a few days into an iteration you find that your estimates are totally wrong, do you stop the iteration and start out again?"

This question certainly reveals the fear that a lot of software engineers have of estimation! One important point to note is that the person asking the question indicates that they think you need to run a number of agile projects before you get good at estimating. I think this is a flawed assumption. Every software project is different, and there is a certain amount of learning involved in every project. You learn about the problem being solved and about the capabilities, or velocity, of your team. The "Ball Point Game" we played earlier illustrates this point quite nicely, every team, after a few iterations, started to give very accurate estimate. With short iterations the feedback is very rapid, as a result you do not need a lot of experience from previous projects to start giving accurate estimates.

Regarding the question itself, should you abort the sprint? I don't think so. If everyone (developers, and stakeholders) has bought into the agile approach, what some might see as a failure should be seen as a valuable lesson. Continue with the sprint, maximise the learning. Do not abort the sprint and try to sweep it under the carpet! This does not promote openness. Besides, can you be sure that your revised estimate after just a few days is better? Have you learnt enough?

"Do you need the right tools and the right people for Agile development?"

Personally I would always value people over tools, regardless of the process or project. Agile development should be quite lightweight. You can probably get away with just a simple spreadsheet, or a few post-it notes!

One problem with an approach that favours communication is that software engineers are not always the most communicative. A recent codeproject survey confirmed the commonly held belief that most software engineers are introverts (the INTJ personality type was the most common). Whilst it is certainly not necessary that all team members are extroverts, I think it does help if individuals occupying certain key roles, where they facilitate communicati0n (such as the ScrumMaster in the SRUM methodology), are comfortable communicators.

A few questions followed about how you find the right kind of people. At Scott logic, our interviews concentrate far more on people's problem solving abilities and how they tackle problems than on just writing code.

After these, and other challenging questions, we have a well earned beer and some food ...

An interesting and enjoyable events.

Regards, Colin E.