Agile ready support processes – Key AIS recommendations

 

Yesterday I posted an article about how someone should carry out the Acceptance into Service testing for the product that is being developed using the agile framework. I am continuing my thoughts on the same today and want to point out few key recommendations while following the process I put forward yesterday,

Agile development framework supports a proven way of working, Collaborative working and encourages close work interaction between various teams that are designing & developing the product, testing the product and providing the support to the product and various others so that the end product is developed that is most complete from each aspect and with minimum possible bugs with a fast turnaround time.

I would like to put forward the following recommendations to assist the support teams to carry out the AIS as effectively possible to ensure better serviceability of the product when it comes in-life,

  • The support teams should act as an internal customer to the product / project development teams and have a very close working relationship with the individuals in the development team
  • Support team should provide an acceptance criteria upfront and make sure all the demands and recommendations on which the sign off is based are understood clearly by the development team.
  • Have a daily interaction with the development teams to ensure that all the recommendations are being incorporated in the actual code development.
  • Do a weekly verification cycle by doing the acceptance testing of the development package on agreeable environment / platform. The development team should be able to demonstrate the evidences of recommendation implementations.
  • The acceptance testing does not necessarily need to be done on the pre-production environment. In all possibilities most of the test cases could be carried out on the development environments and should be accepted as a credible proof.
  • The final verification should a quick one and based on the evidences observed in the development testing so that the turnaround time will be quicker and help agile framework to release the product on live
  • Share the responsibility with the development team and try to understand the application / product while it is being developed. Understand the key components and document them as a part of support manual. This could later be referenced in case of incident and problem management.

In the following table I try to summarize the last recommendation about shared responsibility into three categories to make it easy to understand.  The following example is in case of the documentation involved in the process.

Sample list of documentation from Delivery

Sample list of documentation written / contributed by Support teams

Format in which documents can be delivered / maintained / created

  • Design overview
  • e2e journey
  • Agreed user stories
    Functional
  • Acceptance criteria
  • Various error conditions
  • Sample of logs coded
  • Platform protection information
  • Monitoring requirements etc
  • WIKI site
  • Word document
  • Excel template
  • Any readable format of information 🙂

Leave a Reply