In this article, I have four tests for you, the agile software developer:
1. The Joel Test by Joel Spolsky
2. Agile Engineering Practices by Ken Schwaber
3. The Three Laws of TDD by Uncle Bob
4. The Litmus Test by Uncle Bob
Have a look at them, think about them and check what’s in for you and what’s in for your team or organization.
In 2000, Joel Spolsky proposed the Joel Test with the following questions to benchmark a development organization:
- Do you use source control?
- Can you make a build in one step?
- Do you make daily builds?
- Do you have a bug database?
- Do you fix bugs before writing new code?
- Do you have an up-to-date schedule?
- Do you have a spec?
- Do programmers have quiet working conditions?
- Do you use the best tools money can buy?
- Do you have testers?
- Do new candidates write code during their interview?
- Do you do hallway usability testing?
Some points are really important, others not so much. We never really “adopted” those 12 points as a benchmark for our teams. Why? They are not inherently agile.
When I took the ScrumMaster class with Ken Schwaber in 2004, he had the following 10 questions on a flipchart to check the agile engineering practices of a software development team:
- Do you have a source code control system in place (e.g. Subversion, git)?
- Have 4 eyes looked at the code before checking (e.g. Pair Programming or code reviews)?
- Do you check in at least daily (even if it leads to build failures)?
- Do you have daily builds?
- Do you have unit tests?
- Do you have unit tests which know whether they have passed or failed (e.g. JUnit)?
- Do you use test driven development at the unit test level?
- Do you have continuous builds? Upon each check in? With unit tests executed?
- Do you use test driven development at the acceptance test level?
- Do you do large architectural refactorings at the appropriate times?
The first couple of points are easy, but the further down, the harder it gets. Don’t be surprised to see even experienced agile teams to compromise on some of those points.
When it comes to TDD, Uncle Bob (Robert C. Martin) can be quite religious 😉 He has proposed Three Laws of TDD:
- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Check your daily routine how closely you live by those rules. Those three laws are a tough benchmark.
But the final test, the Litmus test for agile teams, as Uncle Bob calls it, is: “Can you do it fixed price?”
Any team can learn to deliver working software in iterations. But most teams refrain from committing to a fixed price upfront. If your development organization can successfully deliver fixed price projects, it has passed that last, and hardest, Litmus test which separates the wheat from the chaff.