00:00:02

Thank you very much for attending this presentation. I really, really appreciate it considering that Midwestern is speaking right next door though. Thank you very much. Um, so today we're going to cover how at T-Mobile we transition. We transitioned HR domain to becoming a more agile, digital and project organization. And I will explain to you, I will walk into, through our journey and I will explain why I decided to choose the HR domain. Actually, the example of HR domain, uh, this story is an exception is a, uh, experience report, uh, uh, based on, uh, uh, representing the divide between the business and technology. And, but I want what I want to say. It's not just that PK Byrd to HR, the learnings and the takeaways are very much applicable to any organization and are very much scalable.

00:00:59

So my name is Sharon Alvarez. Uh, as you know, already I work at T-Mobile. I started in 2017 when I joined, I 2d with HR domain as an agile coach. And today I work with, uh, the head of our agile transformation. So together we are, uh, we've a large team. We are actually scaling DevOps and agile to the enterprise, uh, outside of T-Mobile bile. I'm also a news reporter and, uh, uh, editor with info cube. And in fact, today I just published an interview with Nicole falls green. So I put it on the slack on the general slack of DASA. So please check it out. It's a wonderful interview where she's giving a lot of additional information about the state of DevOps. And I have an interview of a Jean team coming out on November 11. So I'll share that with you as well.

00:01:53

So before, uh, before we jump into the, uh, into, uh, uh, HR domain, I wanted to give you some numbers about T-Mobile. So T-Mobile was founded in 1990 and, uh, today we have, uh, uh, roughly 52,000 employees. So we are growing and, uh, we are, uh, number one, we have been number one in customer satisfaction in JD powers in three years in a row. So it's a huge accomplishment for us. And, uh, in 2019, we were, we are actually number 49 on the fortune 500 list. And we moved up is seven places in just one year. So DC's a huge accomplishment and it tells you, it illustrates the effort that we are putting in our employees experience. So great place to work waiver, um, uh, uh, disruption innovation and disruption is really part of our DNA. And as an example, in 2013, we were first to offer a and carrier.

00:02:55

We've no contract and shortly followed we've, uh, uh, data. So if you don't have T-Mobile talk to me while I before, uh, before we jumped into HR domain, I think it's helpful to look at the, the journey T-Mobile's journey to, uh, uh, agile and to business agility. So in 2012, we had, uh, we saw grass, DevOps, Gratz, grassroots efforts. So we started with our teams spread over T-Mobile and that's important because today, as we scale, we are actually leveraging those unicorns. We are taking all the lessons from those, uh, wonderful teams that have a lot of experience now, and we are leveraging that. And in 2015, a little bit, 2015, we kicked off a faster enterprise agile transformation. So a former transformation, and it was led by technology. And in 2016, we saw a, an initiative led by the business and they were exploring the Spotify model.

00:03:58

So you can see in technology, in business, in his yet initiative. And then, uh, in 2017, we actually iterated on what we were doing and we kicked off, uh, recently, in fact, um, our, what we call our working model. So our new ways of working. So it's one of the largest transformation because it's actually led in partnership with the business. So, and it shows that we are rapidly transitioning to a project organization, and we are partnering very, very closely with the business. So something I want to, uh, uh, illustrator, um, I attend, uh, I entered the, the all hands, the technology all hands, and, uh, they, they did, uh, some, uh, uh, showcase of some of our projects we were releasing. And it was really interesting. I think that's going to make Jean really happy. Uh, it was really interesting to see that the presenters were from the business and technology.

00:04:54

So I, I think that today, when you can work walking an organization and see the business partner, we have technology to do presentation, product demo and product presentation at the all hands. It's a huge accomplishment, right? So HR continues delivery HR domain. We actually were among the first DevOps pilot in 2015, and that's admirable for an HR organization because we are generally the last HR, generally the last to adopt agile. And when they actually do adopt agile, right? So we started towards the end of 2014 and 2015. So why is that? Why did we, uh, you know, hop on the train at that time? So, uh, we, I think, uh, we, we are here to talk about dev ops to share our experience about DevOps, how we scale, but we are also here to talk about how great our companies are, how great our cultures are, right.

00:05:55

And the reason why we do that is because we are all facing the same HR conditions for change the same HR challenges. So we are also here to spot talent. We are here to spot to, uh, attract a great talent, right? And we had a, several, a presentation I did at the conference from one from Dr. Al, uh, Alameda, uh, from Kronos and another one from Dr. Marta from Google. And, um, so HR has been completely, uh, uh, uh, ups and down in the last five to seven years. Uh, and, uh, we, uh, we all have a new expectations for, from work. So we all demand a seamless experience, digital experience at work. Nobody wants to go to work and have manual processes, right? We all want to be productive and we want it to be easy. And then we also want to feel valued. So that's, that's the reality today. So, uh, at T-Mobile we believe that, uh, employees experience is directly linked to customer experiments, and they are more and more research from Gardner that, uh, going in that direction. So two coats, uh, that I, that are really a very good one from John ledger, who is our CFO CEO, listen to your employees, or listen to your customer and do what they tell you.

00:07:26

And, um, we want to give you a reason why you wouldn't want to work anywhere else. And we want to create an environment where, where, uh, where you wouldn't want to work anywhere else. And that's from our CIU. It's something you mentioned this year during an all hands. So HR domain ecosystem, uh, um, um, I would to give you an idea of our school, uh, we support, uh, nine primary capabilities, uh, we've uh, seven, uh, cloud applications. Uh, so we, we, those are, those are those, uh, uh, application, uh, support 125. We super 125,000 users. And we manage over 200 integrations between all these application and other application, uh, within the enterprise, right? So at 90% of those integration, uh, batch jobs, we've no tele Maitri or very little terrier symmetry. So a lot of challenges, and that's the reason why we needed to, uh, digitalize our application.

00:08:32

So we have roughly a 10 dev ops teams to support all of that, because we also support a large program. We also see for the digitalization of our campus, we've a smart campus IOT. So we have teams working on, uh, uh, digitalizing, our campus as well. So a primary goal was to improve on our operational efficiency. So a timely delivery of the data to downstream system, making sure that we are always on that transactions are delivered and to wind HR, our HR continuous delivery journey. So before 2015, it starts in 2015, we are completely on premise. We have one month elite and we release every 12 months, roughly every 12 month. So what I call APSR one is when we start introducing agile and we end DevOps and we introduced a scrum and we were supported by the enterprise. So we, part of, we are part of a large effort and epi is a two.

00:09:35

So 2050 17, 2018, we go a step further and we introduced lean and biz dev ops. And I'll talk about that in greater details. I joined roughly at that time, it could be before, and in 2000, 19 and 20, we are actually focused on the 90% business digitalization. Okay. APS are the one we are doing agile. So, um, we, we, uh, spent about a year, a year and a half, uh, to progressively bring our, uh, uh, DevOps team together. So we brought development, QA ops together to form a true DevOps teams. Uh, then we, uh, um, uh, developed, uh, uh, we, uh, organize a team behind project and capabilities and value streams. And, uh, we pass, we implemented a continuous daily, very pipeline and, uh, establish a partially automated the path to deployment. Uh, so we, uh, did we worked on all of that or roughly in 2017, 16 and 17.

00:10:43

And, uh, we immediately saw great results. Uh, we immediately saw wait reserves. We had, uh, uh, it cross-functional teams, DevOps teams. We release the, we went from 12 monthly cycle to monthly and then bi-weekly and weekly. And, uh, we also established the beginning of a project capability. So we work really closely with our business stakeholders and we moved from aggressively away from BRD, so great, great accomplishments. And, uh, there's a, but, um, we still had, um, uh, misalignment with the business frustrations and, um, we were still facing a friction and, uh, we had, uh, silos, handoffs, misunderstood impediments, um, an invisible impediments so that we had to, uh, uh, fix along the way. So we eat in our views that we actually, uh, uh, worked on, uh, we implemented agile. We rolled out practices without and DevOps without fully understanding the principle behind those are frameworks.

00:11:57

And that's often the case actually. So we it's also became obvious that we didn't have, we put pieces together pieces of a puzzle together, but we didn't have a, uh, a vision and an . And we didn't think about the outcome. And I think what was missing was in fact, the business outcome, we focused on the Avalose, but we didn't focus on the business outcome. Okay. So, um, and I want to pause and look at the, what I call the old transformation or parody. We have seen a lot of organization at the conference, uh, describing episode one episode, two of phase one phase two, step one, step two. And we are all, uh, um, even if we are, uh, seeing great benefit, we also, uh, uh, see that they're still misalignment with the business. So I'm trying to understand what's going on because we are all going to the same motion.

00:12:53

And, uh, I liked the way uh and I put the link to the video is a remarkable video, by the way, I highly encourage you to watch it. He said, we have implemented agile, we have implemented new technology. We have satisfied processes. It's fantastic. Right. So why is the business still healthy and happy? And I want to add, it's not just a business. We often say the business is unhappy. I don't, I it's true there's frustration, but I don't think that technology is happy either. Right. I don't think the dev ops team are happy if the business is unhappy and I've seen it over and over again. I think the dev ops team, they tried, they are happy when they see that the business is happy. So we have to work together to bring the business along. Right. So what's the problem. Uh, I see, uh, several, uh, anti-patterns the first one we focus on in our blows, right?

00:13:53

We start our transformation, we've agile with DevOps, and we rely out complex, uh, uh, frameworks or methodologies. And we started with the technology and agile. And in fact, those transformations are steel driven by, uh, legacy waterfall thinking. And, um, so, and we applied those, uh, uh, drivers, um, across what I call dimension, which can be strategy, structure, people, processes. So that, to me, it looks very much like a PMBOK, you know, like, uh, so, uh, agile doesn't have a PMBOK, but it looks very much like a PMBOK to me and those dimension, by the way, I put the reference, they are extracted from an article from McKinsey published in 2018. So, um, the new transformation or parody. So I looked at, uh, uh, what we can do better. And in this, in this model, uh, in this model, we, we focus on, uh, the business model innovation and value fell.

00:15:01

So we focused on project value business outcome first, and the three cornerstone of this model are, um, what, when and how. So we start with the watt identify valuable outcome for the business, uh, uh, identify how soon, how fast it needs to be delivered. So that's a privatization and the speed and flow. And then look at the, how you gonna give that to the business. So here you can see that first we focused on the what and when vitalization and the enablers comes only at the end. So we looked at the Annapolis only at the end. We didn't put in Ambrose at the beginning, so I didn't want to roll out additional, uh, framework, additional practices onto our teams because they were already agile fatigue. Right. Um, so, and there's some appeared a really important, like, look at the business, many feet we want teams aligned to produce and so on.

00:16:02

And one thing that's really important. It's not 1, 2, 3. It happens in cycle continuously and the business and technology work together inside synchronization. So we met with our business stakeholders, literally every day I call located, even if I'm, uh, on the technology side, I collocated with my business for two, three months to understand what the pain points were and so on. So really important. So back to T-Mobile, we've all have that in mind, we decided to change our approach, um, and bring the business back into DevOps. So by the way, I don't think that DevOps ever intended to exclude the business. I don't think so, but I think that when we try to work with the vendors business, and we tell them, Hey, we're going to do DevOps. I think it's really difficult for them to, you know, understand, okay, what's the benefit. And when we explain to them that it's, we're doing business DevOps, we really helping them get value faster.

00:17:09

It really helps psychologically. Right? So, but I don't think that dev ops ever intended to exclude the business on the contrary, the ultimate goal of DevOps is to deliver value to the business. So epic is our one true north. We wanted to focus. We wanted to foster one leadership team across HR business partner and technology, one project team, and one culture that was really important and focused on delivering value. So I don't have the timer by the way. So I don't know how I'm doing it. Sorry. I'll give, oh yeah. So, uh, number one, value and privatization. So the two first cornerstones, uh, so we, we, we made it a point and, uh, here, I want to, uh, upload our technology, senior managers. They did an amazing job, uh, uh, making sure that they were identifying the value of all our features and user stories in using in a business terminology, using a business lingo, using, uh, uh, business outcomes.

00:18:22

So we identified the value. We tracked it, we measured it. And we communicated on the outcome using business language, not technology language, and that was initiated by our technology, uh, managers, by the way. So we are still working on that. We're doing a lot of work to improve on that. And I'll talk about Tita during the, the last slide. And, uh, we improve on our single portfolio intake and privatization cycle. So having a single HR it portfolio intake allowed us to drive a full transparency. So we had one single intake and it allowed us to drive complete transparency, um, remover, uh, inconsistency, and, um, any, uh, challenges we also introduced. We didn't introduce quarterly, big room planning. We actually had a big room planning, but we perfected, we improved on that practice and what we did between, we don't just do planning during big on planning and then a sprint planning with the teams.

00:19:25

We made sure that we had a continues, uh, uh, checkpoints with the business and continue. So rhythm of business centered around, uh, privatization. So for example, we don't call them like that, but we had, uh, uh, meetings with leadership teams and with the project leadership that we that's are very similar to a project that made us scrum, and we have an executive action team. So the terminology is coming from a scrum at scale, and it's simply leaders are meeting every morning to look at the, uh, delivery impediments, the flow impediments and privatization impediments. So you can see that our leader, she project leaders and technology leaders were constantly together weekly, and they address any impediments to the delivery teams.

00:20:18

So now once we have identified the value, uh, we prioritize the data. We wanted to make sure that we have an efficient pipeline to deliver it and to win. So, but, uh, to, in order to go faster, we need to know how fast we going, right. And oftentimes we don't know that. So we, we did several, uh, exercise or value stream mapping and, and, uh, we mapped out our value flow across the end to end a cycle, a product delivery cycle. And we looked at a few key aspects. So we looked at the people interaction because we have a lot of roles or roles that are overlapping. And because we are also working on a role rash rationalization and world clarity, we wanted to understand where we could optimize the flow actually of our, of our work. So the people interaction, we looked at the tools we use and the interaction with the tools who interact with the tools when and what, and this is typical activity when we do a value stream mapping, by the way.

00:21:27

And we looked at the rhythm of business, the reports and the status we provide, the reason for that is because I really believe that when we transitioned from project to project, we, uh, we have a log we deliver, we produce a lot of status reports, right. Sometimes weekly. And, uh, we work on activities on tasks only because we have to deliver a status report. Right. And so we wanted to make sure we understood what was the purpose of that report and do we need it, or can we not? Can we remove the, that status? So we looked at almost all the data available from rally. We were using rally at that time. And I also looked at, uh, the quarterly big room retrospective of our teams, because it gives you a lot of interesting data about organizational impediments. So, uh, uh, we, we made a few observations and I'm sure you're going to, if you, if you've done value stream mapping and you probably, and if you are transitioning from project to project, you are probably going to be familiar with those, uh, uh, key impediments.

00:22:38

So the first one we saw that we had two, um, microflows, we have, uh, sorry, a flow between in the project design and development cycle. And then we have a micro flow in the project, continuous delivery cycle. So in the first, uh, area, and I don't want to call them phase, right, because we're not doing waterfall. We really trying to becoming agile. So in the first area, that work is more people centered, right? So we are writing reports, we are conducting assessment or doing research and so on. And I don't mean to say it's more creative, more human, because development is also creative, but, uh, the work is uncertain to, uh, the day's teammates are uncertain and the work is actually the daily, very birds are not predictable, right? Whereas in project continuous delivery, we have an automated pipeline and, uh, it's still creative work, but if we have delays, so the web, the delays and time to recovery are more predictable, right?

00:23:42

So that's the first observation. The next one we started, there was a clear handoff between, uh, product development and the diff the DevOps teams. So that's a, a turnip salvation. We made a handoff and that handoff was painful for both groups. Actually, it was painful for the, for, for the product development team and painful for the DevOps teams. So the turnip salvation we made is, uh, we have, uh, two lead time. We have, so we started that. We have two lead times. So we have, uh, one lead time that I called tribal knowledge lead time. And it's the lead time is that it's actually the actual lead time. It's when we deploy to production. But that lead time is not always documented in tools. And that's because when we deploy a feature, we don't always close it into tools. And so there's a lot of steps that happened that are not always consistently documented in the tools, right?

00:24:43

So with all that information in mind, we wanted to weave all the conversation, the data we gathered from registry mapping and the conversation we had with the business, we wanted to make sure we would, uh, help and roll out practices. That what I, what I call a value and first and value and a flow first practices, we wanted to make sure that we were gonna roll out, help them with techniques, patterns, and practices that would be valuable to them. We didn't want to roll out anything that would not solve any of those challenges. So we wanted to target the pinpoints. Right. And, um, so we, I won't go over all of them because are quite a few, uh, practices for menus. There are quite a few, uh, practices, but, uh, I want to touch on two of them. And, uh, the first one is, uh, um, uh, story mapping.

00:25:41

So I introduced story mapping is a great technique to do with your dev ops teams and product teams, because we put everybody in the room. It's very similar to value stream mapping, but we focus actually on breaking down initiatives features, and we develop a pro product backlog, but we don't do it in silo with the project team. Only we do it with the development team. It's a great, great techniques. It was so successful that the business had adopted it for their own work, and they started socializing it within the business as well. So great wizard. And when you do story mapping, you also work on MVP. We introduced personas and held them emphasize and help the technology team emphasize better with their customers, but also the HR business stakeholders and fatalities. We've the needs of the employees. So a second technique I want to talk about, it's not new, it's a swap meeting and it has been a talk.

00:26:36

There has been few talks actually about swarming. So it's interesting because once we identify the most valuable feature, uh, we generally treated the exact same way as we treat other features. Right. The only difference is we put on, we put it on the top of the backlog and the teams work on that feature in the exact same manner, right? There's no difference, but it's the most valuable feature for the business. So don't, we want to deliver, deploy to production as quick as possible so that we can get their feedback. And so we've the team. We wanted to make sure that we were patently instantly thinking. And even if it meant, uh, customizing practices or coming up with new practices, we were constantly thinking about how can we get the features to the business as fast as possible so that we can get their feedback. So we let the rich swarming and, uh, we, which then allowed us to deliver features much faster to the business and a great success as well.

00:27:39

So all of those, uh, techniques actually documented, I did a presentation at the project school, so I won't go over all of them, but I did a presentation at the project school, and there's a video posted on YouTube or really long video of one hour and a half almost. And I wrote an article published on LinkedIn and the references on the slide as well. So great success with all those practices and with the relationship that we built with the business, we saw a great improvement in our relationships. So with the HR business satisfaction, um, the, we saw an improved relationship between the teams and the business. And that's what I wanted. I wanted the team to have an opportunity to work directly with the business, interact with them. That's really important, right? A greater alignment, transparency, and trust. And we did all of that. We did all of that with tons of fun. So, and in the business own world, I think for me, there's nothing more valuable and no pun intended here, more valuable than a recognition from the business. So we received several recognition. And what was interesting to note is the goal that we set to do to bring the teams together, develop a unified culture unify team. We succeeded. So nine months into the work we were doing with them, we received a former recognition and it was a huge achievement for us. Yeah.

00:29:07

Time check your seven over eight over.

00:29:11

Oh, thank you. So a lot of people ask me, uh, how did you do eat? A lot of people came to ask me and what was really interesting. They didn't ask me, Hey, what techniques did you, uh, they pro what practice, how did you do it? And so on what they asked me is how did you build trust and relationship with the business? So everybody was interested in the relationship in the trust and less in the practices. So my answer to them was a hundred percent empathy. And what that means is we are all good people. We are all very much capable of advertising, right. But the thing is, we go back to our desk to our emails or pictures or backlog, and we don't act on empathy. Right. And so it's really important when we have a conversation with the business and they share feedback.

00:29:59

It's really important to partner with them and act on that feedback if we don't have the mean to solve that. And we work with our managers, but it's really important to act on it timely. So a hundred percent empathy. And I liked that quote, it's not what you do. It's how you do it. Well, last week we got change a catalyst and success factors. So I think when we, when we lead a really large transformation like that, it's important to make allies. So we work closely with our leadership team and we, uh, uh, included everybody, the, all the SMEs we could find. And, uh, don't make your transformation, a black box and power your people to move it forward. So we work with a lot of SMEs. We organize a community of practices and so on and to finish some that take away. So, uh, demonstrate value early.

00:30:49

That's really important. Identify, demonstrate value early, uh, apply, uh, lean software development, lean and biz dev ops to a software development and continuously improve continuously, improve, inspect, and adapt, and then embrace complexity and apply systems thinking and holistic agility. So you saw, even if we improved a lot of the areas, we were missing, the big picture. So it's really important to, uh, improve holistically our organization and walk the talk. So you judge how to implement agile. And here I go back to the old paradigm and the new paradigm, the old paradigm we project manage or transformation, but in the new paradigm, we productize their transformation, right? So our transformation becomes a product well. So how, uh, um, I'm going to make a lot of enemies today. I'm looking to automate agile, not agility, right? I think we are spending an outrageous amount of time and hours managing our project backlog, uh, entering a user stories, closing on user stories and so on. So, um, well thank you very much. I'm over time. I thank you very much.