SAFe Transformation at PCCW Global

With the support of the executive leadership of PCCW Global, CTO, Paul Gampe, made the decision in early 2018 to adopt the Scaled Agile Framework (SAFe). Since 2018 PCCW Global has been on a continuous journey of launching Value Streams and Agile Release Train. Join this session to learn about the challenges faced and the wins achieved with the truly global (APAC, Europe & USA) SAFe transformation at PCCW Global over the past 3 years.

About Paul Gampe

Paul Gampe became Chief Technology Officer (CTO) of PCCW Global in late 2017 and is able to draw on 20 years of experience in IT operations, software development and international business.

He had previously held CTO posts at Console Connect Inc and NEXTDC, and served as Vice President of Worldwide Engineering Services and Operations at Red Hat. Operating as a senior software executive with a substantial technical foundation, Paul has led multidisciplinary teams globally for over 20 years.

Paul holds a wealth of experience in all aspects of the software industry – especially in terms of acquisitions, investments, development, quality engineering, program management and operations – and has led multidisciplinary teams on a global basis. He is an expert in open source technology has worked extensively in the fields of cloud computing, networks and data centres, and has earned a track record for delivering outstanding financial results

Transcript

Em Campbell-Pretty: Welcome folks. Thank you so much for joining us for another SAFe Australia online meetup. It looks like we have a fairly strong Australian contingent today. I can see some folks from Perth and Sydney. We are of course in Melbourne as always. John is of course in Singapore. Paul, our guest for today, is I'm assuming in Brisbane...

Paul Gampe: I am Em.

Em Campbell-Pretty: It's actually nice here today. There is sun outside. I haven't been outside, it's probably cold. But It is sunny.

Adrienne and I met Paul ... I think it was February 2018. It was kind of an interesting journey because the year before I'd had an email from a guy called Lawrence, who worked for a company I'd never heard of called console.io or something like that. And he said, "I'd like a quote for a Leading SAFe class. I gave him the quote and I never heard from him again, such is my life! These things happen…

Then somewhere in very early 2018, [some] people have that quote but work for a different company. They're emailing me from PCCW Global about the quote I gave Console nine months ago. And I'm like, this is really weird. Anyway, you kind of just take the business. Right?

So, I turn up with Adrienne in Brisbane, in the smallest possible meeting room that Paul's organisation could find, where he has gathered his leadership from all across the globe, squished them into a room with us and we have managed to run a Leading SAFe. I discover through that, that the company that was Console had been acquired by a different organisation called PCCW Global.

We went on to have some adventures with Paul, and he's been playing with the Scaled Agile Framework in various guises ever since.

We always get requests from you guys to hear about what's going on with SAFe in the real world. And I thought with three years under his belt now, Paul probably has some good war stories for you.

Paul is the CTO, CIO, SVP of technology. He has a heap of really fancy titles for his role at PCCW Global. I think you were one of the founders, Paul, of Console Connect, is that right?

Paul Gampe: The first technology person to join the organisation.

Em Campbell-Pretty: Right. And you guys were acquired ... I don't know, sometime in 2017, I'm guessing...

Paul Gampe: Correct.

Em Campbell-Pretty: PCCW Global. For those not familiar, is, I think, a wholly owned subsidiary of Hong Kong Telecom. Did I get that right?

Paul Gampe: Yep.

Em Campbell-Pretty: Anyway. I'm going to let Paul talk for himself because he's great at that. Thank you very much for joining Paul. For everybody else, usual things. Video on if you can. Questions through chat and we'll read them out to Paul as we get an opportunity. And over to you Paul.

Paul Gampe: Great. Thank you, Em. Good morning. Good afternoon, everybody. As Em mentioned, my name is Paul Gampe. I'm the chief technology officer for PCCW Global, which is one of the operating divisions of Hong Kong Telecom. And it's interesting to hear Em's version of the acquisition story.

I joined a Silicon Valley Venture Capital backed start-up in 2014, focused on creating connectivity. As workloads begin to move to public cloud, different forms of connectivity for those workloads emerged and we were a start-up that were acquired in November 2017. That's where, as Em alluded to, that's where our journey around the Scaled Agile Framework really began.

I'm just going to share a few slides as Em guessed, I'm using these as a talking point to help remind myself what I need to talk about.

Choosing the Scaled Agile Framework

What I wanted to talk about first is how we ended up with the Scaled Agile Framework, because I think that's a really important part of our engagement with Pretty Agile and the journey that we've been on ever since.

The majority of my career was in enterprise software. I've worked as the VP of engineering for Red Hat. It's a large enterprise software company, managing 1,000 developers worldwide. And despite the fact that it's a software company, Agile is not part of Red Hat's DNA at the time that I was there.

I worked with a lot of customers who had adopted Agile but had never really deployed a framework. After the acquisition, in December 2017, through to when we started working with Em and Adrienne in March, I toured all of PCCW Global's facilities worldwide.

After the acquisition they asked me to take on the CTO role and, gave me, different functions in the organisation to lead. Part of that journey was a meet and greet with new colleagues I would be managing. Corporate Services - our IT department, IP engineering - which operate the sixth largest network in the world and various other acquisitions that PCCW Global had made, prior to acquiring Console Connect. There’s a couple of development communities throughout Europe, in Athens and in London and Reading and Belgium. So, there's a world tour to meet all these different operations.

Stepping back, PCCW Global is one of the largest international telecommunications providers. About 1300 staff, worldwide, 57 offices around the world and [they] speak over 35 languages within the company. So, it's a very diverse multicultural community that we have inside the organisation.

As part of that tour, meeting with, IP engineers, meeting with business leaders, meeting with software developers, I began to sense, the traditional silos that the Scaled Agile Framework is often used to identify and dissolve, and a disconnect between the business and the technical community in the company. I had a gentleman who was, joining me on that tour. And as we'd fly from country to country, I'd often say, "Oh, Henry, I think something of an Agile approach could really benefit the engagement between business and technology in the communities that I'm meeting."

This is probably six-week world tour. It became more and more obvious that most of my recommendations were around adopting an Agile way of working. That led to, the quote that Em, mentioned earlier. I had looked at different Agile frameworks from an academic perspective, LeSS and SAFe and others. Lawrence who has worked with me for many years, had already done quite a lot of research in SAFe, and said this was the right framework. So that's where our journey began.

Training the Senior Management Team

Training the Lean-Agile leaders was perhaps the most important thing that I think we did in terms of our transformation. There had been some academic debate internally among the leadership about what framework to use and which one would be right for us. Different telecommunications providers around the world, have adopted different frameworks. The key thing, I think, once we began to do this leadership training with Pretty Agile, was that we committed. We ended any debate about whether this was the right framework for us or not, whether we believed in Agile or not, as an entire senior management team, often referred to an executive leadership team here in Australia, but the PCCW Global refers to as SMT.

Training the Lean-Agile leaders was perhaps the most important thing that I think we did in terms of our transformation.

Paul Gampe, CTO, PCCW Global

For all of our Senior Management Team from hardcore network engineers, network operations executives, marketing, CEO, there was this collaborative commitment to transform. And for a need to transform. I think the one thing that really... Throw the question back to Em and Adrienne, is that we left that training exercise and value stream identification workshop with a real sense of urgency that I didn't anticipate inside an organisation of this size.

Em Campbell-Pretty: Yeah. I think you guys wanted to start to move really, really quickly. You went from really slow… I think that first course was in February. And that executive course…. We did another visit with you and a few others in Hong Kong to basically get the okay to do that executive course.  I think that was June, July, August, somewhere. Then that executive course was the first or second week in October. And we went from da dada dada da… to can we do this tomorrow? And we're all like... kinda.

Paul Gampe: Exactly. I think the key takeaway there was that commitment. As we're now three into our transformation journey, that, commitments never wavered. In the conclusion part of this story, I can talk about how we've continued to leverage the framework further.

If we hadn't had that level of commitment and that level of, discipline and rigour in applying the framework that Em and Adrienne brought to us, I don't think we would've been as successful as we have been successful. And whether we're successful or not is arbitrary, but I certainly feel like [we've had] success from it.

If we hadn't had that level of commitment and that level of, discipline and rigour in applying the framework that Em and Adrienne brought to us, I don't think we would've been as successful as we have been successful.

Paul Gampe, CTO, PCCW Global

Identifying the Value Streams

I want to talk a little bit about this identifying value streams, because it's [a] really critical part of the framework that. We've continued to expand our technology community worldwide. We're recruiting here in Brisbane, we recruit in Hong Kong, and we often encounter, team members who've worked in other organisations that have adopted SAFe. This component around value streams was a really important learning opportunity for us as an organisation and me as a leader.

I think Em and Adrienne were expecting that we'd do the traditional methodology ... What are our products? Are our products being delivered through a set of systems? Can we put those systems together? Can we identify the people that support those systems and form Agile Release Trains?

But the way that identifying value stream workshop transpired was using it as an opportunity to think about where we wanted to be, not where we are. That allowed us, certainly for me personally, to leverage the framework to drive transformation and the way that the organisation had seen these conductivity industries under dramatic transformation. Not just from a technical perspective, but if you look at the traffic patterns of connectivity around the world, as you can imagine, voices declining, IP traffic is exploding. The way where traffic moves is now very different to where it was in the past. It needs to be on-demand. It can't be a managed service. The senior management team, who I'd only been with for a few months, really leaned into this opportunity and said, "We're going to focus on self-service. We're going to focus on data and we're going to focus on IoT."

That certainly presented lots of problems for us, as I'm sure Em and Adrienne would love to share because we weren't aligned specifically around revenue lines. And, when you try to force a big ship to move, that obviously causes lots of challenges. I don't want to de-emphasise how important that was for us. Of all the value of the Scaled Agile Framework, this value stream identification exercise was really, really valuable.

Launching Agile Release Trains

I'm just going to talk through each of the trains and some of the learnings that we've had as we've launched Agile Release Trains.

The First ART - Data and IoT

This was the first one. This is our data and IoT train. This one would have launched in March 2019. About six months, I imagine, after the executive training program, value stream identification exercise, systems identification, inventorying all the systems and then identifying the people who support the systems forming Agile Release Trains and teams and away we go.

What you see here is a combination of probably the biggest challenge that we faced as an organisation. We were a very small software development community in Silicon Valley, venture capital, very high velocity, product-centric development community. We are 30 people, and then we're being acquired by an organisation of just under 1,500. We represented to them everything that they had hoped to achieve in their transformation. We were able to automate networks globally. We were able to provision services on demand via an ecosystem of platform economics effectively.

The demand set that they brought to bear on this little development team was staggering. We can see here by the number of people, that came from our headquarters to participate in this planning exercise. If we hadn't had, the framework, I don't know how that integration would have gone, but we leaned right into SAFe, and said, "This is the way that we're going to operate, and this is what we're going to deliver in the next 90 days."

And we did. We were within 90 days of the acquisition; we were automating the PCCW Global network. We had a software architecture, we had a methodology for engagement, and we were able to start to make progress, which I think is often the challenge that's faced when you're starting integrations and particularly when you've being acquired for a particular technology asset.

That really is an important part for me. Because the biggest challenge that we faced wasn't just trying to connect a software development mindset with a network engineering mindset. It was coming up with a common language to help everybody in the organisation begin to understand what we're going to do when we're going to do it. That is where we started to identify some of the other aspects of the value of the framework, particularly around inter-train dependencies, which was a really challenging area for us to navigate.

I'm going to pause here. Em and Adrienne were with me on this part of the journey. So, I'm going to see if they've got anything I'd like to add.

Em Campbell-Pretty: I do love the photo of you two embracing there Paul. It's one of my, favourite executive leadership moments when we got to the end of your planning event. At Pretty Agile, we like to have the senior businessperson and the senior technology person give a handshake in front of the train and take a photo. And these two guys hug! So that's the SVP of Product, I think Jordick was at the time, and Paul embracing at the end of the first PI Planning.

That was such an awesome week. Still such a highlight for us. Really fun group of people. One of the things that was exceptional about that from our perspective is you flew everybody in from wherever they needed to come from. You had folks there from, from Europe, from the UK, from the US, and from Hong Kong. All of us were in Brisbane, which was really, really amazing. It was really exciting launch for us.

Paul Gampe: Yeah. Thank you, Em. It was really exciting for us too. And a lot of the little subtle disciplines that you've shared with us, always trying to protect us from making mistakes that you've seen other trains do in the past, have been copied and carried forward. This process of getting the business and the technology leadership to commit to the plan is worldwide. Every train does, even virtually now that we have to do it over video, and we do that ceremony because we know it's so important because Em and Adrienne said so.

This process of getting the business and the technology leadership to commit to the plan is worldwide. Every train does, even virtually now that we have to do it over video, and we do that ceremony because we know it's so important because Em and Adrienne said so.

Paul Gampe, CTO, PCCW Global

Em Campbell-Pretty: I'd like to see a photo of a virtual hug one day, Paul.

Paul Gampe: All right. Planning is at the end of June.

Em Campbell-Pretty: I look forward to it.

The Second ART - Corporate Services

Paul Gampe: The second train we launched, and you can see the confidence votes and the T-shirt branding was Corporate Services. This is our traditional IT department. I play a dual role in the organisation. I'm both the chief technology officer leading, the product development, particularly the self-service, on-demand product set, but also play the CIO role. So I lead internal functions. This would be your ERP and accounts receivable, accounts payable, your collaboration suite.

The real benefit that we got from this community, which is in Hong Kong here, was transparency. We had a PP ITPC - Project Planning Information Technology Planning Committee. When I joined that committee, there was well over 50 projects in flight, and a large suite of Gantt charts to track their delivery over time. There really was a low level of confidence at that point in the teams' ability to deliver on time.

As we began to do this Agile Release Train identification and launch, the key benefit from the Scaled Agile Framework for me from this one was to give the teams confidence that when they said that they could commit to delivery in the next, you know, PI, then it would happen. The community you see here have gone on to achieve, predictability rates of above 90% since they've been operating.

This train launched in June 2019. The real benefit, talking about agile ways of working is, this trust that's begun to develop, when a feature or an epic ends up in Corporate Services, this team is really trusted to deliver. All of their Agile artefacts, their PI Planning, their feature backlogs, their weighted- shorted job first allocation, their roadmap for feature delivery [are] really, really well done. This team, which originally had a reputation for an inability to deliver is now perceived as very reliable. And it's core.

A big part of transforming a traditional managed services telecommunication provider into a technology company is being able to do things like pay for invoices on demand, pay by credit card, provision services instantly and have a subscription revenue model. You can't do that without an Agile ERP and an organisation that's got a really good relationship with the financial function. The business owner for this Agile Release Train is our CFO. So we've got really strong business technology commitment, and all of our epics and our PI objectives are voted on by the business.

Em Campbell-Pretty: Paul there's a question in the chat. "I'd be interested to hear if you've experienced challenges with time zones for PI Planning now that you've moved to virtual and if you have any tips on how to mitigate." My bet is, you guys are having all sorts of fun with time zones and virtual.

Paul Gampe: Yeah. So that's a great segue into our next step to our next Agile Release Train.

The Third ART - Interstellar

This photo is probably in Reading or London. At this point in our journey here, this is our third Agile Release Train we're launching, and you can see here, I'm not there. So this is the first time... I'd been directly involved in all of the Agile Release Train formation [up until then], and now we're beginning to expand internationally.

On the screen here, you see teams from Athens, from London, from Reading from Belgium, from Hong Kong, from the United States, and from South Africa, just to give you an example of the time zone challenges that we face as an organisation. This is in July 2019. Here is where we really started to struggle particularly with inter-ART dependencies.

This development community that you see here, [was] predominantly built by a series of acquisitions, prior to me joining via acquisition. Unified communications as a service platform, a threat management system, mobility, data enrichment and visualisation technology. So really quite deep data science expertise, and a large portfolio of online applications delivering a lot of value but without any sort of framework to coordinate, with the product and business functions operating out of Hong Kong.

We really started to see the silos break down once we had this group of disparate acquisitions aggregated into what we call Interstellar. Predominantly a development community around our mobility and voice products. Immediately the tension started to decline between the technology and the business function, because there's sufficient knowledge around the Scaled Agile Framework.

By this point in July, we're probably approaching 200 people [that] have been trained in Agile. We started to engage with different coaches. Because of this European footprint, we involved a training team out of Europe. We started to notice the difference between Pretty Agile training and other training, and some of the ceremonies that we've now come to entrench in the way that we do Scaled Agile Framework, have come from the learnings that we had from Pretty Agile. We even started to see the way epics and feature slicing was being taught to this community was different to the way that we had been taught to do it. It's taken a while for us to unwind some of those challenges.

We started to notice the difference between Pretty Agile training and other training, and some of the ceremonies that we've now come to entrench in the way that we do Scaled Agile Framework, have come from the learnings that we had from Pretty Agile.

Paul Gampe, CTO, PCCW Global

At this point in the journey, we're struggling with time zones. Not all senior leadership were able to get to the PI Planning events. We're beginning to see the benefits certainly into the forming communities, but we're struggling with time zones. And where we ended up is.... I'll comment on that when I get to the end because we did a planning event in 2020.

The 4th ART -  IP Connectivity

By September 2019, we're accelerating. At this point, we've identified all the Agile Release Trains that we intend to launch. We had marked five coming out of the workshop that we did with Em and Adrienne.

Here we are launching the IP connectivity [ART]. This is a core revenue engine of the business. This is AS3491, for anybody who's a technologist on the phone. Today the fifth largest IPV4 network in the world. So [a] very highly skilled, highly valued technical community generating a lot of value for our users and for the enterprise.

The takeaway for us here was two things. The framework immediately brought to light the workload. There was not a lot of resistance, but there was certainly organisational resistance to adopting an Agile way of working in this community. Having been a network engineer in a prior career, I can see why. If your application fails and your webpage doesn't load, the general bias of the consumer is you hit reload and it's okay. You know, there's a tolerance for failure at the application layer

It really took some time for me to spend with this community to remind myself that the blast radius for failure of the fifth largest network in the world is pretty big. So you really can't fail. When you're faced with that sort of pressure, you tend to resist change, because you trust what you have done in the past and it's given you this ability to deliver in the now, and you anticipate it's going to give you the ability to deliver in the future. What we needed to do though, was change. Because delivering services via our managed services with tickets and engineers logging into devices, the error rate is still high if you've got human intervention and it doesn't map to the way that organisations are operating today. You need agility and to do that, you need to automate.

This community had been attempting automation. They knew it was there, but they weren't able to achieve it. The Scaled Agile Framework gave us a way to have this community start to talk about epics and features and to start to slice work. Tools that they'd never had before. They knew they wanted to automate, but they didn't know how to go from I want to automate the network to, I want to automate a layer two service, I want to automate a layer two service between this port and that port. And so the framework was immensely beneficial in educating this community about how to begin to break down work. I know that sounds trivial and obvious, but it was a real important learning for particularly this train.

What we learned, as Em and Adrienne are great at saying, [is] just bring all work onto the train. Whatever resistance you may have, you know, "I can only do 20% here," and then we faced a lot of that and saying, "Oh no, I can't be fully dedicated." So we said, “You and all your work can come to the train and we'll visualise it and we'll see what it is.”  That was really powerful. It disarmed a lot of reticence we had to implementing an Agile Release Train around our core revenue engine. Once we'd brought all the work onto the train, I said "Wow! Holy cow! This team is doing a huge amount of work." And we could start to see the metrics, the tasks, backlogs, the feature backlogs, the complexity that they were dealing with.:

So that was my takeaway from this slide, just bringing work onto the train and using those tools [such as] kanabn was immensely valuable for us because I hadn't seen that workload before. It wasn't structured in a way where it was visible.

Because the network was our core asset, we could start to do inter-train dependencies. We already had two trains in flight. Here we had this train, Data and IoT, automating the network, but they'd email network engineers saying, "Can you do this config so that I can start to talk to this router?" We could start to do inter-ART dependencies. The Release Train Engineers will begin to coordinate and say, "When's your PI Planning? I've got a backlog of features I need you to implement. So, we saw this emerging, lean portfolio management function occur organically as we got up to our fourth Agile Release Train here.

Fifth ART – Delivery and Support

Again, another train where I'm not present, this is our Delivery and Support Agile Release Train. This is at the end of 2019. This is where sufficient knowledge about the Scaled Agile Framework had gone beyond the community that were directly reporting to me. I appreciate the bias in an organisation, everybody who works for me is going to do agile because I told them to do agile. When here, what you see is a community that's just had access to training.

By the end of 2019, we've formed our own lean agile centre of excellence. Em and Adrienne have trained quite a few SPCs in the organisation and we're now taking on that training load ourselves. And people are volunteering to get trained.

What you see here is our support organisation, which is large, between three and 400 staff worldwide. We've got network operation centres everywhere in the world, saying, "We think we can form an agile release train, and we think we can really benefit from doing so." We have Jupiter and Mars, and feature teams start coming together, and they identify systems and identify backlogs and they decide what they want to achieve. It was really, really powerful and wonderful to watch this agile release train form and take flight. At this point, I'm off looking after the technology trains and then we start to see inter dependencies between the support and the technology organisation. So great to see.

Sixth ART - Platform

Beside the traditional Scaled Agile Framework implementation roadmap, you might've seen that I added this, last item - integrate release trains into our digital platform. And I know Em and Adrienne are great fans of digital platforms. We actually had a vision of building a digital platform because we've actually achieved quite a lot of our transformation.

By the end of 2019, this is starting to look like it could be real. Like we actually could build a platform economic model, because of the successes we've had in moving a lot of our value into on demand services. Ambitiously we decided we're going to launch a platform, Agile Release Train, and begin to get that layer of functionality needed to unlock the other Agile Release Trains.

Here it is. This is actually at PI Planning in January 2020, in Hong Kong weeks before, actually probably only days before, COVID-19. We learned a lot about the platform Agile Release Train. The key takeaways for us were two things.

By this point, our lean portfolio management function has started to provide some pretty rich data. As we're launching this train, we now know how much of our economic investment is in horizon one. We know how much is in horizon two, and we know how much is in horizon three. And we know the profile is not looking the way we want it to. By having all of our epics and all of our features categorised, and an economic model where we invest in sustainable long-lived Agile Release Trains, we can quite categorically say okay, this is how much we're spending per annum on horizon one and horizon two and horizon three.

By now, we're starting to get fed with intelligence to help make good decisions. One of the decisions we said is okay, we're [going to stop] starving horizon three. We really believe, and I personally believe that distributed ledger technology is critical to the success of the telecommunications industry. The idea that I'm going to have a long lived, permanent internet connection from an IOT device is just nonsensical. This IoT device has got a- a 30-minute lifespan or a one-year lifespan. It needs to connect to a cloud, and then it's going to go away, but there could be 10,000 of those IoT devices. How are you going to settle for that? Are you going to pay by invoice? Are you going to pay by credit card?

The transaction volume is going begin to exceed traditional payment methodology. We needed to start research into distributed ledger. So, we work with the MEF, CBAN, TM Forum and GSMA. We're now deeply involved, the teams you see here, in a collaborative proof of concept around using distributed ledger, not only to settle, but inventory management between carriers.

To get that expertise, we had to start to integrate third parties. Em and Adrienne, going back to our first lessons in learning, [taught us] "treat everybody as a first-class citizen". So, you see here, three companies that are not ours, all wearing our T-shirts, all at our events, planning collaboratively with us. It's a precursor. Whenever I start talking to vendors saying, "Have you got anybody trained in Scaled Agile Framework?" Because if you don't, we're going to train you and then you can come to plan with us because we're not negotiating on how we deliver value.

That was really, really important for us to be able to get the investment into our horizon three, because you can't just go build a distributed ledger technology team. So we had to work with start-ups and other companies.

Global PI Planning January 2020 & COVID-19

So that was really important for us to have that learning, about treating third parties as first parties when we go into planning. I don't know if Em and Adrienne ever knew this, but it led to a 2020 Global PI planning. We had over probably five to 600 people in Hong Kong, doing a full, all six Agile Release Train [planning], and I'm very happy to report, we even have this SAFe program contributor award ceremony. I know Em and Adrienne are familiar with how the Hong Kong team can run a great show. To watch the polish and finesse of an event planning team in Hong Kong, combined with the Scaled Agile Framework. I said, "We're going to do SAFe really well."

It was great. It was a huge event. We had Release Train Engineers running between meeting rooms. We actually started planning an internet on demand, which for any network engineer on the call, would begin to understand when we talk about blast radius of failure. We left this event so confident that we could automate the internet.

We did actually put that into production at the end of last year. A real highlight of my career and a real highlight in terms of the impact the Scaled Agile Framework can have on an organisation leading this event.

What it did for us though was allow us to touch all of the 400 technologist and the 1-200 business community [members] inside the organisation and establish ways of working, which gave me two things; really high level of assurance that as the pandemic began to sweep around the world and for an organisation that's operating in 57 offices around the world and almost 1500 staff, I got to live through the pandemic hitting London, hitting Reading, hitting Belgium, hitting Virginia, you know. I had staff in every one of these locations and the two things that really, I reflect on through 2020 is that because we did this, I knew that every single colleague was on a feature team.

Everybody had a scrum master who was caring about them. Everybody had a product owner to tell them how they can add value to the organisation irrespective of what might be going on around them. And you can continue to deliver value. Here's your features, here's your backlog. Here's what we need you to do. That focus, you could see the value of it as everybody's personal experience turned from this great moment to sadness and loss. Those Agile ways of working to me are always going to be around the scrum team and that relationship and the community and the value you get to deliver by being part of that.

We didn't lose a beat. COVID-19 or economic impact, for sure, but in terms of our ability to have, you know, greater than 95%, predictability for our ARTs, for us go to market with a world first product, we did it. We didn't miss a beat, and I'm really, really grateful for the framework, for that side of the framework, in terms of what we've been able to achieve.

Redefining the Value Streams

In closing, I know we've only got a few minutes left. And I'm sure in Em and Adrienne are fielding a big backlog of questions. When I was being approached by Adrienne, for some other activities. l leaned into the opportunity and said, "Hey, Adrienne, we're actually thinking of changing our value streams." And she said, "Yeah, sure. Why not? You know, it's a great retrospective inspect and adapt thing." Oh good, okay. We're not the only ones who are crazy enough to give it a go, but we may in fact be the ones to do so.

Over the last three years, we're seeing the power of, as I started this journey with, how you define your value streams transformed the company. When we said, we want to focus on self-service and we want to focus on delivering on demand, we did it. What that's done is it's put us in a position of beginning of this year, saying, "Actually, our journey is not done. We think there's another phase of our evolution. And the big steering wheel that we had to turn the organisation last time, let's use it again."

We've now completely redefined our value streams and want to deliver value in a new way where we're completely in the mindset that we're a technology company. We're a platform economic model. One day you're a supplier, and one day you're a consumer and we're just a platform that allows, infrastructure and applications to come together. So, we're doing it again.

We've designed a whole new set of value streams. We've identified systems associated with those people and those value streams. We're re-designing Agile Release Trains; we're keeping the unit of measure to the feature team and I think that's really important psychologically. We're moving feature teams to align to new value streams. We're doing it again. That's part of our transformation. When the journey with the Scaled Agile Framework [started] the organisation was a managed services global carrier, and now we're the meeting place of applications and infrastructure. And we're onto the next stage of our journey.

Lessons Learned

Here's my lessons learned.

Commitment was key. Marc Halbfinger, who Em and Adrienne know well, the CEO of PCCW Global, is an unwavering advocate of the Scaled Agile Framework and the benefits of Agile ways of working. Never have once has he ever strayed from that position. And it's been incredibly valuable and powerful to help the transformation.

I often get colleagues [telling] me SAFe isn't Agile. Yeah, I'm sure almost everybody on this call must get that all the time. And I certainly get it a lot. And my answer is it's not trying to be. Agile is a mindset. Agile is caring for your community. It's empowering people to do valuable work for users who are going to appreciate the value, transparency, and trust. That's what Agile is to me.

The Scaled Agile Framework is a framework, and it's a really good framework. It's all of these other things you need to help an organisation build successful Agile teams. It's not our job. It's not trying to be, it's a framework and it's a really good one.

Be willing to adapt. I brought in the story about bringing the workload to the train. Part of helping a very large global organisation with a really successful revenue engine, agree to want to change is being open and saying, "Okay, that's not development work. It may be operational work, but we're still going to bring it on the train. There's still something here to help create visibility or create dependency management." And that was really important to disarm the more successful parts of our organisation to be willing to adopt new ways of working.

Inspect and adapt. We're pretty religious. We do retros every two weeks. We do our inspect and adapt at the end of every PI. We produce lots of artefacts, lots of statistical analysis. And the important thing here is that we're even doing it at the value stream level. You know, it's not just a tool for a scrum team. It's a tool for our executive leadership teams, and we continue to inspect and adapt. And then the great quote of course, change is never painful, only the resistance to change is painful. So thank you. I hope I covered enough ground for you, Em.

Em Campbell-Pretty: Yeah. You did great. And it was, wonderful that you can give the- the continuation of the story, Paul. We get snippets because you sent folks to our classes. Anytime someone lands in the class, we go, "Tell us stuff." Um, so I can't remember who but someone turned- turned up in the class, not um, not too long after your global planning and- told us all about all that. And of course, we uh, we watch your adventures on LinkedIn, which is really fun. Some really massive Zoom meetings in the last in the last year.

Q&A

Em Campbell-Pretty: If you don't mind, just a couple of questions for you, Paul. From John Andrews. "Hi, Paul fascinating journey and really impressive. Do you also run a large solution ... Large solution site and have an STE in your setup? If so, I'm interested in how you introduced this role and what challenges you faced. Thank you."

Paul Gampe: Great question, John. We've just started that at the beginning of this year. Two program increments ago, the senior management team is so committed to this transformation that it will often join inspect and adapts. And so we had the trifecta from all six Agile Release Train, present their performance. What was your programme predictability like?

Let's go through the letters to management and as a consistent theme of feedback "we need a solution level." I got quite agitated with the feedback. I said this is just poor inter-dependencies. You're not trying to coordinate work across the whole six Agile Release Trains. You need to get more disciplined at getting your feature backlog to your respective product manager on time.

I said, "But here's ... Let me show you what a solution is." And we're- we're going through a branding exercise, to introduce a new look and feel. You'll notice the slide deck that I presented is quite different from what we did in the past.

So, I said, "Okay. You want to change um, the branding." And marketing thinking, "Oh yeah, that's a 20-minute logo slap on an invoice. We update the website and we're done." So let's talk to all the system architects about what change your brand might look like.

I think we took about eight weeks. We identified 23 systems. We were starting to get project maybe three or four programme increments. I said, "You need a solution train engineer, don't you?" And they said, "Okay. Yeah, right. We get it now." We've got to try to coordinate a large body of work across a large body of Agile Release Trains. I understand what a solution manager and a solution train engineer is.

And particularly now that we're moving to a new value stream architecture, we are really going to need that solution layer quite a lot, because we're using it to transform the business again, moving away from product silos and thinking more holistically about features.

Em Campbell-Pretty: Thanks, Paul. From Rob Howard. "Paul, great story. Well told. Can I ask when you were deciding to go with the framework and which one, as CTO, how did you get other executives buy-in given the change you probably knew this would entail?"

Paul Gampe: Good question, Rob. One of the reasons that PCCW Global is, so successful is because it takes an economic outlook. HKT as our parent has fantastic financial discipline and Em and Adrienne know it. That discipline is a real, strength in decision making if you know how to use it effectively.

So part of the Scaled Agile framework, as opposed to, bringing in McKinsey, or LeSS or any of the other frameworks, is readily available, trainers worldwide. That was a lower cost for us. All of the content is available online on the Scaled Agile Framework website. Zero licencing fees to gain access to knowledge. And certification is, adding value to our employees. So, we're investing in our staff and they can see it.

From the purely economic model, I was very easily able to position the Scaled Agile Framework as the right one for us. Not dismissing McKinsey and the great work they do helping transformation in other companies, but for us, it was really an economic decision. And this was the one that had the highest return on investment in our colleagues and the clearest cost that we could map out to get underway.

Em Campbell-Pretty: One from Annand. "Thanks for the insightful session. What measures were used to pivot epics?"

Paul Gampe: Pivot epics. Sorry. I might need more context to that question.

Annand: Hi. Thanks, Paul, for the wonderful session. So basically, taking a hypothesis on an epic, and then deciding to plan further investment towards creating more. What kind of specific measures so you used to pivot or proceed further?

Paul Gampe: Ah, great. Yep. So leading indicators. Often what we're learning is that taking a hard economic measure is not appropriate. Particularly, what we're finding is some of the features and products we're bringing to market are in one case world-first. So there's not a lot of market awareness. And so that means there's a market education, lead time to getting revenue from a product.

So we're looking more now at leading indicators, like the number of monthly average users. The funnel, how much interest are we able to drive through having this feature in production, as opposed to did we achieve X dollars of revenue in the first 90 days after delivery? So, we're thinking further upstream, looking left into metrics and then seeing if we hit them. And if not, why not?.

Em Campbell-Pretty: Okay. We have exhausted the written questions. So I don't know if anyone's holding back, waiting for the floor to ask Paul the big question? You were too informative, Paul. I think this is clearly the challenge.

Paul Gampe: I time-boxed it, right? I can see the little clock you have in the background counting down.

Em Campbell-Pretty: I thought about putting one up for you. And I thought, "Oh, you're probably programmed by now. You'll be fine."

Paul Gampe: It's here. It's here beside me on my desk. Laurence went and bought three of them.

Em Campbell-Pretty: Always like that, Lawrence. All right, folks. It looks like, we have met everybody's needs. Thank you so much, Paul, for taking the time to share the journey. It was really lovely to relive the 2018, 2019, journey, where we were really working with you guys intensely and great to get that full update.

It's a really impressive story. We really appreciated being part of your journey. And then we look forward to, continuing to encounter your team in various events as you continue to grow your SAFe capability. Thank you so much, Paul. Really, really appreciate it.

Paul Gampe: Thank you. Appreciate the time.

Em Campbell-Pretty: Have a good afternoon, everyone. Thank you for joining us.