After wrapping up a VOIP project using a conventional waterfall process, I joined a group of very talented web designers on a web portal project using the Agile process. Both projects are quite large in terms of the size of the code base. Each release for the previous VOIP project lasted anywhere from 8 to 12 months. On this current project, a release normally takes around 2 to 3 months, which typically includes 3 to 4 development iterations, 1 regression testing iteration and 1 hardening iteration.

My first impression of the Agile process is that it is very progressive. I can easily see the progress made by each developer as well as the entire team on a daily basis. This was rarely the case in the previous waterfall development environment. The several initial releases of this project have confirmed my observation that being able to deliver early results, with much sooner return on investment if you will, is one of the Agile method’s greatest strengths.

The Agile process is light-weight as opposed to the traditional well-structured heavier waterfall process. Light-weight does not mean that there is less control or planning. My understanding is that the Agile process distributes the planning and control of uncertainties to each team member in many small steps over a relatively short period of time, avoiding the big long term visionary statements and aggressive targets often set during the waterfall process. Agile planning is focused more on individual estimates over a short period of time rather than a lengthy planning document covering a much longer period. The Agile process requires constant revisiting of plans and schedules. This benefits the developers and maintains clarity and focus. Individuals and interactions are the keys to build a common understanding of the project goals and the ways to reach them.

Changes of project requirements are often a nightmare to developers in the waterfall process because they have to rewrite their functional specification and design documents. They may have to re-architect their software implementation. All of these updates require re-review and re-approval. The Agile process, on the other hand, encourages and embraces the changing requirements. Product owners constantly give feedback to developers based on their discussion with customers. Developers are more adaptable to the changing UACs (user acceptance criteria). Because Agile uses iteration-based scheduling (versus release-based scheduling) and because a single iteration is much shorter than one release, any significant changes in UAC can be reflected in the new stories for the next iteration.

During the iteration planning and release planning phases, software developers, have to work very closely with product owners and other stakeholders. It is absolutely crucial for every one of the developers to be involved in this phase because in order for the developers to solve the issues, we must first fully understand them. This is much harder in reality than it sounds. The Agile process encourages individual accountability, self-organization as well as collaboration between stakeholders. In practice, we use daily stand-up meetings which include accomplishments and obstacles for that day and a list of the things to do the next day. In addition routine communications occur between team members including all stakeholders in the project. This prevents any hidden issues and encourages team members to respond. The Agile process emphasizes working software over cumbersome documentation. As soon as we check in source code and mark a development task as being completed, the QA team is able to test it without any delay. This guarantees that we deliver completely developed and fully tested features in a much shorter period of time.

No matter how well the Agile process is defined, a project’s success depends to a large extent on how well you follow the process. Understated documentation, such as user story or use case related documentation, could lead to confusion especially for a larger project. Team members tend to rely heavily on email exchanges and wiki pages to record design thoughts and discussions without any version controls. Team members’ flexibility in accepting the changing UACs is one of Agile’s strengths. However, changing UACs too frequently or too late in the iteration will cause a lot of frustration among developers.

As of now, my knowledge and experience with the Agile process is still very limited. Even without much formal training or many years of Agile experience, I am already excited with and quite encouraged by a lot of benefits the Agile process has offered to us.

This entry was posted on Sunday, August 2nd, 2009 at 2:55 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.