Agile Methodology Mashups

When it comes to how you approach software development, you don't get anything better than adopting an agile software development process. But how to apply this in your process can sometimes confuse people.

About two years ago I wrote an article describing the agile culture which contended that the main point of being agile was in the culture, rather than the process. With another two years of software development behind me, I still believe what I had to say back then.  After all the agile manifesto states people over process as the first principle:

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

With that in mind, I believe that creating your own Agile Methodology Mashup is the best way to form some type of process around how you develop software.  If you're looking for inspiration on what agile methods are best to follow, there's no shortage of choice for agile methodologies. The most popular methodologies I have seen are eXtreme Programming, feature-driven development, scrum and lean software development.

A few years ago to be agile meant to follow XP - these days the fashionable approach is lean software. One thing they all hold in common is that they bundle a set of agile principles together, but there's nothing to stop you creating your own process from these. 

Speaking from my own experience, the practices that I have bundled together are as follows: 

• Pair Programming
  Often frowned upon as a waste of people, there's no doubt that getting 2 people working on a problem gets a better quality solution out there as fast.  Technology has moved on since the idea of pair programming originated - the ECF project provides a way to collaborate remotely using real time shared editing.
• Daily Scrum/Standing Meeting
  Another really simple practice is to have a 5-10 minute meetup every morning to monitor progress and to communicate across the entire team.  It's best to fit this is as a part of your day rather than consider it just another meeting. One person takes charge of the meeting to make sure it doesn't spiral off topic.

• Kanban/Burn Down Charts
  It's good to mix in a visual indicator of development progress into your daily meeting. Typically all the tasks for the week are listed on cards on a board, broken down into categories. As the card completes one phase, it moves onto another. The category here is anything that makes sense to you - it could be the development stage (unit tests, design, coding, complete) or weekdays. Once things move along each day and you see some movement on the board, you know you're doing it right.
  
  It can also be useful to add in a color to indicate the status of a task or the entire project. For example, red could signify that the project is in trouble. If you use the indicators, visible to everyone else in the company, maybe someone else will dig in and help your project out when you're in the red.

• Test First Development
  This almost goes without saying - but test driven development is the most effective way to develop software. You get the advantage of thinking through all the cases before you start writing code, and you have a suite of tests ready to validate your code against. This saves a huge amount of time in bug fixing, and typically will create well designed code (as testable code is usually modularised well).

In the end, I think your process should be a mix and match of different agile methods that enable you to develop quality software quickly and allows you to adhere to the agile manifesto. Do you have a particular set of practices you use in your process? Or do you follow one agile approach rigidly?