Good code practices help Agile work
While the process framework behind Scrum and Agile in general gets you thinking about how you organise the work and the facilitate the team, it’s only half the story.
For software development teams there are some engineering practices that can help the team code well within the people and organisational processes that Agile implements. The aim of these engineering practices is to allow the development team to create the best software product possible. These are enabling approaches that allow us to focus on the most important aspect of software development; not engineering practices but building the right software.
The idea is to define and agree a basic way of working that allows us to focus on writing great software that satisfies the business. By using some good engineering practices we remove the waste in a developers day and allow them to get on with coding.
What follows is a mixture of engineering practice and working practices that I’ve had some success with.
Control your code - It’s just good practice to use revision control however you decide to run the project. We like subversion.
TDD/BDD - Test Driven Development or Behaviour Driven Development. Write your tests first and then write your code to fulfil those tests. This way you don’t end up with no time to test and it means you’re doing the design up front in small chunks. People often wonder where the Architecture is in Agile, well if you do TDD the way it was meant to be done then when you write your tests you’re actually designing how the code should behave. Effectively the TDD cycle of test-code-refactor is an inspect and adapt design process, that a developer goes through in cycles lasting minutes.
War room - Your team and their interactions are the single the most important factor in the success or failure of a project. If you can get all your team in one room and make it their war room it will help the team to be cohesive and develop a sense of shared values and team practices or behaviours.
Continuous Integration and Automated Testing - Automate both unit testing and acceptance or functional testing. Ad hoc testing is a bad idea - by automating the building and testing in the code control system you ensure that the software builds at every check-in; this is continuous integration. Developers will feel more comfortable changing existing code and refactoring, no one forgets to run the tests, you spot errors early, development becomes more flexible. For a test framework in Rails apps there is Rake, Zentest and Test::Unit for Ruby, and for JUnit for Java. For acceptance testing there is Selenium and Fitnesse. Cruise control for Ant enforces continuous integration in Java.
Quiet time - When you’re in the zone and cranking out quality code like it was gong out of fashion, the last thing you need is an interruption. Once you’ve been rudely awakened it can take ages to get back into the right frame of mind for problem solving. Agree a quiet time with no phones and email or devise a physical signalling system like a busy flag so people know not to interrupt.
Automate those documents - Use software that extracts relevant information from the code and creates some of your documentation for you. That way your documents show you what is really happening with the software. It almost documents itself. So much more useful than some spec that says what should be happening.
You should also look at pair programming. Once I’ve had more experience of it I’ll post my thoughts on it. Check Ron Jeffries site for more.
Remember, not every practice works for every situation, try them out and keep what fits. Make sure to get the team to agree their working practices - enforced ways of working that validate and measure the wrong practices and metrics wont deliver you software, let alone agility.
