grid pinterest pencil mobile search cog accessibility cross embed terminal twitter wordpress linkedin
← Blog

How to make your service delivery Agile

Whilst a lot of our focus at Siteset is product development and innovation, our lifeblood is the delivery of our ongoing support and content management service. We have an experienced and highly skilled team of Client Service Administrators and Assistants diligently servicing the continuing stream of client requests for support, whilst maintaining an exceptionally high service level agreement (SLA) with a strong and resilient team spirit. They are our foot soldiers and without them, Siteset would be up a creek without a paddle.

So it seems unfair that we in the projects and product development teams get to play around with all of this exciting and inventive Agile stuff, while our service delivery colleagues relentlessly beaver away on their workload. In a sense, their consistency and reliability enables the other teams to experiment with new Agile business practices and approaches, giving them a working lifestyle that they have come to expect! The least we could do is work out how they could also get a slice of the pie.

However, since starting our journey into Agile, this has been easier said than done. We had grown painfully aware that a lot of the literature and frameworks out there simply are targeted more towards product development and project delivery, than ongoing, business-as-usual service delivery.

We were beginning to consider that, perhaps, the two worlds were just not compatible. But then, as happens so often when you are on the verge of giving up, we finally started to gain some traction with it!

We have moved away from trying to shoehorn some of the ceremonies found in certain Agile frameworks into the Client Services Team’s routine, and stopped trying to impose principles and philosophies that are not designed for the service delivery environment. In fact, all we have done is to consider some of the Agile buzzwords and adopt good old common sense to assess how we can benefit from applying them. Here are some examples:

Shared Responsibility

One for all, and all for one.

It is a universal truth that, whether the entire workforce realises it or not, each individual is contributing to the same goals: to keep the business operational by excelling in its given sector, and justifying its ongoing existence.

However, a side effect of traditional forms of matrix management structures is that they inevitably lead to members of staff growing disillusioned with their role and failing to appreciate the importance of their contribution to the wider organisation’s success. Senior and Middle Management carry the pressures and expectations of their departments on their shoulders, and exist to protect their staff from those same pressures, whilst staff can be content to coast in their roles, avoid putting their head above the parapet, and fail to fully buy-in to their role in supporting the business in achieving its goals.

Siteset’s Client Services Team embraces its shared responsibilities. They each know what they and their team is judged on, and how success is measured, and they work together to ensure that they are succeeding. It is not one person’s job to pick up the pieces when jobs overrun or threaten the SLA. By sharing this, it contributes to fair and equal workloads, a high performing team and a positive, supportive working environment.

In projects, we have the luxury of compromising on Time, Cost, Quality or Scope in order to make a project manageable. In service delivery, there is no such luxury, and the only way to succeed in delivering a service that meets all of these criteria is to operate as a team.

Empowerment

With great power comes great responsibility.

As an extension of ‘shared responsibility’ a key tenet of Agile (and common buzzword) is ‘empowerment’. In fact, it underpins ‘shared responsibility’, as arguably that cannot be done without empowering individuals to step up and take greater responsibility than they would have previously.

There will inevitably be a varying degree of domain knowledge and experience within a given team, as the members of that team will have been with the organisation, or working in the industry, for different amounts of time.

However, by empowering individuals to learn more complex aspects of a role, and have the responsibility of being accountable for the delivery of that, you will reap the benefits. That individual will be far more engaged with the job, their team and the organisation, and will undoubtedly have a greater pride in their work. Likewise, the team and organisation will benefit from fewer knowledge and skills gaps, fewer points of failure or bottlenecks, and greater employee loyalty/lower staff turnover.

Autonomy

We are the masters of our own destiny.

A by-product of ‘empowerment’ will be that team members have the confidence of the organisation, as well as its trust and protection, to follow their own initiative and choose their own workload. As SCRUM preaches, this autonomy is a key characteristic of a self-organising team, so the service or support team that demonstrates this trait will have fewer management overheads in terms of delegation and micro-management.

Multi-skilled

The whole is greated than the sum of its parts.

It is natural, and perfectly human, for team members on a support or service desk to have aspects of the job and subject matter that they prefer to others, and maybe even specialise in. Sometimes this can happen to the extent that individuals become siloed or, even more extreme: the entire team is made up of silos!

In practice though, this doesn’t really do anyone any favours. It encourages dependencies and bottlenecks on particular individuals, discourages professional development and betterment across the workforce and facilitates complacency.

It is far more desirable to have a multi-skilled and versatile team with built-in redundancy (in the sense that you don’t have single points of failure, not that everybody gets fired!).

A good way to transition a team of silos to a multi-skilled one is to encourage peer-to-peer learning, which, similar to pair or mob programming, involves the knowledgeable member of staff (the mentor) sitting with the colleague with the knowledge-gap (the learner) and coaching them through the task or subject matter. The next time that or a similar need arises, the learning colleague can take the lead on the task under the supervision of the mentor, with this approach being repeated until the learner has consolidated and embedded the new skill.

The initial investment in time to facilitate this knowledge transfer will pay dividends with the long-term benefit of upskilling the workforce.

Interactions

Sharing is caring.

Not all of the Agile (and, in particular, SCRUM) ceremonies that we have tried to adopt with the Client Services Team have stayed the course, but two that are now fully integrated are retrospectives and stand-ups (with a twist).

To begin with, retrospectives are a no-brainer. Getting into the habit and discipline of a regular meeting to review the various elements of the team’s work and environment is a sure-fire way to encourage communication, transparency and continuous improvement. By having a forum to identify things that need to change, and a process to revisit and review the progress of those changes, improvements will happen. The fact that this change is driven by the people doing the job ensures that the change is worthwhile and for the greater good.

Stand-ups have proven to be less cut and dried than retrospectives. We tried stand-ups like in SCRUM, with each team member reporting on what they did yesterday, what they’re doing today and what issues they have. The first two are a bit irrelevant in service delivery and support environments, as, moreover, what you did yesterday has little bearing on what you’re doing today, and you do not necessarily know what support requests will need to be done today. There is also less diversity here than in product development, so each day’s stand-ups would be indistinguishable from the last. Finally, this wasn’t actually providing any value to the team, and did not provide the value that it does in SCRUM, as the team is not collaborating on building something, so does not need this regular status reporting.

An element that has developed organically though is that the team discuss any factors that may determine where they need to focus their efforts, so it is more of a collective call to action to identify anything that they, as a team, need to do today.

The third part - what issues you have - is paramount, and is the most valuable aspect of the Client Services Team’s daily stand-up. They will discuss any impediments that they have, which will flag that a colleague needs to provide some assistance, as well as any issues that they may have encountered (but not been impeded by) that the other team members need to know about.

A final benefit is that it is a regular touch point for any remote workers, both in terms of keeping them in the loop, and allowing them to contribute in discussing issues affecting the team.

Ultimately, the team will benefit from increased interaction and these ceremonies will help to facilitate that. It should be stressed that the team’s communications should not be limited to these ceremonies though; constant communication throughout the day will further foster a highly functional and productive team.

Mastery

I can explain it to you, but I can't understand it for you.

Our Client Services Team has t-shirts with the above slogan. This perfectly encapsulates the power of mastery, for, once you have understood something, you can then explain it.

By encouraging and emphasising the importance of mastery of a given subject or issue, and providing an environment that facilitates this, the team becomes increasingly capable of providing a thorough, diverse and robust service to cope with issues and requests of all different types. It also puts team members in a position where they can provide effective peer-to-peer mentoring with colleagues new to the subject area, or new to the team.

Continuous delivery and improvement

If we stand still, we go backwards.

Whilst the practice of Continuous Delivery is specific to product development, the high-level concept applies naturally to the service delivery and support environments.

Teams will often work from a ticketing system’s backlog, with expectations and SLA commitments around how long tickets should remain in the backlog, as well as how long they take to progress to ‘Done’.

By consciously acknowledging the principle of Continuous Delivery, the team will recognise that one of their primary measures of success is the frequency and velocity of their throughput (known as cycle-time in Continuous Delivery) and they will strive to reduce it without compromising on quality.

Automation is a key factor in the practice of Continuous Delivery, and we are always looking at ways in which it can be leveraged in the Client Services Team’s day-to-day work to reduce their cycle-time. Ticketing systems, such as Zendesk, provide the platform for such automation where possible, and this is likely to become an increasingly more valuable tool in the Agile service delivery team’s armoury. The key is ensuring that this doesn’t come at the cost of high-quality service and human interaction.

Another of Agile’s ‘continuous’ buzzwords is that of ‘continuous improvement’, and any Agile team worth its salt is always looking at how it can change and evolve to keep improving; the Agile service delivery or support team should be no different.

+++++

We would love to hear from you if you are also adopting Agile in your service delivery, so do get in touch if our experiences and stories are of interest to you and you would like to continue the discussion. Equally, please feel free to share any of your own experiences or challenges in trying to make your service delivery more Agile. 

Back

Who’s got your back?

If I was to give the board at British Airways one piece of advice today it would be this; immedia...

Read More
  • Agile
  • Data
  • Quality

A Christmas Dream

The office was alive by the time I got there, my brilliant team showing just how they care...

Read More
  • Agile
  • Culture
  • People