Lessons Learned from One Agile Project

Agile for Small Projects

No two projects are the same, but what they all share are problems and challenges. Obstacles range from limited resources to short timelines, to limited budgets. At times,  it is helpful to use examples from successful large-scale agile projects as a “recipe” for success with the same methodology at a smaller scale.

I’ve manage one small project (3 developers – 6 months planned). Project was canceled due to some reasons (project progress was great, so the reasons are not in development. I briefly describe here what we’ve tried and what was useful for us. I think this information will be interesting. This is a real example after all. The project was on Perl.

Elements of Success for Small Agile Projects

XP-style Planning. Small 2 weeks iterations. Small iteration helps to track project progress and create better estimates. Planning is quite easy and can be done in Excel without sophisticated tools like MS Project. We are going to use XP-style planning in future for high-risk projects (with new technologies, new team, or whatever make project risk high). Sure, web based tool for XP-planning can help.

Customer Feedback. Manage a project without client representative is a hell on the earth. You are working like in a vacuum. No response, no feedback and no attention. You can’t establish rapport with a client, and there is a chance that system will not satisfy client expectations. And sure it won’t. Project Manager must make every effort to get a person from the client side for the constant feedback.

Info for Top Managers. All information for top managers should be in a short and clear form. Do not send 20 pages requirements docs or lengthy emails. Top managers do not have enough time to read such docs. It is better to extract most important features and ideas at a single page and attach full document to be on a safe side.

Phone Calls. Phone calls are much better than emails or IMs. Sure, phone is impolite and it is hard to clear express your thoughts, but, anyway, phone is better. Many issues can be resolved faster and easier.

QA & Testing as Part Small Agile Projects

Test-Driven Development. We wrote unit tests for all business objects before actual code, and it worked great. However, we did not have tests for controllers. Controllers are very close to GUI and they changed often (during first month). Maybe we should write unit tests for controllers as well, maybe not. This is unclear. Anyway, TDD is good and we will use it as a mandatory practice.

Acceptance Tests. About 50 tests were created based on SAMIE. We modified tests quite often and spent near half an hour hour per day to keep ‘em working. These tests helped a lot when we performed major refactoring in controllers and GUI layers. But it seems that SAMIE is not the best tool for acceptance testing. It is easy to use, but sometimes unstable and Win32 restricted. But I did not find a better one so far.

Refactoring. It helps to reduce code duplication and keeps system architecture clear. We had doing refactoring constantly, and sometimes we spent whole day on major refactoring. As a result, new functionality implementation appeared easier than we expected. We will use refactoring as a mandatory practice in future.

Prototyping & Development

Walking Skeleton. This is a first, fast and small release, which contains single system feature ‘in depth’. For example, show projects list, add project into the database, check user permissions on project. Walking Skeleton for the system took near 2 weeks. We managed to investigate many architectural decisions and choose the best. Small and fast release is a great thing.

Pair Programming. We created the most important system modules in pair. The code quality and overall system architecture appeared significantly better when pair programming used. Constant code review, communication and experience sharing are really great things. It is not easy to program 7 or more hours in a row, and you feel exhausted in the end of the day. But work satisfaction is great. We will use pair programming for teaching, experience sharing and critical modules implementation in future.

Code Metrics. LOCs dynamic, Unit Tests # dynamic, Acceptance Tests dynamic. Code metrics helped to track project progress and predict team velocity and project size.

Project Site. Helps to organize important project related information (news, documents, actual project state, links) in a single place. However, Project site update should be more simpler. For example, we can use a basic CMS for project site maintenance in future.

O/R Mapping. Tangram was used as an O/R mapping tool. It took about 2-3 days to resolve some tricky issues, but in general O/R mapping speeds up development and supports database abstraction. Maybe OODBMS is a better solution, but if you stick to RDBMS, O/R mapping will help. However, for small systems or web sites O/R mapping is not required.

System Prototypes. Helps to resolve many issues on the early stage. In general, the prototype should be created if project budget allows to do that. But I do not recommend to create a comprehensive prototype, since it just wastes time. Prototype should contain major system modules and maybe some secondary.

Honesty. Just be honest with your teammates. They will trust you, and trust is one of the major factors for gelled teams.

Documentation in Source Code. Almost all system architecture related documentation was in source code. We used a tool to build linked html pages from POD documentation. As a result, documentation maintenance was easier.