Mark Balbes presents a framework for agile project management’s critical techniques. These techniques are required for successful agile development, where rapid requirements changes can be followed through with rapid development changes.
I recently had an impromptu lunch conversation with a small group of agile consultants and developers. We had all come together at a conference and coincidentally sat down at the same table. The developers were explaining how their team was trying to use agile but was not having success. They were almost at the point of giving up and going back to their older processes. The consultants—trained and experienced scrum masters—started asking some probing questions. Was the team customer focused? Check! Did they have a trained scrum master? Check! Did they all receive training? Check! Did they use sprints? Check!
From the answers they gave, everything seemed to be in place. I decided to jump in with a few questions of my own.
- First, I asked about their automated testing framework—they didn't have one.
- Second, I asked about their continuous integration process—they didn't have one.
- Third, I asked if they used test-driven development—they didn't know what that was.
- Fourth, I asked if they paired—they thought I was crazy.
And from this short assessment, I knew why they were failing. You see, agile project management isn't enough. As a mathematician might say, “It's necessary, but not sufficient.”
The underlying goal of agile software development is to rapidly deliver high-quality code that meets the users' needs. The presumption, borne out through years of experience, is that software requirements change rapidly. The project must be able to keep pace with these changes or risk being obsolete before it is even delivered.
Agile project management practices go a long way to making this possible. They keep requirements flexible and allow them to change pretty much on a whim.
The catch is that the software itself has to be able to change on a whim too. It's one thing to be able to say halfway into your project that you are going to make major changes to the requirements. It's another thing to actually do it and still deliver on time.
Below is a framework for agile project management’s critical techniques. These techniques are required for successful agile development, where rapid requirements changes can be followed through with rapid development changes.
Automate Your Testing
Automated tests are nothing new to the disciplined software developer. While some may think this technique was invented when JUnit and other similar frameworks were created, it has actually been around for a long time before that.
And though it's nothing new, it continues to amaze me how many projects are developed without their benefits. A solid bed of automated tests (unit, integration, regression, and user acceptance tests) means that the software can be dramatically changed without the fear that existing functionality is going to break. Fearlessness means that the software can be more aggressively refactored and extended to provide new functionality faster and with higher quality.
Implement Continuous Integration
Continuous integration is usually thought to be an automated process using integration servers like Cruise Control or Jenkins. These servers continuously monitor your source control server (e.g. Subversion or Git) for changes, pull these changes, build the system, run all automated tests, and then publish the results. While this is great, on smaller projects you don't necessarily need this overhead.
Continuous integration is really the act of team members committing their changes to the software often (e.g., multiple times per day), pulling the changes from others, and then running all the tests to ensure that what they are writing has not broken anything already committed to the source code repository. In this way, everyone is working on the same baseline software.
If you think this seems obvious, let me tell you