Recap
In my previous blog, ‘Agile lifecycle – The project side of life‘, I explained the benefits of the agile way of working in projects. Transparency, communication and fixed versus variable aspects are key in agile project management. But if you look at the complete lifecycle of software, it doesn’t stop after the project is released.
In our case, the R&D department delivers a product that is rolled out at customer site (Agile development). The delivery team is responsible for the project and potential customizations if needed and will handle this in an agile way (Agile projects). After the sign off, the maintenance department will take over the application and maintain it in the best possible way. Is this working for us?
To be blunt, No…
THE BRIDGE BETWEEN AGILE PROJECTS AND AGILE SUPPORT
When transferring an application from a delivery team to a maintenance team, you need to do some handover. Lean principles are always stressing to limit the number of handover moments in your process since it is considered as waste and results in risks you want to eliminate. Although our handover process is streamlined, the biggest risk comes from another side. The customer…
When executing your projects in an agile way, you are not only nurturing your customer, you are also letting them getting used to a certain way of working. Since most of the work is done on customer location, the communication is direct, transparent and frequent and the customer has full control over all the aspects of the project, you create a certain expectation. This expectation is difficult to meet when you are supporting and maintaining the application in the traditional way.
Most support departments work with an ITIL, ISM, ASL or BiSL process. These kind of processes, or methodologies, are known for their process templates, agreements and best practices. From a support perspective there is nothing wrong with these approaches, but from a customers’ perspective there is.
Imagine a customer that is used to an agile project approach in where they can communicate with the project team instantly, they can turn the knobs on every aspect of the project, decisions can result in immediate actions and they have full control over the list of items and the prioritization of these items. And then… the project is released and handed over to the support department.
All of a sudden the questions, issues, changes and enhancements, a customer wants to have in the application, will be handled as a ticket. Impact, urgency and priority are defined by the support department, with limited or no involvement of the customer. The response and resolution times are calculated based on the contractual agreements and the flow of a ticket is pre-defined and does not allow for swift changes.
Everything we did for our customer in the project is wiped out by the way we support the customer in the maintenance part of the lifecycle.
Is there a way to do it differently? Yes, there is…
AGILE SUPPORT
What if you could offer your customer agile support? What if you could allow your customer to have all the benefits of the agile approach in the support process?
When looking at the maintenance part of the lifecycle, you will have a contact person on customer side, you will have a list of tickets that need to be fixed or developed, you will have a responsible person on your side and you need to deliver a new package of deliverables. It seems that all components for an agile approach are there, so why not handle it in an agile kind of way?
So how do the agile development terms reflect on support?
IMAGINE THIS…
A customer has an issue (user story). They can log that issue with us and we will add it to the backlog. An employee of the customer (product owner) can prioritize the issue. Not in an ITIL way of prioritizing (High, Medium, Low), but in an agile way, 20 stories, means 20 priorities. So the issue with priority 1 will be worked on first, until it is fixed, or the product owner determines that another issue has a higher priority. The customer is fully in control of the prioritization of their issue and there will never be a discussion in which order the tickets should be handled.
When a ticket is created by the customer, the support department will determine the “points” of that ticket. This will not determine the priority of the issue, but says something about the scale and complexity of it. Since the level of priority can also be measured through the number of related issues, support will also determine the relation to already existing tickets. By adding the points to the tickets, it is easy to determine if the support department can handle the story themselves, or if we need to involve backup engineers for this.
By having close communication with the customer (stand up) we can have direct feedback about the list of tickets (sprint log) and the things we are waiting for. Each day we will have this stand up, so the customer is always informed about the statuses of the issues, the things we are expecting from them and, more importantly, the things they can expect from us. Even if nothing happened, it is still wise to update the customer. This allows for mutual expectations and will result in little to no discussions.
Stories (or tickets) will not have ITIL states (like “New”, “Accepted”, “Paused”, “Work in progress”, “Solved”, “Closed”), but can simply be “To Do”, “Running”, “Done”. Since there is close communication, it is not needed to have every possible situation reflected on ticket states.
By introducing an evaluation phase (retrospective) after a maintenance release or rollout of a patch, we are able to determine the satisfaction of the customer and the things we can improve in a future patch or release.
IS THIS REALLY NECESSARY?
In the near future, functionalities of the products you deliver might not be the main differentiator between you and your competitors anymore. You could go for differentiation on price, but there can be only one who is the cheapest. I am convinced that differentiation must be done on service and by delivering an agile experience you are able to be the outstanding service company. Please let me know what you think of this blog post. I am really curious in your opinion.
Get in touch
