Agile IT Support Delivery

An Agile method for developing and releasing software using a methodology such as DevOps is commendable and a necessity in the current age, given the ever-changing and evolving needs of clients and stakeholders. However, this rapid rate of change can become a double-edged sword if not planned and managed with prudence.

The key factor, in my opinion, is to minimize the number of support-related problems, and in order to contain this metric, we should step back a little. In fact, the best strategy would be to go all the way back to the recruitment strategy in order to get the right people in the organization. I understand that this may not be an option in the short term, therefore, I will also go over the alternate option which should also produce good results on its own.

Option 1) Recruitment of It Professionals Who Understand Modern Agile Practices.

This is considered a mid-to-long range solution which should be implemented in conjunction with the short-term solution which will be discussed under option 2. However, please note that both options can be implemented independently of each other.

New Agile methods for product development and delivery contrast variably with older methods such as the Waterfall approach. For professionals accustomed to more traditional approaches, it is possible to transfer to the new models, but it is important to note that nothing comes without a cost. This is where a cost-benefit analysis comes to play and if the costs of training are not worth the most preferable outcome than it is advisable to implement a recruitment strategy which emphasizes knowledge and experience with the modern Agile development tools and techniques.

As mentioned earlier this approach will work for the mid-to-long term range as it is not feasible to get rid of all the existing staff immediately; operations must continue and new product development will be required. What can be done is to start phasing older staff into support or strategic roles depending on their capabilities and the newer staff take the Agile product delivery domain. This strategy can be uniquely beneficial as we can see our DevOps team developing with new technical staff for product delivery and our domain knowledge intact with the product support team. This approach will also maintain the velocity required for successful Agile product delivery and set the backdrop for successful product support.

Before I explain why I think this approach will work I would like to emphasize that not all employees are equal. The corollary is that there will be many professionals who will be able to surpass the learning curve and remain in the development team so we can have recruits in the Agile support team who bring with them the background and expertise of the new more Agile support delivery techniques. This will certainly make this phased approach more suitable over the longer range as was intended.

Now I will justify this strategy by looking back at our original goal, which was to minimize the number of support issues and the total cost of support in an Agile DevOps environment. As I mentioned, it is advisable to start from the beginning of the process, the recruitment phase, in order to correctly optimize the support cost. By slowly recruiting Agile leadership into the development and support teams it will be possible to bring the right knowledge into the organization which can then be dispersed to the units and organization as a whole. I believe this will be better than a simple training approach because the two variant approaches to product delivery require a shift in thinking and require time. So the training costs can be extremely high as opposed to hiring already trained professionals. And it is possible that the entire training cost is lost if employees are not motivated to change their mindset. Even if some employees are motivated, if the vast majority of professionals cannot or are not willing to change, then it is obvious that simple training will not work, as Agile methodologies need buy-in from all stakeholders. There needs to be external pressure which comes in the form of talent recruitment.

Option 2) Define a Strategy for Employees to Better Understand and Adapt Agile Methodologies.

Moving forward, Agile methodologies require new ways of thinking. With faster time to production, it is possible to introduce more problems than solutions if not done correctly. In this section, I will mention some strategies which can be implemented immediately and will work to manage our cost of support.

One way to minimize problems is to enforce that two developers review all new code checked in. One should be a senior developer and the second could be someone working on the same feature or it could be someone who has previously worked on the feature. This will also enforce a broader understanding of the business and technology by the development team as developers will be able to understand what other developers are working on.

Another technique could be for developers to rotate alongside the support staff for production support and after-hour support. This will enforce understanding of the support issues by the delivery team and collaboration between the delivery and support teams. When developers deal with production support issues first hand they will be able to see the picture from the support personnel's view and also start to build an understanding of what they can do better in order to reduce incidences. In fact, we can even do a quick standup on a daily basis between the Dev and Ops team members to improve collaboration, team building, and communication. It is important to note that it is not required for all the developers on a specific project to participate in support-related issues. We should select the appropriate personnel. The key take away from this activity is to get the delivery and support teams to start working together to solve a common goal.

The support team must realize that the velocity of incidences will increase as the velocity of product delivery increases and they need to build a system to help manage issues. One way is to use an incidence management system such as JIRA. To be effective, all relevant information regarding the incident should be linked to the incident report. It should be easy for the support personnel to link all the feature tickets all the way back to the requirements documents so that the person working on the resolution has all the information required to efficiently resolve the issue. Another method to manage velocity is try to automate certain parts of the product support process. For example, automated test scripts could be developed and new code checked in could be run against these test scripts to ensure certain standards and metrics are met which will reduce the probability of a support related issue occurring in the future. For example, software could be developed to run various test cases to ensure all test cases pass, and best practices could be checked using automation as well as code coverage or null pointer checks. All automated checks should help in reducing the probability of support-related issues to occur at some point in the future.

Another strategy which can be implemented immediately with very little upfront cost is that of continuous learning. As mentioned earlier, change requires time, so this strategy will not have any definite end and will last for the duration of the organization. What needs to be emphasized is change and learning to work together, so a certain amount of time should be dedicated to learning about the latest trends and which trends can fit nicely within the organization. Not just a few people need to be involved in this, but the entire department must be aware and knowledgeable in order for a true cultural shift to take place. The more people know, the better, as it will support a platform for an exchange of ideas and creativity when everyone is up to speed. Again, the recruitment strategy in option one ties into this with bringing in the right people.

Continuous integration is another way to help reduce the number of support issues arising in the production environment. In continuous integration, changes made by the Dev team are continuously integrated and deployed to test and user testing environments so that operations and clients can find as many defects possible before production. Continuous integration is another domain which can use the collaboration of the development and support teams. The benefits of collaboration between the two groups have been briefly been discussed. By working on a common goal there will be greater understanding and sharing of ideas which should improve the quality of the system under test.

Conclusion

I will briefly outline some of the risks involved with each of the options described above. For option 1, the main risk is that HR does not understand the needs of the IT department.  In this case, the desired recruitment strategy will not work. In order to eliminate this risk, the IT and HR department need to work together to understand the current trends and requirements in order to recruit the right people. There is also a risk that existing employees will not be happy with the hiring of new talent but I think the external pressure will be sufficient to counteract this force as long as the right people are hired. For option 2, the risk is the same as which was mentioned in option 1, which was that people will not be able to adapt to the changes. To mitigate this risk the implementations should be rolled out in phased incremental steps. Also, if option 1 is implemented in conjunction with option 2, then the burden on existing staff will also be reduced and increase the chances of success.

To wrap it up, I would like to mention that there is no one methodology which is guaranteed and destined to work,  aseach organization has its own constraints and requirements. As always, the key is continues learning and sharing of knowledge for successful adaptation and growth.