Adaptive S/W Development - Practices



The Adaptive Software Development practices are driven by a faith in continuous adaptation, with the lifecycle prepared to accepting continuous change as the standard.

Adaptive Software Development Lifecycle is dedicated to −

  • Continuous learning
  • Change direction
  • Re-assessment
  • Peering into an uncertain future
  • Exceptional collaboration among developers, management, and clients

Adaptive SDLC

Adaptive Software Development consolidates RAD with Software Engineering Best Practices, for example −

  • Project initiation.
  • Adaptive cycle planning.
  • Concurrent component engineering.
  • Quality review.
  • Final QA and release.

Adaptive Software Development practices can be illustrated as following −

practices_learning_loop-tsc

As mentioned above, Adaptive Software Development practices are spread across the three stages as following −

  • Speculate − Initiation and planning

    • Project Initiation

    • Establishing time-box for the whole 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 client'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 commencement and planning stage. They are −

  • Project initiation
  • Establishing time-box for the whole 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 information should be gathered in a fundamental JAD session, considering speed as the major aspect. Initiation can be finished in a concentrated two to five day effort for a small to medium sized projects, or two to three weeks effort for bigger projects.

During the JAD sessions, prerequisites are gathered in enough detail to distinguish features and establish an overview of the object, information, or other architectural model.

Establishing Time-box for the Entire Project

The time-box for the whole project should be established, based on the scope, feature-set prerequisites, estimates, and asset availability that result from project commencement work.

As you aware, Speculating doesn't abandon estimating, however it just means accepting that estimates can go wrong.

Iterations and Time-box

Decide on the number of iterations and the individual iteration lengths dependent on the overall project scope and the degree of vulnerability.

For a small to medium sized application −

  • Iterations usually fluctuate from four to eight weeks.
  • Some projects work best with two-week iterations.
  • Some projects might require more than two months.

Choose the time, based on what works for you. Once you decide on the quantity of iterations and the lengths of each of the iterations, assign a schedule to every one of the iterations.

Develop a Theme or Objective

The team members should build up a theme or objective for each iteration. This is something like 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 client to enable review and feedback.

Within the iterations, the builds should deliver working highlights on a ideally 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 finish of the project.

Assign Features

Developers and clients should together assign features to each iteration. The most significant criteria for this feature assignment is that every iteration must deliver a visible set of features with considerable functionality to the client.

During the task of features to the iterations −

  • Development team should think of the feature estimates, risks, and dependencies and provide them to the client.

  • Clients should decide on feature prioritization, using the information gave by the development team.

Thus iteration planning is feature-based and done as a team with developers and clients. Experience has indicated 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 stage, the focus is on the development. The Collaborate stage has two activities −

  • The Development team collaborate and deliver working software.

  • The project supevisors facilitate collaboration and concurrent development activities.

Collaboration is an act of shared creation that includes the development team, the clients and the managers. Shared creation is fostered by trust and respect.

Teams should collaborate on −

  • Technical problems
  • Business requirements
  • Quick decision making

Following are the practices relevant to the Collaborate stage in Adaptive Software Development −

  • Collaboration for distributed teams
  • Collaboration for smaller projects
  • Collaboration for bigger 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 colleagues are working in physical proximity, Collaboration with informal hallway chats and whiteboard scribbling should be encouraged, as this is found to be powerful.

Collaboration for Bigger Projects

Bigger projects require additional practices, collaboration tools, and project manager interaction and should be arranged on the contextual basis.

Learn - Quality Review

Adaptive Software Development empowers the idea of ‘Experiment and Learn’.

Learning from the mistakes and experimentation requires that the colleagues 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 client'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 Client's Perspective

In the Adaptive Software Development projects, getting input from the clients is the first priority. The suggested practice for this is a client focus group. These sessions are designed to explore a working model of the application and record client change requests.

Client 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 emphasis.

Result Quality from a Technical Perspective

In the Adaptive Software Development projects, periodic survey of technical artifacts should be given importance. Code Reviews should be done on a continuous basis. Audits of other technical artifacts, such as technical architecture can be conducted weekly or at the finish 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 for example −

  • Figure out 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, deciding the project status is feature-based approach, the finish of each iteration marked by finished 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 theoretical, more than the question 2 above, question 3 is significant. That is, the project team and the clients need to continuously ask themselves, "What have we learned until this point, and does it change our viewpoint on where we need to go?"





Input your Topic Name and press Enter.