Click here to Skip to main content
15,393,377 members
Articles / Web Development / ASP.NET
Posted 18 Feb 2006


82 bookmarked

Agile Development Checklist

Rate me:
Please Sign up or sign in to vote.
4.76/5 (16 votes)
18 Feb 20064 min read
The purpose of this article is to define a set of ideal practices for an agile software development project.


The purpose of this article is to define a set of ideal practices for an agile software development project. The idea for this article came to me after discussing CMMI-type processes and realizing that there is no agile equivalent. I encourage you to leave comments about this article using the discussions module at the bottom of this page. Please note that the practices listed are the practices that I believe are essential to a good agile development project; they do not necessarily have anything to do with being agile. I have tried to list the practices in descending order of importance.

Practice 1: Aggressive refactoring

In my opinion, refactoring is the most overlooked skill for a software developer. A well refactored application has a much higher value to the project sponsor than a poorly refactored application. The most common sign of code in need of refactoring is excessively long methods. I try to keep methods to less than 100 lines. Other common code smells are misleading or meaningless variable names, and code duplication. Static code analysis tools, such as FxCop, can provide a useful measure of code quality.

Practice 2: Testing

Firstly, there should be some developer testing. All the code that is written should be testable and should have tests written for it. It is acceptable to modify your program to facilitate good testing. I believe that the traditional testing terms; unit tests, integration tests and system tests have become outdated. Instead, I prefer the terms developer tests, functional tests and non-functional tests. Non-functional tests are things like performance testing, functional tests are tests that the customer cares about like use case tests or business transaction tests, and developer tests are everything else that the developer needs to test to prove to herself that the code is correct.

We should automate as much testing as possible and run it as part of continuous integration. If code coverage analysis is included in the automated testing it provides a nice indication of the health of the system at any point of time.

Practice 3: Automated build and deployment

The project should have an automated build, an automated deployment and ideally automated testing. In the optimal situation, a developer can click a button and the build process will build the latest source, deploy, test and report on the result. Automating these processes not only saves time but also eliminates a huge number of bugs and time wasters.

Practice 4: Continuous integration

If a project has automated build, deployment and testing then continuous integration is really just a matter of automating the kick-off of that build, deploy test cycle. Every checkin should result in a new build and test, on a separate build server. The results of this should be reported to every team member and it should be an established team practice to immediately fix the build. A working build should be everyone's top priority. People should not be made to feel bad if they break the build, as this decreases their courage.

Practice 5: Source control

A source control system should be used to store all project artifacts including: code, non-code documentation, build scripts, database schema and data scripts, and tests. The code should not be checked into the build until it compiles and passes its tests.

Practice 6: Communication plan

There should be a defined, direct communication channel between the developers and the customers. This can be (best to worst): on demand face-to-face communication, daily or weekly face-face communication, contact phone numbers, instant messaging, email mailing list, intermediary (BA or PM). These communication channels can and should be combined.

Practice 7: Task tracking

There should be a defined technique for recording and prioritizing development tasks and bugs. The system should make it possible to assign responsibility for tasks to individuals. If tasks are tracked against estimates then the estimate should be performed by the person who will do the task.

Practice 8: Self documenting code

Code comments should be subjected to the same quality requirements as the code itself. Everything possible should be done to ensure that no other technical documentation is required. When non-code technical documentation is required it should be subject to the following restrictions: referenced from the code, always up-to-date (change when the code changes), only one version per baseline, stored in source control.

Practice 9: Peer review

There must be some form of peer review, such as code review of fellow programmers. If the developers are subjected to performance reviews then the peer reviews they do should be an input to that process. This helps to avoid the temptation to approve everything to avoid confrontation. Make sure that the reviews are for quality, not just for correctness.

Practice 10: Work-in-progress

A working version of the latest iteration should always be available for customer feedback. The advantage of this is that customers see very quickly when something has been developed contrary to what they had in mind. Shortening this feedback loop decreases the cost of change.

Practice 11: Feedback mechanism

ThThere should be a defined mechanism for project team members, including the customer, to provide feedback on the project's processes. My suggestion is to hold a short meeting at the end of each iteration.


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Liam McLennan
Web Developer
Australia Australia
Liam McLennan has been developing for the internet since 2001. His major interests are agile development and object-oriented design.

Comments and Discussions

QuestionInsufficient Content Pin
Arun Kalesh16-Nov-16 6:07
MemberArun Kalesh16-Nov-16 6:07 
GeneralThat's not agile, that's just SDLC Pin
Micky4634565-Mar-07 18:40
MemberMicky4634565-Mar-07 18:40 
GeneralRe: That's not agile, that's just SDLC Pin
Bob Zebuilder5-Mar-07 22:14
MemberBob Zebuilder5-Mar-07 22:14 
GeneralNice information Pin
seee sharp13-Nov-06 1:43
Memberseee sharp13-Nov-06 1:43 
GeneralGood Article Pin
bhawin22-Feb-06 17:47
Memberbhawin22-Feb-06 17:47 
GeneralRe: Good Article Pin
Paul Conrad25-Feb-06 11:23
professionalPaul Conrad25-Feb-06 11:23 
GeneralI agree with each point Pin
Koszyk20-Feb-06 21:26
MemberKoszyk20-Feb-06 21:26 
GeneralAbout task tracking Pin
ValentinR20-Feb-06 20:36
MemberValentinR20-Feb-06 20:36 
GeneralRe: About task tracking Pin
Bob Zebuilder21-Feb-06 9:23
MemberBob Zebuilder21-Feb-06 9:23 
GeneralRe: About task tracking Pin
ValentinR21-Feb-06 20:11
MemberValentinR21-Feb-06 20:11 
GeneralNice Framework Pin
Kevin Gray19-Feb-06 15:17
MemberKevin Gray19-Feb-06 15:17 
GeneralGood stuff Pin
User 5924118-Feb-06 19:32
MemberUser 5924118-Feb-06 19:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.