August 6, 2010

Agile Rapid Application Development

I am into software development for last 17 years. Most of the projects I have worked on relies heavily on agile development processes. Over these years, I have always tried to refine agile methodologies to achieve more and more smooth and rapid development experience.

With this experience, we have come out with a lightweight methodology, which has works well for our RAD projects. I will share it here. This can serve as a guideline for our future projects, as well as for new agile project managers. But remember, every project is unique and requires its own customization. Generic processes are to help, not to bind. So, never follow a generic process blindly.

For easy reference, let’s name the methodology we are going to discuss as RADLite. RADLite is similar to other agile methodologies in most of the aspects and hence here we shall be focusing only on the differences.

Key guiding factors

There are some well known influencing factors, e. g. “requirements evolve over time,” behind agile methodologies, and RADLite respects them. However, RADLite respects the following factors a lot - to achieve more RAD.

• Trying to do thing right at one shot is much more painful than evolving with multiple iterations.
• People give most output when they are given the work they like most. At early stages, people don’t like writing documentation and test cases
• You may not be able to hire all genius developers. Project should succeed with people of mixed talent.
• An average developer gives most output when the plumbing code and develompent patterns are already well set.

Keeping all these factors in mind, RADLite divides a project in phases as given below.

The Inception Phase

The objective of the inception phase is to arrive at an estimate and go/no-go decision with minimal effort. Inception phase aims to deliver the following.

1. One para summary about the product, its objective and the scope of the project
2. One or two page elaboration on the domain and project scope in plain English
3. System overview or broad architecture and deployment scenario. Should indicate volume and load.
4. Summary of user stories as themes. No need to elaborate.
5. Broad domain entity model (without attributes and complex associations)
6. List of non functional requirements like response time.
7. List of technology / legal risks, proof-of-concept tasks and mitigation plans. No need to mention common risks such as attrition.
8. List of cross cutting / non functional tasks.
9. List of third party tools and libraries needed.
10. Effort / Time / Cost estimation based on story points method.

For a medimu-sized project, these things are typically jotted following a one or two hour discussion among the customer, a functional analyst and a software architect. Many times, only either the functional analyst or the software architect takes the call and then explains the other one.

Note that all these happen before the project is signed off, and hence, no need to devote considerable effort into this. For a medium-sized project, typically, half-a-day to two days should be sufficient.

Agile methodologies suggest to add about 40%-50% contingency to the estimates, and RADLite respects that. However, many of the times the estimate is driven by budget constraint or competition. In that case, limiting the estimates to some feasible figure, keeping in mind feature trade-off is the only way. By the way, feature trade off is not a bad idea at all. Standish Group [2001] research shows that on average only 20 percent of software features in existing applications are “always or “often” used, 16 percent are “sometimes” used, 19 percent are “rarely” used and 45 percent are never used. Great relieving information for we software estimators!

Note that in some projects there might be some uncertainities which may need investment in a feasibility study before the sign-off.

The Preparation Phase

Once the project is signed off, it enters the preparation phase. The preparation phase sets up the platform for the developers, arming them for action - i.e. to gobble up the user stories.

The following jobs are addressed in the preparation phase:

1. Resource arrangement
2. Development environment setup
3. Ensuring that there are no show stopper risks. Doing proof-of-concept of risky techincal features
4. Development framework and patterns setup. Includes designing UI Templates and patterns, establishing coding patterns, coding base classes for entity and service classes, coding utility classes, coding cross cutting concerns etc.
5. Skeleton entity model setup
6. Place holder classes which would be expanded later
7. User story expansion and elaboration. Division into must-have, should-have, could-have categories.
8. Coding convention establishment
9. Developers’ training

The development phase

The development phase is sub-divided into three phases, namely must-have, should-have and could-have phase. Each of these phases address their own set of user stories.

Each of these is again sub-divided into these phases:

1. Development of working prototype, side-by-side elaboration of business rules: This phase is important whenever the requirements are not clear. It gives the customer a full cycle to revisit his requirements, business rules and stories. This is done in multiple iterations of fixed length, typically two weeks. Development of working prototype aims to develop all the UI and flow. but can skip time taking, changable business rules, security constraints etc. The objective of this phase is to demonostrate the customer the full functionality, so that he can re-visit the requirements, if any.
2. Development in multiple iterations of fixed length, typically two weeks.
   1. Base test data and acceptance test case preparation: This is done by the onsite customer or functional analyst on spreadsheet format.
   2. Code Refractoring.
   3. Development: Developers refer the base test data and acceptance test cases while coding.
   4. Acceptance test automation: By looking at the base test data and the acceptance test case prepared by the onsite customer, developers record the test cases just after developing an user story. The recorded cases are coded in proper format and put into the automated test case repository.

Development of working prototype is more important in the must-have phase than the should-have and could-have phases. The rule of thumb is that, if the requirements are not clear to such an extent that it may need one of more cycles of revisit, we should have development of working prototype.

The transition phase

RADLite does not deviate here from well established standard methodologies.

Summary

RADLite is a methodology successfully followed by me in multiple projects. It’s uniqueness are:

1. More specific about estimation strategy on inception phase
2. A preparation phase to give the developers a solid platform before attacking user stories
3. A specific testing strategy different from TDD

Let me know your views!