Agile ready support processes – Acceptance Into Service

There is a lot of push currently within the IT organizations to use the ‘Agile development’ methodology for delivering new products & projects. The customer demands changes rapidly and that is what precisely the agile development framework provides  to the service providers.

But .. and the big but is that the ‘agile development framework’ talks only about the development of a software and does not talk about the necessary processes that are required post go-live and related testing efforts to accept the product into service.

Yeah, I am precisely talking about the support processes that need to be aligned with development efforts and must be completed before the go-live of a product. In fact, I am talking about “Acceptance into Service” testing that needs to be done before the product is accepted into the service.

In a traditional world when the development follows the waterfall model, the window for the acceptance service is normally reserved a week before the scheduled go-live to complete the activities such as knowledge handover to the ASG teams, create support documents and related testing.  However, the agile framework does not allow such window for doing the acceptance testing at the end of the development cycle and expects the teams to collaborate while the development is being carried out.

The following table precisely summarizes how I perceive the difference between the way Acceptance into Service will work in the Agile way as against the traditional way.

Waterfall Model Agile Model
  • Delivery team develops the application
  • Hands over to support team
  • Support group tests i.e., buster testing, resilience testing, log sampling & analysis etc
  • Feed back the issues
  • Delivery team fixes in next release
  • Delivery team still develops the application, but support team gives requirements upfront which will help them support application better post-live
  • Collaborative working, rather than hand over, the testing is done jointly, daily against the acceptance criteria
  • Weekly check point to ensure & track the progress against pre-decided acceptance criteria
  • AIS phase itself on reference becomes verification phase whether application works as desired on production-level environment
  • All the issues found will be fixed in next development iteration


In a nutshell, I would like to summarized my proposed Agile method for performing the acceptance into service is as follows,

  • AIS is no longer a separate phase but a joint effort of delivering bug free, support ready & self aware application on production
  • High level AIS process
    • Agree on the acceptance criteria upfront
    • Verify compliance
    • Understand the application as it evolves
    • Build the support repository as the application evolves
    • Build the support document together
    • AIS tasks are now part of the delivery sprint
    • Resilience testing is done as a separate phase if need be
  • AIS is a process to help delivery teams deliver better software – than pointing mistakes / finding errors

Hope you find the above useful as a summary.

This is of course my first post of this series and of course I will try to post more information on the agile processes and related testing mechanisms and how they would help you test the applications thoroughly prior to being accepted into service for support.

Leave a Reply