Sometimes software development teams have projects so small that the full rigor of the technical practices of eXtreme...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Programming (XP) or the management practices of Scrum can be overkill. This article describes an example of such an Agile project from the early days of the Agile movement. For small projects, the following are helpful:
- Have very short iterations
- Have frequent demonstrations of ongoing work
- Have lots of exploratory testing
- Create a little more documentation than is usual on larger Agile projects
My example project has a team of two, me and a testing/QA colleague. I played the developer role and he played the customer role, which was characteristic of Agile projects at the time.
The system we worked in kept the same data in two different places, and the data in both places were supposed to update each other daily and be essentially identical. The system generated several dozen different discrepancy reports about data mismatches. However, those discrepancy reports were difficult to parse, and after struggling with that, I could guess that the number of data discrepancies was much higher than anyone suspected, but the nature of the many discrepancy logs made it difficult to pin down the extent to which the systems differed.
This was our project: to create a Perl script that would marshal all of the various discrepancy reports into a single location, so that management and development staff would know exactly to what extent the two supposedly identical systems were out-of-sync.
As the developer, I concentrated on making sure that the script itself was technically correct, and reporting correct information. As the customer, my colleague concentrated on testing, and on knowing what impact our work would have on the company at large. But of course, being just a team of two, we both shared what we knew about the project as a whole.
Short iterations and frequent demonstrations
The purpose of iterations is to allow the team to plan their work at the beginning of a time box, and to reflect on how the work went at the end of the time box. For teams of significant size, iterations are often two weeks that begin with "sprint planning" and end with a full-team retrospective on the previous iteration's work.
But with a team of two, iterations can be much shorter. For my project, we decided to have two-day iterations and a daily standup meeting. In practice, this meant that every day we would discuss how the work was going, what we had discovered about these discrepancies, and what that meant to the company. Every other day would be a demonstration of progress so far and a discussion of our next steps.
My project didn't have unit tests. For one thing, it was a throwaway piece of code, intended to demonstrate a particular situation only for a short time. Also, I was a novice programmer at the time, and I didn't really understand TDD very well.
However, we did do a significant amount of exploratory testing on the script every other day. Because we wanted to be sure to have accurate results, as the script matured and began exposing more and more discrepancies in our system data, we checked and re-checked that what was being reported was accurate.
We did this testing together every other day, during and after every demonstration. Both of us would dig into the source data, read the code, run the program, and verify both to ourselves and to each other that the project was going the right direction, and the results we were getting were accurate.
Testing is important on any Agile project, but for very small projects, it pays to choose the most efficient testing methods appropriate to the project.
On a regular Agile project, the whole team is involved in the work throughout the entire iteration, and everyone shares a common understanding of what is being done and why. Given this common understanding, such larger Agile projects usually produce very little documentation.
But a small-scale project like my example is likely being done away from the main team. And in my case, the results of the project had to be defensible. In both cases, it makes sense to create some documentation about the nature of the project, how the work proceeded, how the testing was done, and what the results indicate. This documentation is important for the rest of the team to know, and important for management to refer to also.
Agile is a state of mind
In 2003, when I did the project described here, using Agile methods for software development was controversial. Also, the well-known XP/Scrum practices followed by most of the Agile community today had not settled into the standard pattern we are now familiar with. Many people were experimenting with Agile methods based on the Agile Manifesto itself.
The Agile Manifesto was ten years old in February 2011. For me the Agile Manifesto is still an important document with an important set of ideas. And even though a decade later Agile methods are more settled into accepted practices than they were in 2003, I think it is still worthwhile to make experiments using the Manifesto as a guide:
...we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan