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 ModelAgile 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.
Comments