Wednesday, 04 April 2018 06:57

The Operations Insight

Written by

A very important part within the software life cycle is the maintenance of the software.

I have often believed we undervalue the effort that is required for the smooth running of an application and its platform.

In an agile world, we are continuously shipping out features. These enhancements, whether functional or non-functional, need to be supported once they are in production. We still live in a world where Dev and Ops work in silos. I firmly believe that a collaborative culture is imperative. DevOps has emerged as a solution; however the interpretation is left to organizations.

What I have learned having worked in multiple roles is that operations input is taken lightly whereas the input is valuable and can help us define our stories, write tighter DoDs and better acceptance criterias.

Two things that have primarily contributed to my “operations” or “support” perspective:

  1. Experience working in L3 Application Support: This role gave me a holistic understanding towards working and maintenance of an application, which not only included the “code” and “data” but the infrastructure, integration, data flow, stakeholder engagement, performance and monitoring.
  2. Experience as a BA valuing the support input: When defining a requirement and acceptance criteria I am looking not only at the functional aspects but an overall understanding of how this new feature will integrate with the application. I now view a requirement with how it can break and am able to define stronger acceptance criterias.

As a BA why should I worry about the support input you ask?

Let me start by answering what they do:

  1. They are the fire fighters for the application.
  2. They are the frontline to every feedback, every problem and every improvement.
  3. They have in-depth insights on the application as a whole.
  4. They have upstream/downstream stakeholder information.
  5. They are well versed with vendor engagement.

Advertisement

How will this input help a Business Analyst?

  1. Performance: Operations can provide valuable input regarding performance issues encountered with new features or release. This input can be absorbed in the acceptance criteria or definition of done for future enhancements. Over time I have found the Definition of Done getting tighter resulting in unit testing happening earlier on in the chain.
  2. Defects: In an ideal world, we should be able to reproduce all the defects in a non-production environment. However, use of stubs and data discrepancies can cause a hiccup. Operations can provide more insight with production logs, customer impact and data. It assists in resolving the defects quicker and to provide resolution efficiently.
  3. Downstream and upstream flows: Production support often deal with issues that are caused due to upstream or downstream impact. They are aware of how data is exchanged between systems and what nuances result in issues. This knowledge can be crucial when defining solutions around system integration.
  4. Tools: Support teams are well versed with monitoring and analytics tools used with the application. They have in-depth insight into how these tools are integrated with the application/infrastructure. They are aware of what are the logging requirements, how the tools need to be factored in the deployment process, are there any purging/restart requirements. This information is critical during deployment for a smooth release.
  5. Problem Records: A peek into the problem records will highlight the recurring issues, high impact issues, performance issues, resilience issues. The problem records are an insight into the Tech Debt created with every sprint. These can then be absorbed into the sprints to deliver a more stable platform. I am a champion of having at least some platform uplift work done with every release.
  6. Manual work: There are regular processes, changes and updates the production support team do to keep the application running smoothly. These processes can be incorporated into the backlog of work and picked up when the developers have spare capacity. This leads to automation and lesser resource dependency.
  7. Support Engagement: Early engagement ensures that Ops are aware of the work coming their way. They will advise of any processes that need to be followed as part of this engagement, to avoid any rude shocks at the last minute. Sometimes they are engaged in multiple works for the same day, and can inform us of any changes that might overlap with delivery.

These might seem trivial or might be low in priority in the backlog, but consistent interaction with the team and grooming of the backlog will highlight issues that when resolved will have a very positive impact on the overall application and its performance. This improves the customer interaction with the application and reduces the fire-fighting the operations team needs to do.

What are the ways in which we can effectively engage production support if they work as independent team not integrated with delivery?

  1. Engage them early: Involve them in the planning discussion. Get their inputs while grooming the backlog, not just for their issues/stories. But also during feature grooming. They can provide invaluable insight into integration and issues they currently encounter.
  2. Engage them often: The communication with Ops needs to be ongoing. Planning, grooming, retrospectives and the lunches. Collaborate intimately.
  3. Incorporate the DevOps culture: This can be an entire article in itself. As the simplest measure, get the Devs and Ops to collaborate more. Involve the Ops team in the stand ups; get the Devs to assist during a high impact issue. This will create ownership and empathy for the work that the two silos do. DevOps is more; it is culture and tools. However we need to start with the culture first.
  4. Educate the product owner and stakeholders: This to me has been the primary challenge. The business needs to be made aware of all the challenges, and need to be educated on how these improvements are essential for the application to run smoothly, not just today but in the future.

Collaboration is the key here, like any other interaction.

Having worked in operations I am highly empathetic towards the work that goes on in the space and very optimistic about the value that the team can provide in being able to deliver a world class platform.

Read 2636 times
Raji Pillay

Raji Pillay is passionate about technology and even as a young adult, wanted to be part of the information technology domain. She completed her education in IT and grabbed the first developer opportunity that came her way. Since then she has worked in different roles in this field. She believes technology is like “Muggle” magic, and takes pride in playing a part. She loves learning new technology and practices. Experienced working in Lotus Notes, .Net, Java and a plethora of tools. ITIL, Prince2 and SCRUM certified and on the path to be AWS practitioner certified.

Latest from Raji Pillay

© BA Times.com 2017

macgregor logo white web