The original approach to customer management was very low-level, process-oriented and didn’t hold the customer in mind, resulting in multiple hand-offs of information and a lack of transparency both for the customer and as to what the end to end experience was.
Over the years the number of systems used to manage these processes had grown unmanageable, with many of those systems requiring specialist knowledge and training and being difficult to maintain and adapt to a changing business. A large number of systems was leading to long call times and dissatisfaction from both customers and the operators themselves. Also, a large number of outsourced staff had been recruited to manage the inefficient processes required to operate around the deficiencies.
It was decided to create a new platform that hid this complexity from the operator, freeing up their time to have more valuable interactions with the customers and the customers time by not having to wait for processes to complete.
FIRST STEPS
A single Scrum team was formed and given a simple customer journey to deliver, to test whether the new platform was suitable, and could integrate into the existing systems correctly, After a few months, and navigating several impediments, the team proved the technology, and delivered the new journey. Based on this success the sponsor decided to scale up the initiative and drastically revamp the customer experience. This reimagination of the operations would impact customers when contacting the call centres and as well as many hidden back-office processes.
At the same time, the organisation was beginning an Agile transformation, and the decision was that this programme would be an excellent candidate: we did not know what the solution would be, or indeed what problems were going to appear as we learnt more – both regarding the technology and the business processes.
To get started the Product Owner team identified the critical customer journeys for the call centre and back office customer service process. A variety of measures were then collected, including call volumes and average times. These steps then fed into a prioritisation algorithm to ensure the most significant impact was achieved as early as possible, delivering very tangible benefits to the business and call centres while also giving confidence to the senior executives watching carefully – this was a big, very visible, programme using a new approach to deliver the changes to the business.
We were fortunate in that we had an engaged sponsor, Paula, who was very supportive of creating a new way of working for the company and was happy to start with a blank canvas. What we created together was very similar to Large Scaled Scrum.
Please note, some terms we used have been modified to fit with LeSS terminology to improve clarity.
ROLES AND RESPONSIBILITIES
Product Owner
While Paula would’ve made the ideal Product Owner, it was not possible to get sufficient of her time, so a senior customer service manager, Nigel M, was appointed and given almost full authority to deliver the best product he was able to. Nigel M was the final decision maker, setting priorities across the programme and resolving any conflicts that arose between customer journeys.
Area Product Owners
Our Area Product Owners were customer service managers, bringing both a wealth of knowledge and experience about how the call centres worked and a real passion for delivering the best possible outcome for their teams. They were responsible for individual journeys, explaining the what and why to the Development Teams and
Teams
System thinking
To fully understand the current journeys, mapping all the steps and driving out the real reasoning behind specific actions a small group of systems thinkers took the lead. This team created current “as-is” maps of the journey and co-created the “to-be” journeys with the Development Teams and Product Owner team.
Business change
As the programme was wide-ranging, we would be impacting not only technical systems but also how the business ran. To deal with this we had a team of business change managers, many with experience in both IT and business change, to work with the broader business ensuring we had a smooth pathway to live for all aspects of the programme. Due to the broader organisation not being in-scope for the Agile transformation at the time, many of the tasks needed were likely to be long-running and to manage this the Business Change team used the Kanban Method to accomplish their work.
Development
Starting with one team, growing to four and over time we scaled to twelve Development Teams, using Scrum, to increase the ability of the programme to deliver what proved to be a very significant piece of work. The teams were fully cross-functional, not only incorporating developers across the systems, analysts and testers but also subject matter experts in the call centres, communications and many other departments, though with the diverse technology stack this did lead to overly large teams on the whole.
Some of these teams were co-located, but we also had dispersed teams between the UK and India which were a real problem in the beginning, mainly when building new and complex solutions across multiple technology stacks. Once the teams deliver the first significant milestone, the teams then self-organised into new teams that could work with autonomy and be the guide of 3-9 people, resulting in increased efficiency with fewer people.
The Development Teams were assigned to particular Requirement Areas, roughly equating to customer journeys, but there was movement between Areas as priorities changed, and capacity was needed elsewhere.
MAKING IT WORK
There was a single Product Backlog across the whole programme, composed of the customer journeys that would deliver sufficient return on investment. The Product Owner team prioritised the Backlog using a simple algorithm that incorporated the approximate effort involved in delivery, volume of calls received, number of FTE impacted, impact on customer satisfaction, impact on employee satisfaction – all weighted for relevance. An additional variable termed “The Paula Factor” was also included, which came into use when Paula needed to increase the priority of an item but couldn’t necessarily disclose the reason why. This algorithm allowed Nigel to prioritise the work led principally by CD3 (Cost of Delay Divided by Duration), though he took into account a variety of other factors.
Once a team pulled a customer journey from the Product Backlog, it would flow through various steps, often incrementally and iteratively. It was essential to keep things moving like this as the organisation traditionally spent a long time in analysis and had a culture that rewarded certainty over progress – something the broader transformation was looking to change.
Educate everyone
The first step we took was to begin running training courses, educating everyone involved via single day introductory training for all team members, dedicated Product Owner training, including the sponsor of the whole programme and specialised Scrum Master training. This education meant that we started with two important aspects covered:
- there was a basic level of knowledge throughout the programme on how we intended to work together, and
- there was a shared understanding of the new terms used in an Agile environment.
These two aspects meant we short-cut several common problems that appear in programmes, for example when the senior management want changes they knew to take them to the Product Owner rather than directly to team members.
We continued to support this education with ongoing sharing of challenges and critical learnings, within and across teams, via lunch and learns and check-in sessions across disciplines such as the Product Owner team, Scrum Masters and Business Analysts.
Deciding what to build
The Product Owner team, supported by dedicated system thinking experts would get a good idea of what the current business process was, including which systems were used to service the demand. This approach was often a combination of expert knowledge, mainly from our Area Product Owners, sitting with the operatives as they went through the process and interviews.
When the team felt it had sufficient, using the 80/20 rule, understanding of the current process, we then ignored it all.
Starting with a blank canvas the Product Owner team, with representatives all the other teams, created a new process that they felt was the best possible experience for the customer. This process was created by ignoring all the constraints, such as systems and regulations, and thinking about it from a customer point of view – what is the minimum you need to do to service the need. As the team grew in experience, this became a crucial stage not only for envisioning innovative approaches to the problems but also for driving out more fundamental issues: were we servicing a failure demand? Did the process need to exist? Could things be achieved through a different method?
Once we had our 2020 vision of the process, we then overlaid reality – what systems interactions occurred, what other business processes needed information, what regulations were relevant. This final step in deciding what the new process should look like was then used to communicate the vision for the process to the stakeholder.
Breaking the work down and building the product
Once the new business process was good enough (remembering it had been co-created with the Development Team) it was taken into an Overall Product Backlog Refinement and split further. The primary method for splitting was what one team affectionately referred to as the “Underground Map”: creating scenarios that flowed through the process and only creating user stories for those “stations” that were touched – when done in colour, this looked a lot like the London Underground map. A significant benefit of breaking down the process in this way was that you could have releasable software very quickly if only for a small proportion of the volume entering the journey, that could be placed into pilot speedily and live feedback received.
The typical outcome from the Overall Product Backlog Refinement was that a single team would receive the whole customer journey, however a few journeys were so big that they had to be split between teams – though a lead team would always start a Sprint or two before others joined to ensure there was a walking skeleton to build from.
Reviewing the product and process
When it came to the end of a Sprint the Development Teams in each Requirement Area came together and had the Sprint Review with the Area Product Owner. However, every other Sprint the programme came together and reviewed as a whole – this meeting allowed us to keep communications open across the Teams, keep everyone appraised of what was happening across the programme, and to give the teams opportunities to feedback into each other’s journeys.
Learnings from Development Team Retrospectives were shared predominantly via the Scrum Master community. However every three months an Overall Retrospective was conducted, gathering improvements ideas for the programme’s running and organisational changes. However, this was not the only route where the teams identified improvement opportunities: there was an ongoing dialogue between the sponsor and Product Owners seeking ways in which the programme could be both accelerated and the environment made more pleasant for the Development Teams.
CONCLUSIONS
Though we did not create a perfect approach to delivering the new product, we certainly had successes throughout the year.
- Educating everyone up-front meant we were fortunate to not have competing agendas within the programme (though they indeed existed across the organisation).
- Having a single Product Owner, as this meant that we could (almost) always get a decision quickly on both priority and feature content.
- Having customers as Area Product Owners, as they brought real passion and vision to the Development Teams, exciting and enticing them to deliver exceptional systems with genuine impact.
What we would do differently
Alongside the successes, there were excellent opportunities to learn. For the next initiative of this scale we would strongly consider:
- Increasing the frequency of the Overall Retrospective: would prevented some of the discussions within the teams about how the organisation was not trying to support the initiative. Opening the dialogue with the sponsor would’ve increased visibility/transparency and stopped many communication issues.
- Staying smaller longer: due to pressures from the organisation we scaled the approach too soon. Ironing out more of the development issues, particularly the “path to live” for the software, before adding additional teams means the whole journey would have been smoother.
- Co-locating teams: the teams working in the same ares formed as much better units. These teams created a real sense of “togetherness” and developed the safety to innovate and deeply challenge the way the business worked.