Click here to Skip to main content
12,882,806 members (36,332 online)
Click here to Skip to main content
Add your own
alternative version


82 bookmarked
Posted 18 Feb 2006

Agile Development Checklist

, 18 Feb 2006
Rate this:
Please Sign up or sign in to vote.
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.

You may also be interested in...


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
Beugnen5-Mar-07 18:40
memberBeugnen5-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
Ashish Basran13-Nov-06 1:43
memberAshish Basran13-Nov-06 1:43 
GeneralGood Article Pin
bhawin22-Feb-06 17:47
memberbhawin22-Feb-06 17:47 
GeneralRe: Good Article Pin
computerguru9238225-Feb-06 11:23
membercomputerguru9238225-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 
I agree that this is good stuff. Thank you Liam for this ordered list. My two cents are focused at the fact that you are attempting to order this list by importance.

I have to admit I was a bit confused about your ordering… I even thought that I had it backwards meaning the most important was on the bottom but that would be ascending order of importance and you specifically said descending may Practice 1 a higher order of importance that Practice 11. Please correct me if I am wrong, but I take it to read that way.

When I first started programming I would probably have agreed with your ordering but after having many different roles including consultant, architect and developer I have to say that I completely disagree with your order of importance from an operations stand point.

Earlier on when I only had the role of developer I was focused on features and implementation and the highest priorities in this role are Practices (based on the article): 1,2,3,5,7,8,9 because these assure me that the implemented software will work, my butt is covered and in the end I still look like I know what I am doing. Big Grin | :-D

Now when I am in the role of Architect/Developer I am focused on the results of the process and the highest priorities in this role are Practices (based on the article): 4,6,10 and 11 in no certain order because these assure me that the project vision are on track and that the customer will accept the final goods.

When I am in the role of Consultant I am focused on becoming a resource to my client and the highest priorities in this role are still Practices (based on the article): 4,6,10 and 11 in no certain order because these assure me that the customer’s personal objectives are met, and all indirect desires for this software project are addressed.

The difference in these roles is that the software becomes less about me as my role increases and my measure of success become customer satisfaction.

So the rest of what I will be saying will be looking at this article from an architect and consultant point of view like I said earlier from an operations development standpoint.

Here is an example from one of my experiences to help frame what I am thinking about:
We were brought in to save a project from imminent failure. We found that the largest reason the project was in failure was because that no one from the prior software team was allowed to speak with the customer. The sales agent wanted all communication between developers and customer to go through him. He felt that he understood his customer better than the technical guys and didn’t want them to frustrate his customer with any techno-babble.
Consequently his company ended up following a WaterFall methodology and didn't find out that the sales agent and network engineer had completely missed their customer’s vision and focus until delivery. The results of which were: loss of software engineers who were tired of being blamed for bad software when the problem was missed vision; internal politics and distrust between the sales team and the development team; and frustrated customers.Cry | :(( None of which had anything to do with the internal coding techniques, the software delivered worked just fine because they checked off Practices (based on the article): 1,2,3,5,7,8,9. Failure had everything to do with customer feedback and expectation. I am seeing this is holding mostly true across the board.

We implemented an Agile process that stressed the importance of Practices (based on the article): 4,6,10 and 11, the feedback and communication flow alleviated tension and ensured that we not only delivered the customer what he expected but exceeded his expectation by putting in extras based on understanding his business and prior frustrations. When missed bugs arose (as they almost always do) the customer was not angry or surprised, and was happy to be apart of the process and system to get all the cracks out of the software that he paid for and accepted.:-> This has been the overall trend for every successful project that I have worked on.

I would put the level of importance in this order or close to it:

Practice 1: Communication Plan
Practice 2: Feedback Mechanism
Practice 3: Work-In-Progress (Customers and developers should now what is expected and exactly what the next step is before the end of the first meeting.)
Practice 4: Peer Review (Architecting and Designing Phase and during each iteration)
Practice 5: Continuous Integration
All of the above should be dealt with and worked out before the first line of code is ever written so therefore should be at the top of the checklist and is higher in priority for success.
Practices 6 – 11: should be some ordering of the remainder as determined by good coding techniques and guidelines. Each company will implement them in their own way depending on the size of the team and project- all are important and should be implemented.

Big point I am stressing that my ordering increases programmer, sales, and customer satisfaction, increases project trust and ownership and informed programmers put goodies in the software that make the customer smile. The other way around… you might get there, but you will have a few missed turns along the way.

Like I said this is just my two cents. Others may disagree. I look forward to hearing feedback. Big Grin | :-D

Kevin Gray
GeneralGood stuff Pin
pwasser18-Feb-06 19:32
memberpwasser18-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.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170422.1 | Last Updated 19 Feb 2006
Article Copyright 2006 by Liam McLennan
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid