Being Agile

25 September 2008 // Pär Wenåker

Not long ago I got caught up in a discussion on agile development (again). The discussion proceeded more or less as it use to do for people that have never had the opportunity to work in a project that applies agile methodologies. Accordingly, someone said that they had heard about someone else doing agile development, in this case Scrum, and someone else answering that “isn’t” that just about skipping documentation and going to code according to the (in)famous “hacking and hoping” approach. As a strong believer in agile methodologies I tried to explain what it was all about and the discussion lead me to look up the Agile Manifestfrom 2001 to remind me on the core points of agile development.

Individuals and interaction over process and tools.

Have you been on a project where you have had a very good process or tools and that you can say that it was the process or tools that made you succeed, regardless of the people involved? I haven’t, but I have been on numerous projects that have been saved by skillful, competent and sometimes heroic people. This does not mean that we should ignore and not value processes and tools and just throw them overboard. It just means that we should value people more. If the process or tools gets in the way of people making them less productive, something is wrong. When you follow the agile principles, you are also encouraged to have the guts to reveal your weaknesses and ask for help from your fellow team members. This helps spreading knowledge and it also helps spreading good practices. You are in it as a team and not as individuals, so if you do not get the team interacting in a good way you are not doing agile.

Working software over comprehensive documentation.

Well, at the end of the day it is the working software that our customers pay us for. The documentation is good to have, but it is the working system that is and must be our priority number one. Have you ever tried to do a requirements analysis on a web interface without some kind of mockup? If you have, I am pretty sure that you agree that no matter how good your use-case descriptions are or how fancy looking your photoshop pictures look, the customer will want to change the final result when you show it. Instead of producing pages of documents describing how you should build something, just build it and show it in order to get fast feedback. Find a way to get running software to show to your customer as often as possible to get feedback and correct according to that feedback. This is not easy but it should be your goal to deliver software that the customer really wants and finds valuable.

Customer collaboration over contract negotiation.

In the case with the web interface above, this statements mean that it is better to have a close collaboration with the customer and straiten out the requirements in an iterative process. Start to build some of the interface and show it to the customer, get feedback early, rebuild and show it again. Go round this loop until the result is satisfying for everyone. If you start with a signed off requirements document and deliver a working interface a few months later without any customer interaction or feedback, I am pretty sure that you are delivering something that the customer is not expecting and maybe not even wants. Now you say that “what if the customer always changes his mind? We have to finish all these use cases”. That is the key point with this bullet. You have to get the customer “on board” and make them realize what major changes might result in. It is up to your customer to prioritize the requirements in order to maximize return of investment. In an agile project the resources like man-hours are more or less fixed. We realize that we have the team and resources that we have and the functionality is the rubber-band. We try to maximize the return of investment with the resources we have and keep shipping high quality software while doing it.

Response to change over following plan.

We all know that things are going to change during a software development project. Requirements are going to change, technology might change, people might change, the market might change and so on. When doing agile development you do not try to control change, you manage change. You have very short iterations and the only requirement you put on your customer is that they should know what they want for each iteration. With iteration lengths of two to three weeks that means that you require them to know what they want two to three weeks in advance. I do not think that that is to much to ask, even if I have been on projects where it apparently was. The customer gets the benefit of being able to change his or her mind and re-prioritize the requirements every two to three weeks. Isn’t that great for the customer?

Take a look at the Agile Manifest again and try to find where it say that you should not do any documentation. You are right, it is not there. It is about how you value different aspects of a software project and the things in bold on the left side always have more value compared to the ones on the right side. Just remember that that doesn’t mean that the things on the right side have no value at all!

I hope you think that this makes sense (at least I think it does), but you should always remember that there are no “silver bullets” or easy solutions. Also remember that Software development is a Wicked Problem and that the social aspects of software development sometimes are more complex than the technological ones.