With a little hard work and my secret development ingredient, you can be a better Agile Developer
Recently my fellow developers at Integrum and I took a survey that helped us assess our team with regard to our Agile practices. When taking the survey, and now reviewing it later on, I was struck by how many of the questions were related to a single concept. Many of the problem areas that can be uncovered by the survey, along with examples of one’s successes, come back to this one theme.
Are programmers nearly always confident that the code they’ve written recently does what it’s intended to do?Consider the following questions:
- Is there more than one bug per month in the business logic of completed stories?
- Can any programmer on the team currently build and test the software, and get unambiguous success / fail result, using a single command?
- When a programmer gets the latest code, is he nearly always confident that it will build successfully and pass all tests?
- Are fewer than five bugs per month discovered in the teamʼs finished work?
- After a line item is marked “complete” do team members later perform unexpected additional work, such as bug fixes or release polish, to finish it?
- Are programmers nearly always confident that the code they’ve written recently does what it’s intended to do?
- Are all programmers comfortable making changes to the code?
- Do programmers have more than one debug session per week that exceeds 10 minutes?
- Do unexpected design changes require difficult or costly changes to existing code?
- Do any programmers optimize code without conducting performance tests first?
- Is there more than one bug per month in the business logic of completed stories?
- Are any team members unsure about the quality of the software the team is producing?
What’s the common theme among these stories, and the secret to better agile development? Testing, testing and more testing.
The negative outcomes implied by some of these questions can be solved by testing. Spending time fixing “completed” stories? Probably something you could have tested. Conversely, the positive benefits implied by other questions can be had via testing. Want to make your code more inviting and easier to deal with for new team members or people unfamiliar with the project? Give them robust and well-written tests.
