00:00:07

Hi, my name is Kira Barkley. I'm the director of analytics at John Deere financial, very excited to be with you to hear today, virtually at the DevOps enterprise summit, London, appreciate the opportunity. And I'm really excited for this talk today. We're going to share with you some lessons that I've learned at John Deere, as we've begun to operationalize analytics, as many of you have experienced there's significant change that's required both behaviorally and technically. However, we've also found that our core values and strengths have enhanced our ability to bring analytics to life in our business. Let's start this talk under the premise of a great divide, a divide between innovative and hip analytics leaders and the profitable and efficient leaders of our core it and product development processes. The leaders that have, has allowed us to be profitable and efficient to date. For those of you who may not be familiar with John Deere, we are a 180 year old company headquartered in Moline, Illinois, United States.

00:01:22

Since our founding, our focus has been delivering products and services linked to the land. We entered the tractor business in 1918 and today our portfolio includes equipment and services for agriculture construction, lawn and golf applications. Our revenue in 2017 was near $30 billion. And we have facilities in more than 30 countries around the world, sell products in over a hundred countries and have about 61,000 employees globally. Using the most advanced methods and technologies to solve problems has always been part of our culture. Well, I personally wasn't around when this particular picture was captured. It is illustrative of the continual manufacturing efficiencies that we've employed today, though. Our products and factory floors look a whole lot different. We use analytics at our factories to minimize scrap rates and identify quality defects faster. We incorporate machine learning into our sales and marketing plans and even embed AI into our products, creating smarter machines and enabling farmers to make better decisions, but getting to a spot where we can operationalize these advanced analytics into our core processes and business decisions has required some change in the way that we've traditionally approached solution development.

00:02:47

But if there's one thing we know well at John Deere its process, after all, we're 180 year old manufacturing company, and wouldn't, you know, it, we have an analytics process. We run really fast in four to six weeks, sprints building out proof of concepts and running pilots and incorporating customer feedback at every step with digital or analytics solutions, external customers may not fully understand how they want insights to be delivered. And that continual feedback loop allows us to adapt and improve the solution. But from the perspective of my colleagues in manufacturing, that sounds really fast paced, downright, terrifying and way out in left field. Our traditional development processes have been pretty linear where we collect and research customer requirements and then work between marketing and technical teams to design a product or a solution. It may truly seem like we're miles apart here and reconciling this is just hopeless, but the good news is we at John Deere are accustomed to following process.

00:03:57

And if we can fall back on that common understanding, we now have a starting point from which to adapt a common understanding of our starting point was critical to forward progress. Once we understood that processes needed to be amended touch points between the business and technical teams needed some conversation, how do we engage? When do we talk? So when do we talk in the product development process? There's a time for that one time. There's one handoff. And that handoff occurs between product design and manufacturing, a blueprint for the product that informs factory design or in digital terms. It's a roadmap that informs tech stack and architecture. So as you can imagine, the first question to the data and analytics team is at what point in this process do I get my blueprint? So imagine the dismay, when I respond, there is no blueprint. We need to deliver value.

00:05:01

One use case at a time minds are literally blown, but to their credit, the initial response was okay, then I need to build a robust and foundational dataset and staff up on advanced capabilities. We need to be sure that we can get your solutions to the market as soon as possible. So then imagine their disappointment. When I respond, that's kind of a terrible idea. We fail 75% of the time, particularly in these early proof of concept stages. And now everyone is like really puzzled. So where exactly does this leave us? We're learning as we go that transparency through projects is absolutely key. This allows innovation and delivery teams to keep focus on respective areas of specialization and simultaneously have runway when new foundational services or skills are needed. Each new use case is also helping us to better design a flexible and modular architecture. Our delivery teams need visibility to our proof of concepts.

00:06:11

They need involvements in the pilots to truly nail the delivery. The key here is to remain transparent and build tools and capabilities over time. So now let's talk flexibility. So here's an example for you. We recently delivered a sales lead generation tool to our John Deere dealers. And then we were ready to move on to our next project. Now we're working on a geospatial tool that delivers biomass projections throughout a customer's cornfield, as excited as us analytics folks are about this. Believe it or not, we got a not very warm and fuzzy response from this amazing news. It might be something like, oh my gosh, I just built the architecture to deliver sales leads. There's nothing geospatial about it. I don't have any data engineers who have worked with geospatial data before there's new data, there's new tooling, there's different architecture. And this just feels seriously insurmountable as an analytics lead.

00:07:16

I'm thinking my data scientist just played around for a few days and they figured it out. It can't possibly be that hard. We learned that not only is it critical to upskill and build capabilities within data science, we need to do the same thing with our engineering teams to stay current with technology. Maintaining communication is critical to support continuous innovation and skill advancement. While we've had a fair amount of change in our development processes and engagement models. We've also found that our core strengths and values continue to serve us. Well. One example of this is how we think about safety in digital terms and that's data governance and security. And let me tell you, everyone is aligned on following the rules, keeping our customers' data secure is a top priority for us. Our production teams develop secure environments. They set strict permissions. They aggregate and anonymize all data and they run all use cases through our data governance and it council.

00:08:26

Well, I'm super duper motivated to stay out of jail. For obvious reasons. Part of me is pretty concerned about this. Will this allow us to be flexible? Will it allow us to be fast? It just feels like a huge roadblock in the making. The good news is it doesn't have to be what I'm showing you on. This slide is published on our public website. It's clear, it's concise, and it's easy to understand. It was developed by a room full of attorneys, rather by a team of business legal and technical professionals. All of these perspectives need a seat at the table to build policies and make decisions. This partnership keeps us moving quickly, but in a safe way. So John Deere has been known for our efficient and effective core operations, and we are able to maintain this mindset and build on the strengths in our digital endeavors.

00:09:28

So what exactly does this mean in a digital environment? So imagine this conversation. So I start by making a joke about how totally efficient it is. Probably not my best move. And I get a response, something like we have cost targets and performance targets to hit with this deployment and to do so. We're going to have to make some tweaks to your models. Maybe prune them, make them more performance. We might even have to hire our own data scientists to adapt to the models, to perform my immediate reaction to this is something really defensive, like do not compromise the data science. We wouldn't let our factory operations crews change the design of attractor just to speed up the operations. Honestly, we've been able to leverage the cultural drive for efficiency, for developing efficient solutions. We're finding that, doing that at scale requires iteration between the business and the it teams to absolutely ensure that the design isn't compromised.

00:10:30

We've also realized solutions at scale may leverage a different tech stack and may have new capabilities and needed to support them. Additionally, we've identified and are beginning to define roles, which specialized in that design handoff. We call this a computational data scientist. These are often folks with computer science backgrounds that have grown statistical or data science skills and iterate with the data scientists who developed the initial model. One of the famous quotes from our founder, John Deere was I will never put my name on a product that doesn't have in it. The best that is in me, quality remains a paramount value at John Deere. I've made it pretty clear to my counterparts at this point in delivery that I super value speed. I was slightly shocked to be honest, when one of those colleagues asked me, well, how much does quality matter? Well, of course quality matters were John Deere.

00:11:35

One of the ways we maintain quality in our iron products are the clear specifications that we have for the components that go into the products for analytics. I think of these raw materials and components as the data, everyone is pretty excited about the potential value of analytics in our business. And they certainly have bought into the hype of the technology, AI ML, et cetera, but we find it's often difficult to get buy in for the time and investment in the foundational data. As simple as it might sound using the manufacturing analogy has been really helpful for us in communicating the importance of data. We've also realized that as analytics teams, it's super exciting to develop the proof of concept and the pilots, but it's also equally important to provide our it colleagues with the data and model parameters that allow us to maintain this quality.

00:12:38

It's a partnership and it shouldn't be left to the delivery teams to have to guess. And also let's be real to get the investment that we need in data. We always have to tie it directly to the value produced with each deployment. So we could think of long established processes as a hindrance to innovation, but we've found that these processes can actually give us an edge when we leverage them correctly. For analytics, significant transformation is required in process engagement and flexibility, but our core values at John Deere of integrity, innovation and quality remain absolutely foundational and critical to our success as a technology company. Thank you so much to the dev ops community for your time today. And I really look forward to answering your questions. Thank you.