Agile Rapid Application Development

I have been developing software since long. Most of the projects I have worked on relied heavily on agile development processes. Over these years, I have always tried to learn refining agile methodologies to achieve more and more smooth and rapid development experience.
Let me take a moment to record my generic experiences here, at least for my reference.

Key guiding factors

There are some well known influencing factors, e. g. “requirements evolve over time” and we should respects them. However, some of those factors I have learned to respect a lot - to achieve more RAD, are

• Trying to do thing right at one or two shots 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, I see a normal project having these phases:

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. No need to go into depth - agile methodologies defer going to the depth until development phase.
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 user stories (could be high level pseudo-code) and 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, prioritizing key and uncertain requirements. Development of working prototype aims to develop all the UI and flow, but can skip time taking, changeable business rules, security constraints etc. The objective of this phase is to demonstrate the customer the full functionality, so that he can re-visit the requirements, if any. For my Java projects, I find the best place for documenting the elaborated user stories to be the JavaDoc, with a custom CSS for generating the docs for non-coders. For traceability, you can maintain sequence numbers in a Google spreadsheet, and use those numbers in the JavaDoc business rules. Those numbers could be then used in test cases. In summary, I like to depend on the JavaDoc and in line documentation for maintaining much of the documentation at a single place. So, going by this, modular coding and strong in-line documentation should be done while designing/coding. Don't consider coding of a ticket complete unless you have finished doing enough in-line documentation - note that in RADLite this is the only place where requirements, HLD and LLD are being documented. Document in a way which can be processed using a document generator tool, like JavaDoc, as much as possible.
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 prepare detailed design (e.g.) 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!