Recently, I worked on a project following Agile development process. The size of the project was big including a J2EE Web application, integration using an ESB product and Web-Services. The development teams were located at two places in USA and one in offshore (India). Before start of the project, the client decided to use Agile process for this project. I had worked on other development process such as RUP, SDP, Waterfall etc. This was my first experience with Agile process.
Principles of Agile Process
Following principles of Agile Process were followed:
- The requirements were captured in the form on user stories. There was no formal requirement or use-case document for the entire project.
- The project was executed in iterations. In one iteration, few user stories were selected for implementation. During selection of user stories for one iteration, it was ensured that the implementation time would not be more than 4 to 6 weeks.
- The development team, business analyst and testers sit in one big conference room at all three locations. There was one hour of meeting daily to keep track of development, issues and other items.
- The development started on the very first day. The developers were given the user stories, and list of frameworks/tools to start the project. The developers had marathon meeting to discuss the implementation strategy. They divided the work and started coding.
- Business analysts and testers worked with developers to assist in understanding the requirements and testing the deliverables.
- Each iteration delivered a new version of application for deployment in production.
- The requirements were not static. It could be changed anytime during development.
This process was followed for few iterations, and we started seeing problems with this approach.
Problems with Agile Process and Lessons Learnt
- No Requirement Document: Agile process recommends to minimize the documents. And, the requirements can be changed by the customer anytime. This creates a lot of confusion to the customer. A lot of time is wasted in discussion with the business analyst in finalizing the requirements. As analyst is not bound to freeze the requirement, the developers are always in the state of uncertainty that the change may be coming soon.
This creates more problems to the project manager specially in case of fixed-bid contracts. Since the scope of the iteration is not defined, it becomes difficult for the project manager to mange the scope of deliverables. Agile process says that "Forget about Change Requests", which is good for the client but not for the consulting/contracting company.
- No Design Document: The developers are expected to discuss the implementation approach and start development as soon as the user story is received. Now a days, the applications (Web or Integration) are so complicated that you need a good framework and abstraction around common functionality. This improves consistency and reuse.
In Agile process, there is no time allocated to develop the common framework to be used by all developers. In absence of the common framework, each developer tends to write code in its own style. This creates huge inconsistency. The problem compounds when the teams are sitting in different locations and different time zones.
- Senior Developers only: The developers are expected to discuss the architecture & implementation strategy, and start programming. This requires that the developers must have good experience in developing similar applications. For junior developers, it was always a challenge to understand all the decisions taken during the discussion and start implementing it.
- No Team Lead / Supervisor: All developers are expected to work on certain deliverables. Usually, there is only one leader in Agile process, who manages the entire development cycle. But, the leaders responsibility is very much similar to a project manager which includes managing the user stories, scope of iterations etc. The developers work on own. In large projects, (as per my experience) technical and QA leads are very important to manage the deliverables. Without a lead, each developers tend to follow its own design patters, coding practice resulting in poor quality, duplicate work and inconsistency.
- Incremental Deliverables: The project is divided into user stories and the life of an iteration is around 4 to 6 weeks. Each iteration creates a version of the application to be deployed in production. If the application is actually put in production and is used by the end-users, it requires migration effort for each iteration. For large projects, the requirements are built incrementally, the database is changed in each iteration. This requires migrating data in the end of each iteration, which becomes a signification effort (but not useful) by the end of the project.
- Managing Large Developers: If a large development team is working, it becomes difficult to allocate work to each developer for a 4-6 weeks development cycle. Few developers get a lot of pressure and few get a lot of time for "Googling/Coffee/Smoking".
- No Task Level Schedule: Usually, the only task defined for an iteration is to implement the user-story. This becomes difficult for the project manager or lead to keep track of the progress. Changing requirement adds more problems to it.
Conclusion
Looking at pros and cons of Agile Development Process, I feel that it may be good for small projects or the maintenance/upgrade projects. In these cases, as the framework and other documents/tools are already created, there is a baseline. The upgrade would require minor and local changes, which can be managed very easily and effectively in terms of user stories and small iterations. For large projects with large development team & multiple development sites, Agile Development Process may not be a good choice.
