Agile Software Development

I just finished reading Agile Software Development by Cockburn in the last few days and it’s a very good book to get an introduction to the subject. Lots of the ideas in there ring back memories from the MBA and knowledge management actually.

For one the sender, receiver problem and frame of reference. The thing is that communication involves a sender, a receiver and a channel. The big problem is that while the channel has noise, both sender and receiver have a frame of reference that puts what they say or hear into the right context for them. This means that you can very easily not understand each other correctly. One solution here would be to often do something like this: “So what you are saying is, just so I understand it correctly, … .” This will also help if you try to win over people and notice a flaw in their reasoning. ;)

The frame of reference will only get a sound base after the norming, storming, performing phases of building a team have been gone through. This is also one of the reasons why outsourcing is a problem. You will not go through that phase and a performing team is a lot better than a norming or storming team. You will have to have so good documentation that frames of reference or noise in the channel are not important.

Cockburn actually says that software development is like rock climbing. It’s cooperative and goal seeking, yet load bearing between different people of a team that are still individuals with different talents. It’s very skill sensitive and requires training as well as the right tools. The resources are limited and you have a plan around which you improvise. It’s fun, challenging and dangerous. Great analogy.

What this also means is that you need to find the right amount of documentation and keep it so rough that you don’t need to continuously update it. This is really where it gets hard for new entries into the team, depending on how much shared vocabulary you already have.

Understanding how people work, behave, interact is key. They make mistake and this is why Agile wants short iterations, to catch them fast and keep them from growing fangs. People prefer to fail conservatively than to succeed differently.

Through University we are taught to be unique (just thinking of how unique your final thesis in germany has to be), and this makes it a none team effort and something that does not make people reuse code as such. Therefore you need to make sure that your culture, attitude and people’s education makes them want to reuse.

Another important item is “flow”. Developers, or anyone actually, get into a flow after 20 minutes of quite time. Turning of the phones for 2 hours is important to really get there at least for a few hours a day.

Motivation is another key part, which can come from three different areas: pride-in-work, pride-in-accomplishment, pride-in-contribution. That is oversimplifying it a little bit as everyone is different, but it seems about right. Another might be fear, but then again that might not be motivation then ;) But if you want to use the above, split projects into small phases.

Osmotic communication means sitting people together, at best from different parts of the organization because they will pick stuff up if they want it or not. Information radiators are good here too, which is something that VISA used very well actually. Written use cases can be used for information stickyness.

So where is the sweetspot. 2–8 people in a room, 2–4 week increments, fully automated regression tests, experienced developers, reflection after each increment, usage experts in each team.

Great stuff all in all. Looking forward to pushing more into this with the new team.

Technorati Tags: Agile, Scrum, Software Development, Teams