The Agile Manifesto

I started with a brief history of Agile and now I’ll look in more detail at the big one the Agile Manifesto. My initial comments were that this was a process rather than a rulebook and it would need to involve the right set of people.

The Agile Manifesto

They have values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

And some principles:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and
  within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity – the art of maximizing the amount of work not done – is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective,
  then tunes and adjusts its behaviour accordingly.

Individual vs processes

The manifesto values individual over processes and, for me, this could be the first problem. I’ve said before we all make mistakes. That means if you leave it to individuals then they are going to make mistakes. Processes can also make mistakes but could then be reviewed and adjusted to avoid that mistake. Individuals are going to keep making mistakes more or less regularly depending on their ability.

For example in the past I ran a project with a set of formatting guidelines. None of the automatic systems had quite the flexibility I was looking for. I thought I could do a better job by hand. After several years on the project I ran an automatic formatter to a comparison. It was able to find places where my manual formatting had failed: double semi-colons and misplaced white spaces mostly. I’d estimate it was about one mistake every 500 lines or so which I think is pretty good. None of it mattered too much, it’s just formatting. However we all make mistakes and it affects more than formatting. There will be bugs that affect functionality, bugs that affect security, code that is harder for future developers to understand. There are automatic tools to help with all of these and using them will probably make for better code. (Please can people make the automatic formatting tools a bit more flexible though.)

My hope is that when the team reflects on how to become more effective they realise realise automation can help. Individuals need to think about exactly what processes and tools can help the most. I don’t think there is one way best way of writing code. If you’re using a tool to format or check your code it shouldn’t just be accepting a pre-existing set of rules. NASA has a set of rules but those are for NASA, the team needs it’s own set of rules for it’s task. Picking rules is also not one and done, as the project change, as technology changes, as people change the right rules can also change.

Working software is all

Working software is a good idea but should it be the only idea? I like the idea of getting software to a “working” state. Early on that can just mean the executable opens and then immediate closes. Keeping software in a working state is also good. Throwing a software component away completely and re-writing it from scratch can sound like it will get rid of all the old problems. However, with time, I’ve realised that it also introduces a whole new set of problems. If possible gradually replacing an old component with a new component can be better. Being able to run it at each stage in-between means you can test it at each stage.

However if you just have working software then I think that could be a problem. If you’re in a situation where all the effort is going in to adding features and none is going in to maintaining the codebase then the project is going to suffer in the long run. It’s faster to write code well one time than it is to write it badly and then go back and refactor. It might be better to build one to throw away. That way you can find out if a feature is possible without ruining the codebase. A project lacking documentation can also be a problem. Often there isn’t information on what exactly project does now or how it came to be that way, it’s frustrating. Maybe you can ask the original author but often they’ve left the team. Even after years in my last big project there were sections I had little idea about. A few lines or a paragraph in the file header would have made a world of difference.

Customers collaboration

A discussion with one of my friends revealed a problem here. The company paying for the software and the company developing the software can have different goals. If you’re paying then ideally you want to set a budget and then get the most software possible for that. If you’re developing then you want to make a profit and may want to make the least software possible for that. It’s not that either party really want to make it hard for the other party but it might happen anyway. If there are any problems during development, which there will be, then there’s going to be conflict.

An agile process seems most suited when the customer and the developers are on the same side. So either developing something internally or a collaboration where both sides are very close.

Responding over planning

Is anyone really going to “Welcome changing requirements, even late in development”? I suppose if your goal is to make the best system possible then maybe you can change requirements late on. I don’t know if “welcome” is the right word though.

I’m not clear what their idea of a plan is? How much of an outline do you have to do for a system before starting? They’re pro-change but I’d like to know more.

On balance

I seem to have significant concerns or questions about all of the values here. The bits click most with me are the ones about the team. A well motivated team who can all pull in the same direction can do great things. Hopefully the company can give them the time, space and support to let the team do the job.