Shaaron A. Alvares

Thank you very much for attending this presentation. I really appreciate it, considering that Mik Kersten is speaking right next door.

Today I am going to cover how, at T-Mobile, we transitioned the HR domain into becoming a more agile, digital, and product organization. I will walk you through our journey and explain why I chose the HR domain as the example. This story is an experience report representing the divide between business and technology, but the learnings and takeaways are not just applicable to HR; they are applicable to any organization and are scalable.

My name is Shaaron Alvares. I work at T-Mobile. I started in 2017 when I joined the HR domain as an agile coach. Today I work with the head of our agile transformation, and together with a large team we are scaling DevOps and agile to the enterprise. Outside T-Mobile, I am also a news reporter and editor with InfoQ. Today I published an interview with Nicole Forsgren, which I put on the DevOps Enterprise Summit Slack, and I have an interview with Gene Kim coming out on November 11.

Before we jump into the HR domain, here are some numbers about T-Mobile. T-Mobile was founded in 1990. Today we have roughly 52,000 employees. We have been number one in customer satisfaction in J.D. Power three years in a row. In 2019 we are number 49 on the Fortune 500 list, and we moved up 37 places in just one year. That illustrates the effort we are putting into employee experience. Innovation and disruption are part of our DNA. In 2013 we were first to offer Un-carrier with no contract, shortly followed by unlimited data.

It is helpful to look at T-Mobile's journey to agile and business agility. In 2012 we saw DevOps grassroots efforts: teams spread across T-Mobile. That is important because today, as we scale, we are leveraging those teams and their lessons. In 2015 we kicked off our first formal enterprise agile transformation, led by technology. In 2016 we saw an initiative led by the business, exploring the Spotify model. In 2017 we iterated again and kicked off what we call our working model, our new ways of working. It is one of our largest transformations because it is led in partnership with the business. It shows that we are rapidly transitioning to a product organization and partnering very closely with the business.

I attended a technology all-hands where there was a showcase of products we were releasing. The presenters were from both business and technology. When you can walk into an organization and see the business partner with technology to do product demos and product presentations at all-hands, it is a huge accomplishment.

The HR continuous delivery domain was among the first DevOps pilots in 2015. That is admirable for an HR organization because HR is generally last to adopt agile, when it adopts agile at all. We started toward the end of 2014 and in 2015.

Why did HR hop on the train at that time? We are here to talk about DevOps and how we scale, but we are also here to talk about how great our companies and cultures are, because we all face the same HR conditions for change and the same HR challenges. We are here to spot talent and attract great talent. HR has been completely turned upside down in the last five to seven years. We all have new expectations from work: a seamless digital experience, no manual processes, productivity, ease, and feeling valued. At T-Mobile, we believe employee experience is directly linked to customer experience, and more Gartner research is pointing in that direction.

John Legere, our CEO, said, "Listen to your employees, listen to your customer, and do what they tell you." Our CIO Cody Sanford said this year during all-hands, "We want to give you a reason why you wouldn't want to work anywhere else, and we want to create an environment where you wouldn't want to work anywhere else."

To give you an idea of the HR domain ecosystem, we support nine primary capabilities with seven cloud applications. Those applications support 125,000 users, and we manage over 200 integrations between these applications and other applications within the enterprise. Ninety percent of those integrations are batch jobs with no telemetry or very little telemetry. Those are a lot of challenges, and they are why we needed to digitalize our applications. We have roughly ten DevOps teams supporting all of that. We also support the digitalization of our campus with smart campus IoT. Our primary goal was to improve operational efficiency: timely delivery of data to downstream systems, always-on transactions, and end-to-end delivery.

The HR continuous delivery journey started before 2015 with an on-premise monolith and a roughly 12-month release cycle. Episode one was when we started introducing agile and DevOps. We introduced Scrum and were supported by the enterprise as part of a large effort. Episode two, in 2017 and 2018, went a step further: we introduced Lean and BizDevOps. In 2019 and 2020, we are focused on 90% business digitalization.

Episode one was "we are doing agile." We spent about a year and a half progressively bringing our DevOps teams together. We brought development, QA, and ops together to form true DevOps teams. We organized teams around products, capabilities, and value streams. We implemented a continuous delivery pipeline and established a partially automated path to deployment. We worked on this roughly in 2016 and 2017, and immediately saw great results. We had IT cross-functional DevOps teams. We went from a 12-month release cycle to monthly, then biweekly, and weekly. We also established the beginning of a product capability. We worked closely with business stakeholders and moved progressively away from BRDs.

But we still had misalignment with the business, frustrations, and friction. We had silos, handoffs, misunderstood impediments, and invisible impediments to fix. It became obvious that we had implemented agile and rolled out practices and DevOps without fully understanding the principles behind those frameworks. It also became obvious that we put pieces of a puzzle together but did not have a vision, an end purpose, or enough thought about outcomes. What was missing was the business outcome. We focused on the enablers, but not on the business outcome.

This is the old transformational paradigm. We see organizations describing episode one, episode two, phase one, phase two, step one, step two. Even when we see benefits, we still see misalignment with the business. Carmen DeArdo said it well: we have implemented agile, implemented new technology, and certified processes, so why is the business still unhappy? I would add that it is not just the business. I do not think technology is happy either if the business is unhappy. DevOps teams thrive when the business is happy, so we have to work together to bring the business along.

The anti-pattern is that we focus on enablers. We start our transformation with agile and DevOps, roll out complex frameworks and methodologies, and start with technology and agile. Those transformations are still driven by legacy waterfall thinking. We apply those drivers across dimensions like strategy, org structure, people, and processes, which looks very much like a PMBOK. Agile does not have a PMBOK, but this looks very much like one.

The new transformational paradigm focuses on business model innovation and value first. It focuses on product value and business outcomes first. The three cornerstones are what, when, and how. Start with the what: identify valuable outcomes for the business. Then identify how soon and how fast it needs to be delivered: prioritization, speed, and flow. Then look at how you are going to give it to the business. The enablers come only at the end. I did not want to roll out additional frameworks and practices to teams that were already agile-fatigued. This is not a one-two-three sequence; it happens continuously, in cycles, with business and technology working together in synchronization. We met with business stakeholders literally every day. Even though I am on the technology side, I co-located with the business for two or three months to understand the pain points.

With that in mind, we decided to change our approach and bring the business back into DevOps. I do not think DevOps ever intended to exclude the business. But when we tell the business, "we are going to do DevOps," it is difficult for them to understand the benefit. When we explain that we are doing BizDevOps and helping them get value faster, it helps psychologically. The ultimate goal of DevOps is to deliver value to the business.

Episode two was one true north. We wanted one leadership team across HR, business partners, and technology; one product team; one culture; and a focus on delivering value.

The first cornerstones were value and prioritization. Our technology senior managers did an amazing job identifying the value of features and user stories in business terminology, using business lingo and business outcomes. We identified value, tracked it, measured it, and communicated outcomes in business language, not technology language. We improved our single portfolio intake and prioritization cycle. A single HR IT portfolio intake drove full transparency, removed inconsistency, and addressed challenges. We did not introduce quarterly big room planning from scratch; we already had it, but improved the practice. We made sure that between big room planning and sprint planning we had continuous checkpoints with the business and a continuous rhythm of business centered around prioritization. We had meetings with leadership and product leadership similar to a product meta-scrum, and an executive action team where leaders met every morning to look at delivery impediments, flow impediments, and prioritization impediments. Product leaders and technology leaders worked together constantly to address impediments to delivery teams.

Once we identified value and prioritized it, we wanted an efficient pipeline to deliver it end to end. But to go faster, we needed to know how fast we were going, and often we did not know that. We did several value stream mapping exercises, mapping value flow across the end-to-end product delivery cycle. We looked at people interactions because many roles overlapped, and we were working on role rationalization and role clarity. We looked at tool interactions: who interacts with which tools, when, and how. We looked at the rhythm of business, reports, and status updates. When transitioning from project to product, we produce many status reports and sometimes do activities only because we must deliver a status report. We wanted to understand the purpose of each report and whether we needed it or could remove it. We looked at almost all the data available from Rally and at the quarterly big room retrospectives, because they provided interesting data about organizational impediments.

We made several observations. First, we saw two flows: a flow in the product design and development cycle and a microflow in the product continuous delivery cycle. In the first area, the work is more people-centered: writing reports, conducting assessments, doing research. The work and estimates are uncertain, and deliverables are not predictable. In product continuous delivery, we have an automated pipeline; it is still creative work, but delays and time to recovery are more predictable. Second, there was a clear handoff between product development and the DevOps teams, painful for both groups. Third, we had two lead times. One was tribal-knowledge lead time, the actual lead time when we deploy to production, but it was not always documented in our tools because features were not always closed in the tools and many steps were not consistently documented.

With that information, the conversations, the value stream mapping data, and the business conversations, we wanted to roll out value-and-flow-first practices. We wanted techniques, patterns, and practices that would be valuable and solve the pain points, not anything that failed to address those challenges.

One practice was story mapping. It is a great technique with DevOps teams and product teams because everybody is in the room. It is similar to value stream mapping, but focuses on breaking down initiatives and features and developing a product backlog. We do not do it in a silo with the product team only; we do it with the development team. It was so successful that the business adopted it for their own work and started socializing it within the business. Story mapping also includes MVPs and personas that help technology teams empathize with customers and HR business stakeholders empathize with employee needs.

A second technique was swarming. Once we identify the most valuable feature, we often treat it the same way as every other feature: we put it at the top of the backlog, but the teams work on it in the same manner. But if it is the most valuable feature for the business, we should want to deploy it to production as quickly as possible so that we can get feedback. With the team, we constantly thought about how to get features to the business as fast as possible, even if it meant customizing practices or coming up with new ones. We leveraged swarming, which allowed us to deliver features much faster to the business.

All of those techniques are documented in a Product School presentation and a LinkedIn article. We saw success with the practices and with the relationship we built with the business. HR business satisfaction improved. The relationship between the teams and the business improved. I wanted the teams to have the opportunity to work directly with the business and interact with them. We gained greater alignment, transparency, and trust, and did it with a lot of fun.

In the business world, there is nothing more valuable than recognition from the business. We received several recognitions. The goal was to bring the teams together and develop a unified culture and unified team, and we succeeded. Nine months into the work, we received formal recognition, which was a huge achievement.

A lot of people asked me, "How did you do it?" What was interesting was that they did not ask which techniques or practices we deployed. They asked how we built trust and relationship with the business. My answer was 100% empathy. We are all capable of empathizing, but then we go back to our desks, emails, pictures, and backlogs, and we do not act on empathy. When we have a conversation with the business and they share feedback, it is important to partner with them and act on that feedback. If we do not have the means to solve it, we work with our managers, but it is important to act on it timely. It is not what you do; it is how you do it.

For change catalysts and success factors, when leading a large transformation it is important to make allies. We worked closely with our leadership team and included all the SMEs we could find. Do not make your transformation a black box. Empower your people to move it forward. We worked with many SMEs and organized communities of practice.

The takeaways are: demonstrate value early; identify and demonstrate value early; apply lean software development, Lean, and BizDevOps to software development; continuously improve, inspect, and adapt; embrace complexity and apply systems thinking and holistic agility; improve the organization holistically; and walk the talk by using agile to implement agile. In the old paradigm, we project-manage the transformation. In the new paradigm, we productize the transformation. The transformation becomes a product.

Finally, I am looking to automate agile, not agility. We spend an outrageous amount of time managing product backlogs, entering user stories, closing user stories, and so on. Thank you very much.