Agile, DataOps, and Data Team Excellence

00:00:00 Housekeeping, and what data team excellence means

Chris Bergh: Just a few minutes and we'll start.

Chris Bergh: Hello. My name is Christopher. I'll be the host of today's webinar. With me is Gil Benghiat, the founder of DataKitchen. And so our topic today is Agile, DataOps and data team excellence. Gil, if you could go to the next slide.

Chris Bergh: Just a few housekeeping things. So today's slides and the recording will be shared this week. So put your answers in the chat window, which you can find on the lower right hand corner of your screen. There's a little button that looks like a chat window and type them in. We will answer your questions at the end. We may answer them some during it, but we'll generally try to answer it at the end. And we've targeted 50 minutes for this presentation with 10 minutes of questions, and Gil will be going through the slides and I will close out the discussion. So thanks everyone for joining. We really appreciate the opportunity to talk to you.

Gil Benghiat: All right. Hi everybody, and welcome. As Chris said, my name is Gil Benghiat. I'm one of the three founders of DataKitchen. My background has been in software development and also consulting and also a lot of data work. I'm one of the co-authors of the DataOps Cookbook and the DataOps Manifesto, and I'm happy to be here. The goals of this workshop, we could sum them up: it's data team excellence. But what does that mean? It's how you can deliver value to the business quickly and with high quality. It's easy to deliver quickly with low quality, and it's also possible to deliver high quality but do it very slowly. The trick is to do both at the same time.

Gil Benghiat: So in this workshop we'll be covering three main things. First is an analytic landscape and trends, to see what's going on. And then we'll talk about DataOps. Agile is one of the components of DataOps, we'll start with that. We'll look at the mindset, how to get started on Agile if you haven't, then some key practices, and then we'll talk about DataOps and from there some things from DevOps and statistical process control. So as we go through this presentation, take out a piece of paper, open up a notepad and think of things that you could try, try to generate some ideas of what can you try tomorrow from this presentation, and I'll prompt you at different points to do so.

Gil Benghiat: And what is the main benefit of DataOps or data operations? If we look at a data team, it is working on new features, delivering value to their customers. Another is fixing the process, reducing technical debt. And then there's this other area which is shown in blue, is just things that go wrong: errors. There's waste, abandoned tasks, doing things manually. And the overall goal of DataOps is to reduce that so teams can focus on the good things, delivering value.

00:05:00 The analytic landscape: Amazon-speed expectations, and why 50% of analytic projects fail

Gil Benghiat: So first in this we'll look at the analytic landscape. And I think it kind of can be condensed into this conversation I had with one of our customers. He's a senior data leader at a pharmaceutical company in the commercial analytics group, and in a conversation with him he said, I'm competing with Amazon. And I thought that was very strange. It's like, is he shipping boxes from his garage? What does he mean by that? So I asked him, what are you talking about? And he says, Amazon has set new expectations.

Gil Benghiat: They deliver things same day, overnight. People expect it, have new expectations. When they want something they want it soon. And he says, and that's how my customers are. I'm delivering analytics. They ask me a question. They don't want to be put into some queue where I eventually get to it. They want the answer same day, maybe tomorrow. So expectations are high. And if we look at a couple industry trends, this is borne out by some data. If we look at the arc of software development, which also follows the arc of analytics, it started with waterfall, and going back a few years if you delivered once a year that was pretty good, but that's been reduced to months, weeks, and now some companies are delivering every few seconds. And the trend has been from waterfall to Agile to DevOps release frequency.

Gil Benghiat: Another major trend is in manufacturing. The big arc is from handmade to mass production to lean manufacturing, and their quality has gone up. And we really can trace this back to Deming, who went to Japan post World War Two. He arrived in 1950 and he was invited to teach leaders and engineers statistical process control, and this resulted in the Toyota Way, which came back to us as Agile and lean.

Gil Benghiat: And there's a certain irony with analytic projects. They're not done. Analytic projects, they do have a begin date but not a completion date, because once you deliver your models, your charts and your dashboards, business customers think of new questions, and that requires new data sets to be organized, quality checked, new dashboards, and that cycle continues. So really in analytics the idea is how to continuously deliver in a changing environment.

Gil Benghiat: And there's a few more things that's hard. Is when you talk to your business customers and you say, hey, what would you like in a graph? They really don't know. They're not sure what they want. And there are these two kind of amusing laws, that users don't know what they want until it's in production, and then they say, you give them something to react to, they may understand then. And then specifications, no one really reads them. So are they worth doing?

Gil Benghiat: And finally, it's hard work. Gartner did a study and found out that 50% of analytic projects fail. So these are the trends. It's hard, things are getting faster, customers are expecting higher quality delivered quicker, and they don't know what they want, and the projects, it's a coin flip if it's going to work. What to do, what should an analytic team do? And the answer is, so what is Agile? It's a way to improve productivity.

Gil Benghiat: I think of it, it's really not technical. It's a mindset versus a method, and it really boils down to four values and 12 principles. They're documented on the agilemanifesto.org website, and I would boil it all down as focus on delivering value, and there's a little bit of which is collaborate with your customers, respond to progress by working code or working analytics, release frequently. So if you chop it into small pieces, get it in the bank.

00:10:00 Agile in four values and twelve principles, and why to start with Scrum

Gil Benghiat: Get feedback on what you delivered. There's people will look and say, that's not what I want, this is what I want. And then look at your process, reflect on the process you're using to deliver, to become more effective. And the specific technique for that is retrospectives. We'll talk a little bit more about that later on. I also find that some Agile practitioners say that there is a right and wrong way to do Agile. I'd say be pragmatic. If you can adopt a practice that improves what you're doing then it's worthwhile, and every organization is different, and what you adopt first and how you implement it will be dependent on what you're trying to do and your current context.

Gil Benghiat: So on the right are these four principles: individuals and interactions over process and data, working software is the unit of measure, collaborate with your customer, and respond to change. Those are the four values. And then there's also

Gil Benghiat: on the website the 12 principles. I'm not going to go through all these, but I will convey that at one DataOps training at a power company, as we went through the training we wrote down different ideas of what they wanted to try, and it really boiled down to, coincidentally, two of these principles. They said, we're not communicating enough with our end users, we need to work in pairs. That was one takeaway, which is one of the principles. And the other was, it's like, hey, we want to start defining MVP, we want to do less, we want to deliver less initially and get feedback. And those are two takeaways.

Gil Benghiat: So out of these simple four values and 12 principles, I think the whole Agile world kind of exploded, and there's all sorts of methods, all sorts of acronyms, and it's a little overwhelming. So where to start? And what I would recommend is start with Scrum. It's kind of not too small, it's easy to get your head around, and then this one survey shows that about 60% of the teams are using some form of Scrum to get started. There's this guy, the Scrum Guide, it's only 14 pages. And it's a great way to learn Agile principles. It's simple to understand, hard to master.

Gil Benghiat: And I can summarize those 14 pages in this one slide here. Scrum is about teams, it's about a set of meetings, and it's about a set of artifacts. And if we kind of look at it in an order, here's how you could get started. First start with your team, and then divide them into three roles: the developers who do the work, the product owner who's in charge of representing the customer and maximizing value that the team produces, and the Scrum Master who's in charge of identifying and removing impediments. So step one, two, three: form your team, assign three roles.

Gil Benghiat: The next step, four, is to take a list of what you want to do and make stories or tickets, make a list of what you want to achieve. That's the product backlog. Scrum has time increments there. Sometimes they're sprints, sometimes they're called iterations, but you need to pick one, and typically they're a week, sometimes two, sometimes four weeks. But in your sprint you want to say what you want to get done. You have a sprint planning meeting, number five, and you carve off from the backlog the tasks that will deliver the most value in that week. That's your sprint backlog. The next step is to meet every day with a daily scrum, which is sometimes also called a stand-up.

Gil Benghiat: I find it a little confusing that the method is called Scrum and a meeting is called scrum. So in the daily stand-up, you go around the room, it should be a 15 minute meeting, and there's three statements: what I achieved yesterday, what my goal is for today, and are there any impediments. And those impediments should be solved. At the end of the sprint, when the sprint backlog has been implemented, there's a review with the stakeholders, and then finally a retrospective, to look at the process and say, can it be improved? So that's Scrum in one slide, and how to get started in nine easy steps.

00:15:00 Why smaller deliverables win: stories, and limiting work in progress

Gil Benghiat: So one thing about Agile is it's a reaction to waterfall. And the thing about waterfall, if you remember about this month long or even year long cycle, is you would go through all the steps and not deliver to the end, and during that time things happen. Requirements change, the customers change, the technology changes. So you may have to react to those changes before you actually deliver value. And the idea with Agile is you have the sprints or iterations so you can deliver along the way. So let's take a look and see what that means. So in this picture, the benefit of delivering more frequently is learning for the team and value for your customer.

Gil Benghiat: So in this project in waterfall, let's say there's one, two, three and four. You go through all your stages, they're delivered, your customer gets value, and you learn about your process and you learn about how those features are for your customer. With Agile you chop up and divide the work. So let's say in sprint one you deliver feature one, your customer gets the benefit of that feature right away, and you learn about your process. How did this go, can we make improvements? To be realized soon. And also, is there any feedback? Now sprint two, we deliver feature two, and here in sprint three we're going to deliver feature three, and what, four wasn't so useful after all, we'll deliver feature five instead.

Gil Benghiat: Think about your own process and think about your own deliverables. Is there a way you could make them smaller? Ask yourself the question, what's the smallest deliverable I can make to deliver value to my customer? Think about that, and if you have an idea write it down on your notepad.

Gil Benghiat: In the sprint backlog, how are these units of work represented? There's a great practice that Agile has come up with, which is stories. The story is written in this format: as a certain role, I would like a certain result, for this benefit. So an example of that is, as a salesperson, so that's your end customer, I would like to see a list of doctors ranked by number of prescriptions so I can visit the top prescribers and make sure that they're happy. So you want your top customers, you want to know who they are and you want to visit them. And if we look at the story, it talks about the what,

Gil Benghiat: not the how. There is just what needs to be done. So it doesn't say, I would like a new column in a new table. It's really what the results are. It's achievable, it's small, it fits in the sprint, and you could test that this is there.

Gil Benghiat: One other kind of Agile practice, which is attributed to Kanban, but if we really go back is introduced by Toyota, is the idea of limiting work in progress. The benefits are less context switching, and we'll look at that on the next slide. You can really focus on getting a story done, in the bank. There's less chance that you start something and then don't finish it, so there's less waste. And then if something isn't advancing, it makes it easier to identify blockers or bottlenecks in your process. So when you implement this, pick a number for each person or the whole team of how much you want to limit. So maybe everybody can only be working on two tasks at once before they're allowed to put on a third.

Gil Benghiat: I found this study pretty interesting, and it was cited in the two books on the left, and it's how much productivity is lost to context switching. And here we see that if you're working on one task there is no context switching, you're 100% productive. But what this study shows is that with every task you add to somebody's queue they lose about 20% of their productivity due to the context switching. So this is another idea for your notepad. Is there a way you can focus on one thing and then get it in the bank before moving to the next one? Is that a practice that you can adopt tomorrow?

00:20:00 Retrospectives, the top Agile techniques, and turning every task into a ticket

Gil Benghiat: Another great technique from Agile is the retrospective. So it's a meeting, formally, that is held at the end of each iteration. Some do them every other iteration. Some teams do them once a month. But the idea is to look at the process and to say, how can it be improved? This thing at the bottom has a bunch of kind of different ways of running a retrospective, so they're not all the same. It could be as simple as listing: what should we start to do, what should we stop doing, what should we continue to do?

Gil Benghiat: I like the alliteration of this one, for what's lacking, what I learned. Or another is kind of keying off emotions: what makes us happy, what makes us sad, what makes us confused. And the idea is to use these techniques to make a list of impediments or a list of opportunities for improvement. And then the key is to pick one, make sure you can actually pick something, get it implemented, instead of, the goal of let's make one improvement per sprint. And if your sprints are a week and you make one improvement per sprint, that's 50 improvements over a year. You could see how this will compound and make everyone's work life better.

Gil Benghiat: So this group scrum.org did a survey, what are the top Agile techniques employed. We touched on a few of them. There's more. Number one by far is the daily stand-up, and that's a great way to improve communication. Number two, iteration planning, is not too surprising. I think if you're going to have sprints you need to pick what's in there. The next is unit testing, which I think is more of a DevOps task than Agile. But how can you,

Gil Benghiat: that brings up the point of how can teams actually deliver quickly. Back when Agile first came out and the idea was like, you should deliver every month, I thought that's impossible, it takes our QA team six weeks just to run the test manually. And there was the answer: automate the tests, unit testing. And then retrospectives is actually one of the top ones as well.

Gil Benghiat: Another technique that we like to use is turn everything into tickets, put things in the backlog, so everything's a ticket: data features, bugs, user requests. You'll find as a team people email you things, turn those into tickets. What should be a ticket? Every task, if it's bigger than a bread box. So pick a time that works for your team. Let's say if it's more than a half hour, turn it into a ticket. Tell everybody, if it's not a ticket it doesn't exist. There's a lot of ways for doing this. And one New Jersey pharma company that adopted this for their analytic team really

Gil Benghiat: improved their operations. So when they started, not all work was in tickets, they were not working on the most important thing first, they didn't finish what they started. But with things in tickets, all tasks as tickets or stories, they were able to look at the age of the tickets to make sure things weren't abandoned, and in short order their team velocity doubled and they reduced their turnaround from two weeks to two days.

Gil Benghiat: And just the tickets following a classic to do, in progress, done. And then it's also good to flag if they're awaiting response, because that will show where something's blocked and you could help remove that as an impediment. All right, that's the Agile section. Now let's look at DataOps. So just as there's an Agile Manifesto, there's also a DataOps Manifesto, which has some things in common with the Agile Manifesto but also has some characteristics that are unique to data. And there's an action, you could go to this website, read it, there's much more detail there, and if you think it's a good idea, sign the manifesto, just like the Agile Manifesto.

00:25:00 DataOps as Agile plus DevOps plus statistical process control

Gil Benghiat: And if we think about DataOps, it really is the combination of these three ideas. Agile, which we talked about. DevOps, which is about automation, orchestration and automated testing, so it's really about having the technical infrastructure to support Agile, or support Agile analytics. But there's one other aspect here, which is in analytics you're really working on a production system. The data flowing through is raw materials that are assembled, so lean manufacturing techniques apply to your data pipelines much more so than to just plain old software.

Gil Benghiat: So if we look at that, kind of the first way to get started with DataOps is orchestrating these. So one journey is what we call the value pipeline. And you could think of it as your pipelines in production. They take the raw data, do some transformations and deliver value to the customers. The other pipeline to automate is the innovation pipeline, or the CD pipeline, and that's how new features find their way into production.

Gil Benghiat: And what's interesting about these pipelines is what's going on here. So in the production pipeline, or the value pipeline, your code is static while your data changes. And the opposite is true in the innovation pipeline. Here you're working on your code, you're getting new ideas into production, but your data is static. So you want to have tests that you could make sure this is right, from software. You want to have some tests that make sure your code is good before you promote into production. You run them here. And actually what's interesting, often time the tests you have in production can be reused, or they could be the same as your tests in your innovation pipeline.

Gil Benghiat: In production, I see, can we ask the question, put it in the chat and Chris will moderate. So in production, you want to ask these kind of three questions. So just as your data pipeline is really like a manufacturing process, there are these three big questions. As the raw materials come in, are my data free from issues? You transform them, you put them together, there's certain assumptions that you make in the code which match business, you want to have tests for those. And then finally, when there's results, are your outputs as you expect, or is there a join that went haywire and kind of doubled or 10x'd the number of rows it should have? So implement these tests in production as well.

Gil Benghiat: And while it's in production, these tests can throw off information that you can run and create statistical process control charts. So one test could be, let me calculate the percent of invalid ZIP codes in my files coming in and my data coming in, and I'll set a threshold. I want those to be less than 1%, and if they're higher I want to be notified. So this is a classic statistical process control chart, upper bound, lower bounds. It applies to data processes as well.

Gil Benghiat: But what's interesting is that it doesn't just end with these process control charts. Analytic teams should really be measuring and improving all of their work. It's kind of funny sometimes, we're into analytics but we don't apply analytics to our own work. So what you should do is look at your own productivity, your own velocity, age of tickets, data error rates, all sorts of metrics, and look at them and review them. So this is another one: are there some metrics that are readily available that I could start looking at tomorrow and use those to improve my process? So that's another question for your notepad. So let's look at a few more metrics.

00:30:00 Measuring your own work: Pareto charts of production issues, and supplier delivery scores

Gil Benghiat: I think one metric that is very helpful is to just list your production issues. If there's an issue there should be a ticket, it should be flagged or tagged as a production issue. People should look at that and say, okay, what was the root cause? Arrange them in a Pareto chart, which is really a count by issues. So if we look at this chart, why are people late to something?

Gil Benghiat: They're getting there, there was traffic, the weather was bad, they overslept. So this is number of incidents on the Y axis, and the buckets are the root cause, and you rank them high to low, and you say, this one on the left is something that we should work on. And we would advise that you should list your production issues, create a quality circle. There's an idea here of love your errors. There shouldn't be blame. Errors happen. The root cause is actually the process, not the person. So look at them and say, how can we improve the process and improve our operations and the quality of our work life.

Gil Benghiat: And then here's one other metric I'll go over. And it's really a list of sources and delivery time. So across the top we have five data suppliers or five sources, on the left is time, and then they each get a score: did the data arrive on time, was it late, or was it missing. And at a glance you can see that source four is giving some trouble. So that's where I would spend some time and make my operations better so I could deliver my SLAs to my customers.

Gil Benghiat: All right, so that's the material that we wanted to go over. For the most part we looked at some trends, we looked at Agile, which is a great set of practices, DataOps brings in elements from statistical process control, DevOps, the technical infrastructure needed to actually do Agile. I hope you have a list of things to work on and lead to improvements of your team. At DataKitchen we have,

Gil Benghiat: we've delivered this course in more detail and we've gone deeper into things. So we have a DataOps training where we go through the materials, we list actions, it helps to mobilize. We have coaching, consulting, so you can engage with us either on a weekly basis or for a purpose specific project. We have data engineers who can put together an Agile data warehouse. And then we also have assessments where we identify obstacles to remove and opportunities to grow. And I'll just

Gil Benghiat: talk about a finding there. We were working with an insurance company. They chose to do the assessment because the VP of analytics was told by the CEO, your team is too slow. So we talked to people, we assessed processes, and the main finding is that the analytic team was treating every single data item as a corporate asset, as an enterprise asset, applying gold standards and processes to everything. And it turns out that everything in analytics doesn't need that level of treatment. If you're settling a claim you do need to have the dollars and cents right, but if you're doing something that's just directionally correct then you don't need to

Gil Benghiat: have the same level of quality, and you want to advertise it. And then the other problem is, since the team was so slow they would actually try to cram in more features, because they said, if we don't get it in now we'll never get it. So by treating data differently and by making the releases smaller, that team was able to make some improvements. If you have specific questions or would like to contact me, here's my email address, gil at datakitchen.io. And I'll turn it to Chris.

00:35:00 Q&A: does ticketing everything make you an order taker?

Chris Bergh: Yeah, so thanks for attending. So I just want to go through some questions. So I think there was a really good question from one attendee. So his concern was, if you turn everything into a ticket then you just sort of become a service department as opposed to a strategy department. And Gil, how would you answer that?

Gil Benghiat: Yeah, it's true, you don't want to be an order taker. You want to collaborate with your customer and really understand what's important and what to do first. And part of what helps is being transparent and to say, here's what I'm working on, here's my tickets. I think what was interesting is another group that had tickets and everybody was vying for things. What this data leader did is she invited all of her people into the sprint planning, and she actually found that when people saw what she was working on they would say, that's more important than mine, I could wait for a week. So I think that

Gil Benghiat: you just don't want to blindly do things. You want to understand why you're doing them, make sure there's value, have a tight feedback loop. I hope that answers the question.

Chris Bergh: Yeah, that's an excellent question. Also, I think the notion of a ticket is not just coming from your customers. I think if you think about categorizing what your tickets do, they certainly can be tickets on, something broke last week, we have to fix it. So there's error fixing. There could be tickets on things are too slow, or technical debt tickets where you want to improve something. There could be tickets on improving documentation. And so, by saying, and some of those are of course not visible to your customer, right, they may not see technical debt.

Chris Bergh: They may not see tickets that drive productivity improvement. But being able to make that work visible and balance off between all the customer requests they have, all the needs that you have of your data infrastructure, all that you need of governance, all that you have in automation, those things are a way to help engender trust with your sponsors. And if anything, the idea is about being customer focused but not being too customer-focused, not doing everything they want. It's the balance between sort of heroism for your customer and the fear that things are going to break and fall apart, and it's that balance between the two.

Chris Bergh: And so, happy to answer any more questions.

Chris Bergh: Sure, go right ahead. Let's see.

Chris Bergh: If you raise your hand go right ahead and ask a question. Feel free to voice it or type it in.

Attendee: Yeah, can you hear me? Yeah,

Gil Benghiat: There we go.

Attendee: so, I like your infographic that talks about efficiency, or what was it, context switching rate, and the more tasks you assign you lose that 20% steadily. So in an environment where you have DataOps, right, and you've got people that are working on both new requirements as well as people that are sort of addressing ongoing daily problems, and with data they're going to be there. I guess what kind of advice can you give if let's say you've got a finite team and they have three or four of these a day, and that kind of drags you down, right, to the bottom of that graph?

Gil Benghiat: Right, that's right. So I think, so a couple points on that. One is what the answer from Scrum would be: we're going to make a list of tickets, lock it in for the week and let the team just work on the tickets. So you may only interrupt the scrum once a week. I think in reality that never works, because your customers come up with something, it is a service business. So how do you keep the whole team from dragging down? And there's different techniques you could apply. One of them is to say, I'll split the team in half, half the team will be

00:40:00 Q&A: protecting a team from context switching, and the subtle art of saying no

Gil Benghiat: protected and will focus on tasks, and the other part of the team will be interruptible. So that way at least part of your team gets to work without this context switching. And I think another thing to do is to negotiate with your customers and to say, what percent of the team is a good devotion for these interruptions? So that's another technique you might be able to try.

Chris Bergh: Yeah, I like that. But the third is the subtle art of saying no. Right? And so your customer may get used to asking on Friday afternoon for a change and expecting sort of you to work Friday night to get it in, and while that sort of heroism is great and it's very useful and needed sometimes, the idea of just asking, hey, can we get this in next sprint instead of this week's sprint, and being able to say to them, sort of subtly push back, is it possible that we could do this next week instead of this week. And the other part is a trust issue between your business customers and your team. Once you've made that work visible with tickets, once you prioritize the tickets, and once you started to work down

Chris Bergh: your technical debt in terms of test and automation, what you'll find is your team gets more freedom to be able to work, and the context switching is lost because you've done what Gil suggested, you've loved your errors, you started to put automation and testing and deployment and DataOps techniques in to fix those tests. So suddenly your team has more time. And I think all those things, it's not a magic button that you can press, because you are dealing with people and their expectations, but it is about working that relationship with your customers and the team that you're running, so you can get away from constant context switching. And also the other part of context switching is just constant fire drills when things break, and trying to protect your team against that.

Attendee: Yeah, I liked your answer about maybe partitioning the team a little bit, but I guess you have to be careful, because then you're going to split dev and ops, right, at some point.

Gil Benghiat: Yeah, yeah, it's something you could rotate. So who's on kind of support that week? Maybe it's one person, maybe it's half the team. And are you splitting dev and ops? Yeah, you do want your development part, you want to have your development be on this left hand side, so you're getting as much done as you can, and there is a support function as well.

Gil Benghiat: Yeah, there's a question in the chat about, okay, yeah.

Chris Bergh: There's two. Gil, do you want to take one?

Gil Benghiat: Yeah, which one do you want to do first, Chris, or would you like to answer?

Chris Bergh: How about I'll do the AI Ops one.

Chris Bergh: So these marketing terms around machine learning operations, AIOps, DataOps, they have sort of two categorizations. So one is, as an engineer, we've done quite a bit of work to define what DataOps is, which is the application of lean and Agile and DevOps techniques to data and analytics systems. And so likewise this Ops suffix means kind of doing these principles of lean and statistical process control and DevOps and Agile as applied to different domains. So in general MLOps is sort of the application of those principles to machine learning systems. AIOps has a second definition which is sometimes used in DevOps, which is a self healing of systems. And so these terms are related in that they generally refer to different domains.

Gil Benghiat: All right, I'm going to come back to the Scrum Master question. I'll read the question: when initiating and deploying DataOps from scratch, do we follow an Agile methodology? If so, how do we introduce both the DataOps framework and Agile methodology in parallel? So I think when starting it's important to recognize

00:45:00 Q&A: introducing DataOps and Agile together, the Scrum Master role, and Agile for a team of one

Gil Benghiat: sorry about that, folks, went the wrong way. Part of DataOps is that Agile is the mindset, so I would say you do it all at once, and you say what will help the most. So for Agile, it's all about organizing the team, having sprints, reflecting on your work, focus on value.

Gil Benghiat: And that's important. And the DevOps part, or part of what DevOps contributes, is automating. If you have a test, can you automate it? If you do a deployment, can you automate it? If your pipeline's running, can you automate that? And then finally you want to gather data and use the kind of Agile mindset of these process automation measurement points, which one will bring the most value first. So you can employ kind of an Agile mindset to kind of bootstrap DataOps and say, these concepts from this presentation or the concepts from the DataOps Cookbook, what do I want to do first, what will bring the most value, do those. And you might find yourself jumping around between these boxes.

Gil Benghiat: All right.

Chris Bergh: Gil, do you want me to take the next question?

Gil Benghiat: Yeah, I didn't have time to read it.

Chris Bergh: What is the role of a Scrum Master and how does he or she fit in the sprint planning? So in general we think of Scrum as one method to organize a team, and Gil had a chart of all the different methodologies between scaled Agile or Spotify or Scrum. We're not recommending Scrum over another methodology, but there is someone who I think should be in charge of organizing the process and the steps that people do, and making sure what are called the rituals here, your planning, ticketing, reviewing, and also when things go wrong, your retrospectives. And I think that's the role of the Scrum Master. And

Chris Bergh: Gil, do you have anything to add to that?

Gil Benghiat: No, that's good. So I'll answer the next question, which I'll paraphrase as, hey, I'm a one person shop, how do I do Agile? I don't have a team. What's your advice? I would say, don't use a board, use, get right to sticky notes and a wall. I think writing your things down as tickets, kind of go in the old way of sticky notes, or organize them by what's the most value. Try to, once you put something in, to limit your to-do column to just a couple things at once, and kind of force yourself to say, if I start something I'm going to finish it before I move on to the next.

Gil Benghiat: So I think there's more details in what you're doing, but I would say make your own personal Kanban board and use tickets.

Chris Bergh: Gil, should I take the next question? Yeah, so I guess the question is around sign off from a superior and

Gil Benghiat: Sure.

Chris Bergh: an internal check. Yeah.

Chris Bergh: I think that is a difficult issue, especially if your process requires sign off. One of the ideas of the DataOps is shipping things before they are perfect, getting them 70% right and getting feedback. And so in that way, sometimes you need to deliver something in a rough mode that's not perfect in order to get feedback first, and that's not necessarily sign off.

Chris Bergh: But the benefit of that is they have seen something once already. The second benefit is they will tell you if you need to continue or if you may need to do something different. And so it's that idea of trying to force feedback from your customer as soon as possible, and also kind of being nervous, uncomfortable when you don't have things perfect. And that takes a relationship with your business customers, but it also makes the final sign off easier, because they're looking at it and they're saying that they've already seen it once and they don't have to go through it. So hope that answers your question. Gil, I don't know if you've got anything to add.

Gil Benghiat: So I'll admit I was reading ahead to the next question. So the next question asks about, there are two teams, one following Kanban,

00:50:00 Q&A: what the hyperscalers do not give you, and where DataKitchen software fits

Gil Benghiat: the DataOps team, and another sprinting, the data engineering team. Is that ideal for balancing operational and strategic initiatives? I think it's fine for each team to optimize and to figure out what's the best way for them to deliver value for their customers. I think what's hard is if, one of our customers said, we're an Agile team in a waterfall company, and they had kind of difficulties with their interfaces. But I think it just goes back to identify who your customer is, collaborate, and make sure you're working on the most important thing for your customer and for your business.

Chris Bergh: So the question, I'll take this one, Gil.

Gil Benghiat: Yep.

Chris Bergh: These days hyperscalers have their own services and tools to do DataOps. How do you see DataKitchen's tools as different? And so, Gil, if you could go just to talk about our software at the very end of the slides.

Gil Benghiat: Yeah.

Chris Bergh: Just go to the three box diagram. One more, go down. So.

Chris Bergh: So in general things have really improved a lot for AWS and Azure. When we first started talking about DataOps a decade ago we asked questions of what source control is and we'd get one out of 20 people raising their hands. And so there are tools within tools like AWS to do things like source control, to do things like have your Kanban board, manage your tickets. A lot of them have tools to do deployment. And so all those things we think are great and that you should use. And so what is left to do? We talk about these sort of top two boxes. What we do see is people sort of plowing ahead and building all the great tools, including the sort of DevOps tools that are in there,

Chris Bergh: they may go into AWS and use Redshift and Glue, or Snowflake, and they may throw Power BI on top, Tableau, use a data science with some Python, and they build something. And what happens is it runs in production, but they have no idea, as new data is flowing through, if things are correct. They have an unobserved system. And so what we believe, and we built some software to help you make sure that the data and analytics that you've delivered has very low errors, and that if there is a problem

Chris Bergh: in the raw data or the integrated data or your tools acting upon the data, that you find out. And so we've got two data observability tools. One does something that no hyperscaler does, is looks across all the tools and builds an abstraction that we call a data journey. And then the second is, a lot of times data engineers have trouble writing data quality validation tests. They may write a row count, they may not do anything at all, they rely on it looks about right. And so we have an engine that automatically builds data quality validation tests, both for initially looking at data during production or anomaly detection. And so those two tools, there aren't really good analogies in all the cloud providers. So we think our software is complementary, and also as Gil said, we have services to help people on their

Chris Bergh: journey to organizationally change to do DataOps.

Chris Bergh: So I think that's it today. If there's any more questions, we're going to go, if you want to learn more about DataKitchen we have a lot of ideas. So for instance we have a manifesto. We have a 250 page book that we've given almost 30,000 copies away. We actually have a book on cultural transformation on that link.

Chris Bergh: We've got some books on our software and discussions of our software. We also have a three-hour DataOps certification that you can take that's for free. And all these things are devoted to the idea of getting you to deliver small bits of value to your customer, run your systems with less error, and stop banging your head against the wall and making your life awful. Delivering value to your customer. So what we'll do is we'll send out the recording of this meeting and will send out the slides later this week. So thank you all again for attending and we appreciate you joining us.

00:55:00 Close

Gil Benghiat: All right, thanks folks.