Introduction

The role of a backstage team is as important as the actors on the main stage to make a play successful. Similarly, all successful products have complex managed service operations behind the scenes working tirelessly round the clock for their clients.

In an always-on ecosystem with rapidly changing customer expectations, Managed Services teams are under extreme pressure to fulfill the demands of customers and cope up with continuously changing products. The importance of an agile MSP cannot be overstated, as highly agile environments have become the foundation for new sales, cost savings, and excellent customer support. For a product company specifically, Managed Services has 3 broad roles to play.

1. Enabling the customers who want to use the product.
2. Central governance including oversight, service level agreements, change management, and so on.
3. IT operations such as infrastructure upkeep, setups, database management, and so on.

The ability of Managed Services to perform in the above areas is just as important in determining the product’s performance and development. This is where the structure outlined below comes into play.

Introducing the Swift Agile Framework

Agile MSPs offer a portfolio of services and expertise to the larger project. Frameworks and accelerators help identify and enhance the most critical factors required for execution. The Swift Agile framework is one such framework that is tailored for the services and support teams and built on top of an agile framework.

Pillars of the framework

The Swift Agile framework goes beyond traditional practises for Managed Services while maintaining the key agile principles. Process, People & Tools form the 3 key pillars ensuring the agility that is much needed for MSPs.

PROCESS

The primary goal of defining a process is to make people more efficient and consistent in their actions. Building effective and reliable processes are of utmost importance. The swift agile framework defines key principles for these processes to be efficient.

Speed of change

While an Agile Framework recommends 2 to 3 week sprints, the Swift Agile Framework recommends a daily sprint. With multiple clients and stakeholders aiming to move at an extremely fast pace, 2–3 stories need to be delivered by each squad member each day. The stories (aka tickets) although small in size need full context of the entire product.

Changing Priorities

While an agile framework seals the list of stories before the sprint begins, the Swift Agile model advocates changing priorities by the hour. A developer may start with a few stories at the beginning of the day but end up completing a different set of stories by the end of the day.

BYTE Sized Deployments to Production

The Swift-Agile model doesn’t wait for other developers to complete their work, they deploy their change to production after each story. So a 20 member services team may end up touching production more than 50 times a day. This requires significant team co-ordination.
Close Co-ordination with clients/stakeholders

As it is now becoming obvious, the framework doesn’t wait for a dedicated UAT phase. Each unit of work is initiated, discussed with clients, executed and validated all in a single shot. This means that the requirements need to be understood perfectly and clients need to be equally available to validate the work done.

Continuous Improvement at the core

As different clients start to come up with similar requests, there will be ample opportunities for automation and self-service. There has to be a separate Engineering team who is looking at which requests are most frequent and most time consuming and how such requests can be automated or converted into self-service. If this isn’t done, the team will increase linearly in size along with client counts and will soon become too costly to manage.

Globally Distributed Teams

As long as the team is doing their daily scrums and staying connected during the day, it is perfectly fine for the team members to be geographically distributed. In fact, global delivery helps manage different clients in different time zones.

Quality is assumed

The last thing you would want is your day to be turned upside down with a Production incident, so the Swift Agile model mandates automated tests built into the task pipelines to be executed post every change. Any production incident or re-opening of tickets would mean an unhappy client and an overburdened team. So establish enough automated quality gates to ensure neither quality nor speed is compromised.

Simplicity

To move fast, the execution needs to be lean and should cut out the less important things like documentation, reviews, etc. At the same time, standard operating procedures and run books must be created and followed as a bible for each type of work until it is fully automated.

PEOPLE

People will always remain at the heart of making the framework successful. The Swift Agile framework can truly be successful if the people aspect accommodates for the following-

Continuous learning

As the product itself grows after every sprint cycle, the services team members need to take out time to understand the new capabilities and enhancements. This may need one or more sessions with the product development teams during every sprint to keep themselves up to date. This session also acts as a sign off gate where services teams assess if the new product feature is in shape and can be launched without adding overheads for the services teams or delays for the clients.

Skilled and motivated squads

The speed and quality of accuracy required here can only be achieved if each and every team member is extremely skilled and understands the entire product perfectly and also is able to assess the impact of the change his story will bring to the system. With things moving and changing at a neck break speed, the individual needs to be highly motivated to ensure minimum frustration over a long period of time.

Retrospectives

The Framework recommends regular postmortems not only to understand what went well and what did not, but also to create an automation backlog from the tickets solved in the past few weeks. Some of these inputs need to be fed back to the product development team to make the product better and easier for their customers.

TOOLS

People’s efforts are leveraged or magnified by tools, making them more useful, and human effort is replaced when automation can do the job more effectively. Some tools concentrate on one of these aspects, but the majority of tools incorporate elements of both.

The right communication tools

Whether it is for managing a pipeline of requests or customers or whether it is for day to day work management, the service desk tool should be able to evolve along with the product. The service desk tool should be easy to use for the clients and should be able to change quickly. At the same time, it should be able to integrate with all the external tools seamlessly so that you can move closer to human-less services every day.

The Role of AI

AI has its own role to play in this framework in 3 key areas. Firstly, use Machine Learning technologies to read the requests at first level and guide clients to the right solution channels without having humans spend that effort going through each request. Secondly, use RPA tools to automate simple requests such that work gets done without even coming to know about it. A work done as soon as requested, creates the much needed wow effect with the customers. Thirdly, introduce NLP to set up a chat bot for your clients to field the simple questions.

Conclusion

To summarize, managed services are no longer a tertiary function of your product management life cycle. It has become the face of your company and a catalyst that can bring in more customers if done correctly or take away even the existing ones if not done in the right manner. Hence, it becomes imperative that the teams are structured around this framework and strive for perfection in each aspect.

Even if you are already running a support team, evaluate your setup around the above parameters and develop a maturity path to get to the next level.
This article is for every Product Operations Manager trying to set up an operations team. This article is also for the Product Managers who need to think about Operations as part of their design and not as a post facto formality.