- Adaptive S/W Development Tutorial
- Adaptive S/W Development - Home
- Introduction
- SDLC Models - Evolution
- SDLC - Waterfall Model
- SDLC - Iterative Incremental Model
- Rapid Application Development
- SDLC - Spiral Model
- SDLC - Agile Methods
- Evolution
- Concepts
- Lifecycle
- Lifecycle Characteristics
- Practices
- Adaptive Management
- Useful Resources
- Quick Guide
- Useful Resources
- Discussion
Adaptive Software Development - Practices
The Adaptive Software Development practices are driven by a belief in continuous adaptation, with the lifecycle equipped to accepting continuous change as the norm.
Adaptive Software Development Lifecycle is dedicated to −
- Continuous learning
- Change orientation
- Re-evaluation
- Peering into an uncertain future
- Intense collaboration among developers, management, and customers
Adaptive SDLC
Adaptive Software Development combines RAD with Software Engineering Best Practices, such as −
- Project initiation.
- Adaptive cycle planning.
- Concurrent component engineering.
- Quality review.
- Final QA and release.
Adaptive Software Development practices can be illustrated as follows −
As illustrated above, Adaptive Software Development practices are spread across the three phases as follows −
Speculate − Initiation and planning
Project Initiation
Establishing time-box for the entire project
Decide on the number of iterations and assign a time-box to each one
Develop a theme or objective for each of the iterations
Assign features to each iteration
Collaborate − Concurrent feature development
Collaboration for distributed teams
Collaboration for smaller projects
Collaboration for larger projects
Learn − Quality Review
Result quality from the customer's perspective
Result quality from a technical perspective
The functioning of the delivery team and the practices team members are utilizing
The project status
Speculate - Initiation and Planning
In Adaptive Software Development, the speculate phase has two activities −
- Initiation
- Planning
Speculate has five practices that can be executed repetitively during the initiation and planning phase. They are −
- Project initiation
- Establishing time-box for the entire project
- Decide on the number of iterations and assign a time-box to each one
- Develop a theme or objective for each of the iterations
- Assign features to each iteration
Project Initiation
Project Initiation involves −
- Setting the project's mission and objectives
- Understanding constraints
- Establishing the project organization
- Identifying and outlining requirements
- Making initial size and scope estimates
- Identifying key project risks
The project initiation data should be gathered in a preliminary JAD session, considering speed as the major aspect. Initiation can be completed in a concentrated two to five day effort for a small to medium sized projects, or two to three weeks effort for larger projects.
During the JAD sessions, requirements are gathered in enough detail to identify features and establish an overview of the object, data, or other architectural model.
Establishing Time-box for the Entire Project
The time-box for the entire project should be established, based on the scope, feature-set requirements, estimates, and resource availability that result from project initiation work.
As you know, Speculating does not abandon estimating, but it just means accepting that estimates can go wrong.
Iterations and Time-box
Decide on the number of iterations and the individual iteration lengths based on the overall project scope and the degree of uncertainty.
For a small to medium sized application −
- Iterations usually vary from four to eight weeks.
- Some projects work best with two-week iterations.
- Some projects might require more than eight weeks.
Choose the time, based on what works for you. Once you decide on the number of iterations and the lengths of each of the iterations, assign a schedule to each of the iterations.
Develop a Theme or Objective
The team members should develop a theme or objective for each iteration. This is something similar to the Sprint Goal in Scrum. Each iteration should deliver a set of features that can demonstrate the product functionality making the product visible to the customer to enable review and feedback.
Within the iterations, the builds should deliver working features on a preferably daily basis enabling integration process and making the product visible to the development team. Testing should be an ongoing, integral part of the feature development. It should not be delayed until the end of the project.
Assign Features
Developers and customers should together assign features to each iteration. The most important criteria for this feature assignment is that every iteration must deliver a visible set of features with considerable functionality to the customer.
During the assignment of features to the iterations −
Development team should come up with the feature estimates, risks, and dependencies and provide them to the customer.
Customers should decide on feature prioritization, using the information provided by the development team.
Thus iteration planning is feature-based and done as a team with developers and customers. Experience has shown that this type of planning provides better understanding of the project than a task-based planning by the project manager. Further, feature-based planning reflects the uniqueness of each project.
Collaborate ─ Concurrent Feature Development
During the Collaborate phase, the focus is on the development. The Collaborate phase has two activities −
The Development team collaborate and deliver working software.
The project managers facilitate collaboration and concurrent development activities.
Collaboration is an act of shared creation that encompasses the development team, the customers and the managers. Shared creation is fostered by trust and respect.
Teams should collaborate on −
- Technical problems
- Business requirements
- Rapid decision making
Following are the practices relevant to the Collaborate phase in Adaptive Software Development −
- Collaboration for distributed teams
- Collaboration for smaller projects
- Collaboration for larger projects
Collaboration for Distributed Teams
In the projects involving distributed teams, the following should be considered −
- Varying alliance partners
- Broad-based knowledge
- The way people interact
- The way they manage interdependencies
Collaboration for Smaller Projects
In the smaller projects, when team members are working in physical proximity, Collaboration with informal hallway chats and whiteboard scribbling should be encouraged, as this is found to be effective.
Collaboration for Larger Projects
Larger projects require additional practices, collaboration tools, and project manager interaction and should be arranged on the contextual basis.
Learn - Quality Review
Adaptive Software Development encourages the concept of ‘Experiment and Learn’.
Learning from the mistakes and experimentation requires that the team members share partially completed code and artifacts early, in order to −
- Find mistakes
- Learn from them
- Reduce rework by finding small problems before they become large ones
At the end of each development iteration, there are four general categories of things to learn −
- Result quality from the customer's perspective
- Result quality from a technical perspective
- The functioning of the delivery team and the practices team
- The project status
Result Quality from the Customer's Perspective
In the Adaptive Software Development projects, getting feedback from the customers is the first priority. The recommended practice for this is a customer focus group. These sessions are designed to explore a working model of the application and record customer change requests.
Customer focus group sessions are facilitated sessions, similar to jad sessions, but rather than generating requirements or defining project plans, they are designed to review the application itself. The customers provide feedback on the working software resulting from an iteration.
Result Quality from a Technical Perspective
In the Adaptive Software Development projects, periodic review of technical artifacts should be given importance. Code Reviews should be done on a continuous basis. Reviews of other technical artifacts, such as technical architecture can be conducted weekly or at the end of an iteration.
In Adaptive Software Development projects, the team should monitor its own performance periodically. Retrospectives encourage the teams to learn about themselves and their work, together as a team.
Iteration-end retrospectives facilitate periodic team performance self-review such as −
- Determine what is not working.
- What the Team needs to do more.
- What the Team needs to do less.
The Project Status
The Project status review helps in planning further work. In the adaptive software development projects, determining the project status is feature-based approach, the end of each iteration marked by completed features resulting in working software.
The Project Status review should include −
- Where is the project?
- Where is the project versus the plans?
- Where should the project be?
As the plans in the Adaptive Software Development projects are speculative, more than the question 2 above, question 3 is important. That is, the project team and the customers need to continuously ask themselves, "What have we learned so far, and does it change our perspective on where we need to go?"