 Hello and welcome, my name is Shannon Kemp and I'm the Chief Digital Manager of Data Diversity. We'd like to thank you for joining the current installment of the Monthly Data Diversity Webinar Series, Real World Data Governance, with Bob Seiner. Today Bob will discuss applied data governance to agile efforts. Just a couple of points to get us started due to the large number of people that attend these sessions. You will be muted during the webinar. If you'd like to chat with us or with each other, we certainly encourage you to do so. Just click the chat icon in the upper right-hand corner for that feature. For questions, you'll be collecting them by the Q&A in the bottom right-hand corner of your screen. Or if you'd like to tweet, we encourage you to share how it's your questions by Twitter using hashtag RWDG. As always, we will send a follow-up email within two business days containing links to the slides, the recording of the session, and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Bob Seiner. Bob is the President and Principal of KIK Consulting and Educational Services and the publisher of the data administration newsletter, TDAN.com. Bob has been a recipient of the Dama Professional Award for significant and demonstrable contributions to the data management industry. Bob specializes in non-invasive data governance, data stewardship, and metadata management solutions. And with that, I will turn the webinar over to Bob to get us started. Hello and welcome. Hello, Shannon. Hello, everybody. Thank you for taking time out of your busy schedule to attend this month's installment of Real World Data Governance. And as Shannon said, we're going to be talking about applying data governance to agile efforts today. So it's good to have you with us. Before I get started, I just want to run through a couple of quick current events, a couple of things that are coming up and share a little bit of information with you. As you know, the Real World Data Governance series takes place on the Thursday of every month at 2 p.m. Eastern Time. Next month, we'll be talking about governing data governance metadata and governing master data metadata as part of the series. I'm looking forward to having you there next month. Also, you know where you can find information about the book Non-Invasive Data Governance. I talk a lot about non-invasive data governance. Also wanted to share with you a couple of events that I'll be speaking at. They're Dataversity Events. And one is coming up in April. That's in Atlanta. And that's the Enterprise Data World event, 2017. I hope to see you there. Also the Data Governance and Information Quality Conference 2017 in San Diego in June. I'll be giving a couple of presentations at that event as well. And if you are not aware, March is Education Month at Dataversity, so I wanted to direct you to the Dataversity Training Center where there are seven online courses on Non-Invasive Data Governance. And if you use a special code, TDMEDU, you can get 25% off your single order, off of a complete order at Dataversity Training Center. Last but not least, just to mention to you the Data Administration newsletter, if you're not familiar with it, it's an online publication that is in its 20th year. And new content is published on the first and third Wednesdays of every month. So a new batch of content was released yesterday. So I hope you'll stop by and take a look at those resources. This webinar, we're going to be talking about applying Data Governance to Agile efforts. And as most of us who are involved in Data Governance efforts or involved in Agile development efforts know that the two programs or Data Governance programs and Agile projects tend to conflict with each other when it comes to how the data and how the information is managed as part of those projects. And oftentimes now an organization's senior leadership has come to expect that we're doing both, that we're doing formal governance of data and that projects are being delivered quickly and effectively. And oftentimes those two paths, the making certain that the data is correct and well documented and the delivery, the quick delivery and the quick effective delivery of software, oftentimes they cause problems when you're trying to do data management and data governance along with an Agile effort. Things that we're going to talk about today are we're going to look for a common ground between Agile project management and data governance as a discipline. We're going to talk about the data goals of an Agile effort. We're going to talk about the Agile goals of a data governance program. We'll spend a little bit of time talking about bridging the gap and building people's understanding as to how the two disciplines can and do work effectively in some organizations. And last I'm going to talk about the steps to apply governance to Agile efforts. And I've come up with a new template that I use to kind of detail and outline in each of the steps of an Agile effort. What are some of the things that we can govern? What are some of the things that we can have some type of an impact on either from a data management perspective or just from a governance of an overall Agile software development effort? I always start out by providing definitions that I use for data governance and data stewardship and it's extremely important, especially in this webinar, to talk about the definition of data governance. So when we talk about data governance, the definition that I use is that it's the execution and enforcement of authority over the management of data and data-related resources. And the truth is that as we're putting these types of projects together, we want to make sure that as we're trying to apply governance to an Agile effort, that we assure that the things that are put in place to make certain that the data is accurate and timely, that there's some level of assurance and that we as data governance practitioners focus in on not overwhelming the Agile project teams with requirements and things that we need from a data perspective, we really need to steer clear and allow them to deliver their efforts in the way that they want to deliver their efforts. But the fact is there's certain things around data management that we need to address and we need to make certain that we execute and enforce authority over how the data that's associated with the Agile efforts, how that is managed. The definition that I use for data stewardship is that it's a formalization of accountability and this definition really goes hand in hand with the definition that I use for what I call non-invasive data governance, which is the practice of applying that formal accountability and behavior through non-invasive roles and responsibilities and in non-invasive data governance, we focus on applying governance to process. So in the example of a process that would be an Agile software development delivery effort, we want to make sure that we're applying the appropriate level of data governance to the process as they've defined it for the Agile delivery effort. The idea of non-invasive data governance, like it is with any form of data governance, is to assure that the definition production and usage of data assures regulatory compliance, security, all those things that we're looking for out of our data governance programs. So when I talk about non-invasive data governance, I'm really talking about how we're applying governance to the organization, how we're applying governance to the Agile efforts. And we know that most of our organizations, at least if our organizations are sizeable, that we're taking on Agile project methodology as a way to be able to deliver projects quicker and more effectively. So let's define also what we mean by Agile. So basically, in simple terms, when people think of the term Agile, it thinks of being able to change on a dime, being able to change things quickly and easily, and typically when they use the term Agile to describe a project management methodology, they're typically talking about the process that takes place to deliver some type of software asset to the organization, whether it's an ERP package or a redelivery of a data warehouse or an MDM initiative, organizations that are taking Agile approaches, they certainly follow a certain type of repeatable method for delivering successful projects. So what are some of the key characteristics of the Agile approach? Well, typically their short work phases, their frequent reassessment of work efforts, there's the adaptation of the plans as we're working through the effort of delivering the software to our organization. So what you're seeing on the screen in front of you now is a fairly typical approach to delivering software in an Agile method. So typically it starts with development of the functionality, they test the functionality and then they go back and develop some more functionality. They integrate that functionality and then they test it again and they repeat this until they get to a certain point where they're demonstrating a release of the software. And oftentimes during the release of the software there's feedback and there's changes that take place and what they do is they repeat again, they go back up to the top and they work on the functionality and they integrate and they test and then they demonstrate the release again. So there's a lot of iterative and repeat in the process of being Agile. And the idea is to be quick and to be effective in how we're delivering data assets and delivering software assets to the organization. So Agile, as you can see with the words repeat being highlighted in bright red, you can see that it's an iterative effort. You go from the top to the bottom but you oftentimes go back to the top and you're constantly in a condition where you're delivering new software and testing that software and delivering it to people. And that's really what an Agile effort is. And most people when they talk about Agile efforts they talk about it in comparison to the waterfall approach, which is again another project management methodology which is basically characterized by sequential stages and a fixed plan. It's like water rolling, water pouring downstream. The water never goes back upstream, we're moving forward. And typically people think of waterfall approach as being slow and being deliberate. And oftentimes the term that I hear used often with the waterfall approach is, well, you can pay me now or you can pay me later. And in the approach we want to make sure that we define all of our requirements up front before we start to design and to deliver what it is we're delivering. And in this situation we'd be delivering software similarly if we're comparing it to an Agile effort. So we can either take all the time up front to develop the requirements and develop the design or we can do that in stages, which is what they suggest in the Agile approach to delivering software. So when we look at the waterfall approach, yeah, I was looking for a graphic that I could include on the screen that could basically pour a cup of water down the top of that staircase on the right-hand side of the screen where we're basically following an approach where we analyze the business requirements and the needs of the organization. We're designing the business requirements. We're coding the implementation. But you don't see the word repeat in the process. Very rarely do we go back and redefine our requirements unless it's absolutely necessary. So typically those organizations that are following the waterfall methodology spend a lot of time up front with steps one and two before they even get into step three because they want to make sure that they understand what's going to need to be integrated with what and what the design requirements are for the piece of software that's being delivered. So basically when it comes to applying data governance to Agile effort, it basically boils down to two things. And since we can see that the approaches are very different, one is very structured and very linear in its approach while the other is completely iterative and going back and redesigning and redeveloping. Well, one of the things that we know and one of the things that I've experienced from working with organizations that are developing Agile efforts is that in order to get data governance involved with the Agile development team, we need to convince the Agile development team that there's a sufficient level of data governance that's necessary for their project. And oftentimes, and I've joked about this before where typically in an organization, in the lunch room, you don't see the Agile development people sitting with the data people because they're looking at things from a very different perspective. So oftentimes in order to convince the Agile development team that sufficient governance is required for their project, it may require some level of mandate, something from above, something from your leadership or senior management that says that we need to also pay very close attention to the quality of the data in the Agile delivery effort. And the second thing that it boils down to is we need to find a way to limit what it is that we as a data governance team are requesting from the Agile development team. So we really need to find a way to apply data governance sufficiently without bogging them down with so much detail, with so much documentation that's going to interfere with their project schedule. So in order to do that, it's certainly going to require some level of compromise between the data people and the Agile people within your organization. So when we start by looking for some level of common ground between Agile efforts and data governance efforts, and we've got to look at the things that are common between these approaches. And so that's typically how we do things, to pull things together that are so different from each other. We begin by looking at what they have in common and we focus on strengthening that and then repeating that process. So in order to do that, what I wanted to do is I wanted to share with you basically, and I've shared these before, the core principles of data governance. And the four core principles in most organizations, in fact, many organizations that have developed data governance policy have used these core principles as the basis to their policy. And the first one is that data must be managed as an asset and that there's clearly defined accountability for the management of data across the organization. The no-brainer of it all is that we know we need to follow internal rules and external rules associated with the data. And with data governance, typically we're trying to be consistent across the life cycle. So if we look at those first three bullet points that are highlighted in red, I would say that the Agile development teams are looking at their initiatives and they're not necessarily focusing on managing data as an asset. They have clearly defined accountability, but the accountability might not be associated with the definition, the production, and the usage of data. Certainly one of the things that Agile efforts and data governance efforts have in common is that they need to follow the internal and external rules. Just because we're following an Agile development methodology to deliver software, it doesn't relieve us of the responsibility of following the rules that are being set internally within the organization and externally through regulatory and compliance and privacy and security type rules. So we want to look at the core principles. We want to highlight the ones that we think that the Agile folks don't have a problem with. They certainly want to manage data well. They certainly have levels of accountability that need to be formalized, and they certainly have to follow the internal and external rules that are associated with the data that sparks up their effort. The first thing we want to do is we want to focus on this from an Agile perspective as well and look at some of the core principles of the Agile approach, and that is that we want to define requirements at a high level. So one of the things that I'm suggesting is that we as data governance practitioners need to help them to get to the appropriate level of requirements. Even though it's requirements at a high level, we want to make sure that requirements are well documented and recorded. Another core principle of the Agile approach is testing early and often. As you saw in the flow that I provided earlier, where there's a lot of repeat, we're going to develop, we're going to integrate, we're going to test, we're going to develop some more, integrate, test, we're going to release, get feedback and then go back up and start developing again. So typically there's an active, there's testing early and often, but there's active user participation. And one of the things that puts data governance and Agile together or brings them together, things that are common ground, are that we're both looking for active participation of the user community. A couple of the other Agile core principles are the timing and you want to be quick and you want to be incremental and we want to be very visual in what we're presenting to people, especially during those release stages of our Agile delivery efforts. So we want to make sure that we look for the common ground, but one of the things that I mentioned earlier, is that we've got to help our senior leadership to understand where governance fits in. And boy, we know that we have a lot of trouble sometimes with that in organizations and getting started. But we want to get them to understand Agile too. In fact, I think a lot more senior leadership tends to understand Agile than they do, than they understand data governance. So basically, what does senior leadership want from data governance? Well, they want three things basically. They want understood data. They want the data to be clearly defined so that people can use it and share it across the organization. So they want truly understood data. They want quality data and they want data that's protected and data that is going to add value to the organization through analysis. So oftentimes in these webinars, I talk about data definition, data production, and data usage. Well, what is senior leadership looking for out of data governance? They're looking for governed data definition. They're looking for governed data production. They're looking for governed data usage as well. So what does senior leadership want from Agile? And that's a picture of my friend Mr. McFeely from Mr. Rogers. He was known for saying one thing over and over again in delivering Mr. Rogers' mail, speedy delivery. That's what our senior leadership wants from our Agile efforts. They want incremental delivery. They want high quality delivery. But this is typically with senior leadership. This is why it's easier for us to convince our senior leadership that we want to deliver projects in an agile way. They want quick, they want incremental, and they want high quality. But the problem that we have is that when we're focusing on data governance, oftentimes the data governance team is asking for things that are going to slow down the delivery process. So let's talk a little bit more about that in a couple minutes here. So what does senior leadership think about data governance? Well, there's a lot of different reasons why senior leadership and organizations are implementing data governance programs. And so oftentimes you hear the term data must be managed as an asset repeated over and over again. Well the fact is that those organizations where the senior leadership are implementing data governance, they look at data as an asset in the organization. They realize that the data has to be protected. And that the data drives the analytics and the decision making so it must be high quality. You know, oftentimes in organizations, senior leadership think that they need to implement data governance because the auditors are telling them that they must have a formal level of data governance. And another reason why senior leadership oftentimes are thinking about or are implementing governance programs is because they see their competition. They read about their competition who are governing their data and getting a higher level of value out of the data than they perceive that they're getting out of the data in their organization. So if we're gonna think about why senior leadership are implementing data governance, let's think about why they're not implementing data governance as well. So typically senior leadership, as I mentioned before, it's a more difficult sell to put a data governance program into place because they don't necessarily understand what are all the different approaches that are available to them when they're implementing a governance program. They view it as being very complex and it's based on the size of the organization but it's gonna be very difficult and it's gonna be very painful to our organization to all of a sudden have governance around data. Again, this is what I'm telling you is a reason why senior leadership are not implementing governance because they think it's gonna be complex. They think it's gonna move slowly. They think it's gonna be quite expensive. It's gonna require resources, change the culture. And you know what? Senior leadership are more used to implementing projects which have a beginning, a middle, and an end. They're not used to implementing programs that basically go on forever. You know, I've joked about it before where if your data governance is a game, you've won the game when you get to the point where data governance is something that's secondary in thought to your organization. So we talk about what does data governance, what does senior leadership think about governance? Now let's talk about what senior leadership thinks about agile development efforts. And what are some of the reasons why organizations are taking the agile development approach to implementing large software projects, large transformation projects, rewrites of the data warehouse as I mentioned before. So oftentimes the reasons why they're implementing agile efforts is because those large projects forever have been taking too long and they've been costing way too much money. They're also saying that projects must be managed to deliver quickly and accurately the end products of the delivery efforts. You know, these are the reasons again why organizations are, or senior leadership is saying that we need to implement agile when it comes to our large projects. So the project must be delivered early and continuously the project communications should typically be face to face and constant. They want high quality and timely delivery of their efforts. And think about it from a senior leadership perspective. I mean who wouldn't want these things? They want things to be delivered. They want things to be of high quality but they don't necessarily take into consideration or they don't, senior leadership doesn't necessarily know that the agile development teams that data is almost an afterthought or that it's not as much of a concern as it is to the more waterfall method of developing these types of efforts. So what does senior leadership think about? This should say about agile. The reason why they're not implementing agile, well the truth is they are. They're implementing agile and typically the projects in the organizations that have the agile development methodology associated with them are not the small projects or not the smaller, less resource intensive projects. The agile projects all tend to be the ERP implementations, the ERP transformations, somebody who's gonna redo the design of their data warehouse or develop a new data warehouse or if an organization is going through any type of transformation, a sales transformation, a supply chain transformation, the organizations that are going through those types of efforts and that are implementing pieces of software to support those types of efforts, those are the types of efforts that typically the agile delivery methodology is associated with. And think about it, that makes sense. These are the larger, most important projects that we encompass within our organization and we want them to be delivered quickly we want them to be delivered efficiently and effectively but at the same time, we want them to be delivered with high quality data that's gonna add value to the organization. So if we're gonna take the steps to bridge the gap and build some level of understanding with our senior leadership, we wanna be able to answer these questions. We wanna be able to address these questions within our organization. So the first question that I have on the screen is what does senior leadership know about relating data governance to agile efforts? And from my experience and the organizations that I've worked with, they have a very difficult time articulating governance. They can articulate agile but they don't necessarily understand the relationship between governing data in an agile effort and how difficult that might be. So what I suggest is if your data governance team is looking to get involved in agile efforts, then there's a tool that I'm providing at the end of this webinar that's gonna help you with ways to be able to show where data governance can be applied to agile efforts. But we need to help senior leadership to understand where these two different disciplines are at odds and the steps that we may need to take as an organization to bring them closer together. In most organizations, very little effort has already been given has been taken basically to relate data governance to agile efforts. So if your organization is different, I'd love to hear from you about that. And here, what steps did you take as an organization to bring closer together your agile and your data governance efforts? But in most organizations, there's been very little effort that's been made to bring data governance into alignment with agile or bring agile into alignment with data governance. Like I said, there's been very little effort so far in a lot of organizations to align data governance in the agile efforts. So how well, and this is a question for us as data governance practitioners, how well are our data governance programs acting agile? Are we looking at, in fact, I've heard it repeated in numerous different venues that people who are involved in the data or in the agile development efforts think that the data governance people are requesting 18 pages of documentation per every data element that's going into their system? Well, that's a little bit of an exaggeration. But a lot of the agile efforts think that data governance is going to slow them down. So what can we do as data practitioners to make certain that what we're asking of the agile teams to document the data, to document the rules associated with the data, that we limit that, and we only ask for those specific things that we need in our organization? So really, to bridge the gap between the two, we need to understand how data governance is different from agile. We need to understand how data governance can be applied to agile efforts. So data governance basically is a sustained program. It's funny, I had a chief information officer of an organization recently ask me how many stewards were we going to need and how long were we going to need them for? Well, I didn't laugh directly at him when he asked the question, but I certainly was chuckling inside. The fact is, what I wanted to do was go back to him with the question, well, how long do you want to have quality data? Well, if we always want to have quality data, then data governance is something that's going to be in place forever. And as I said before, we joke about data governance as a game. We've won the game basically when it's become built into what we do as an organization, even when it comes to delivering agile software efforts. So there's a beginning, but there's no end. And data governance, typically, as I mentioned before, those three things that we're focusing on is the definition, the production, and the usage of the data. And I've challenged people before to come up with a fourth. I mean, typically, everything falls under one of those categories. If we can govern the definition of the data and improve our metadata and our business glossaries, if we can improve how the people who produce data in the organization understand that how they produce data has an impact on the rest of the organization, and that's certainly something that data governance is striving for. Also, data governance and data usage, that's one of the things that many organizations are focusing their data governance efforts on right now is protecting sensitive data or using data so that we can improve our analytical capabilities. So in a data governance effort, we have a direct sustained program that focuses on delivering quality data to the organization. However, Agile, it's more of a project methodology. Typically, there's a beginning, there's milestones, and then it's completed. There's beginning milestones, you may go back to the beginning, there's iterative focus, as I mentioned before, but there's a beginning, there's milestones, and there's completion. So Agile is certainly a project methodology, very different than a sustainable program that we would want to have in place for the long run within the organization. The software definition, production, and usage, we're focusing on those where data governance is focusing on the data definition, production, and usage, and the focus of the Agile effort is to deliver quality software and quality software projects to our organization. So the data goals of an Agile effort are to provide these things. We want to be able to provide accurate data, timely data, dependable, consistent, understood data from the project, but what we need to do from a data perspective is do everything that we can to not interfere with their project schedules. So there's data goals of an Agile effort, they certainly want accurate data, they certainly want timely data, dependable, consistent, understood data, but they don't want, let's put an X down here, we don't want the data people to interfere with the project methodology, with the project schedule and plan and resources that we have assigned. This typically an Agile project is very tightly managed. So what are some of the Agile goals of the data governance program? Well, the Agile goals of a governance program is to do things quickly, efficiently, and effectively to provide the right data at the right time using the right resources and sources, for the right purposes. I've talked often about the Data Governance Bill of Rights, and it's not a rights of the people, it's the right thing to do within the organization. Agile, they want to provide the right data, there's nothing in the Agile approach that says that they don't. They want to do it at the right time with the right sources and the right purposes, they want to do it quickly, efficiently, and effectively, but they want to do it without interfering with the project schedule. So we need to look at it from both perspectives as we're developing our method in our organization to apply a data governance to the Agile efforts in the organization. So let's spend a little bit of time, or the balance of the time that we have in the webinar, to talk about the steps to apply governance to the Agile efforts. Before we get started in talking about what those steps are to apply data governance to Agile efforts, let's talk about two key words that I want you to keep in mind. And they're highlighted in red on this screen, and you'll see that they're highlighted in red on some of the other screens as well. And those two words are assurance and appropriateness. And when I share with you the model that I'm going to share in a minute, you'll see that the words assurance and appropriateness or appropriate are built throughout that template. So we need to focus on two key aspects of governing data, or of governing the organization. So one is the assurance that governance is going to happen. So if we work with our Agile teams and we get them convinced that data governance is necessary, we want to get some level of assurance that governance is going to happen, at least to the negotiated level of governance that we've defined for our organization. And sometimes in order to get to that assurance that governance is going to happen, there needs to be some level of a mandate from our senior leadership. And in order for that to happen, senior leadership needs to understand the relationship between data governance and our Agile development methodology. So we need that assurance, and we want to make sure that we have the appropriate level of governance that we're going to apply. So when I joke before that the data people are asking for 18 pages of documentation, well maybe we need to limit it down to a quarter of a page or a half a page or something like that. If we've got a list of questions associated with data requirements, instead of coming at them with 30 questions, let's come at them with a handful of the most important questions that we want to have answered. So let's make sure that we're applying the appropriate level of governance. So just as a quick reminder, and I stated this upfront at the beginning of the webinar, that data governance is the execution and enforcement of authority over the management of data and data-related assets. In order to execute and enforce authority and to make certain that it is or to assure that it is taking place in the agile delivery methodology and through the agile efforts, it may require that there's a mandate for the data governance and the agile development teams to work together. So always come back to the definition that you have for data governance and that's the reason why I word it very strongly. Some organizations look at that definition of the execution and enforcement of authority and they say that there's a word too strongly. Well, the fact is, no matter how you define data governance for your organization, the truth is that in order for it to be successful, it needs to execute and enforce authority. And in order to be able to do that, in order to be able to apply data governance to our agile efforts, we need to make sure that we have some level of assurance that the agile teams are going to follow the things that the data governance people are requesting or that the data governance people are requesting the appropriate amount of information from the agile team during their effort. So again, come back to the definition but those two key words, assurance and appropriateness are really inappropriate or really important when it comes to trying to identify ways to be able to apply data governance to agile efforts. So typically, and again, from my experience, you will not be able to apply governance to agile efforts if there is no assurance that governance is gonna take place and if the appropriate level of governance is not applied. If you ask for too much, they're gonna push back as hard as you push. So let's make sure that we are very specific and we tell people that are parts of these agile development and delivery teams why we're asking for the information we're asking. What are we going to use it for? Where is the organization gonna benefit from that information? So typically, again, from my experience, I've not seen organizations that were able to apply governance to agile without some level of assurance that the teams were gonna follow the rules and that there was the appropriate level of governance being applied. So let's talk about these two things real quickly. Assurance is, the quick definition of assurance is making certain that it will happen. And so I just shared with you real quickly a couple of the synonyms, word of honor, promise, pledge, vow, guarantee, commitment, no matter what it is in your organization, we wanna make sure that there is some level of commitment from the agile teams to at least follow the limited amount of governance that we're asking them to apply to their efforts. So to get to assurance, it typically requires that our management understand, number one, what the goals of data governance are and that there's different approaches to data governance. We don't need to take a command and control, hit people over the head with a stick, change their title. We don't get to follow that approach within our organization. There are alternative approaches like the noninvasive approach to implementing governance programs. We also wanna make sure that management understands the goals of agile, but in most of the organizations, I see they can describe very quickly what it means to be agile. We're gonna be quick to adapt, we're gonna be quick to deliver, we're gonna deliver high quality, senior leadership seems to know and understand the goals of being agile. They need to understand that how data governance and agile can work together and once they have that understanding, they need to accept that and promote harmony between the data governance efforts and the agile efforts. If we can never get to a point where we have harmony between our data governance and our agile efforts, that will be a great thing within our organization because again, those agile efforts are not focused on things that are meaningless to the organization. It's typically large, complex efforts. So let's look at the term appropriate, and appropriate, suitable and proper for circumstance, some synonyms of that, fitting right relevant, but whatever terms you use in your organization, let's take a look at the level of governance that we're asking of the agile teams and make sure that what we're asking of them is appropriate and that we can validate and verify for them why the information that we're requesting from them, why it's important, how it's going to be used, who's going to use it, and the value it's going to bring to the organization. So typically, in order to come to an appropriate level of governance applied to an agile effort, it requires some level of negotiation or compromise from the data governance people, from the agile people. We need to look at the levels of documentation, the requirements and the metadata that we're asking for as parts of these efforts. We need to have a strong definition of what's right. As I mentioned before, the Bill of Rights, getting the right people involved at the right time, these are things that we can help to apply from a governance perspective to agile efforts. And typically, in order for it to be appropriate, at some point, we're going to want to have management's level of support or approval that the things that the data governance team is asking from our agile teams are appropriate and that they're useful to the organization. So here's the model that I spoke about a little bit earlier in the effort. And typically, what I did was I took the different phases of an agile effort, and I broke each one out into how we might think about applying data governance to each of these different phases. And the reason why I put the term data in quotes is that they might not all be data related. We certainly want to apply the right level of governance to each effort, but since we're focusing on data governance with this webinar, let's talk about it from the data perspective. So the first step, the first phase of an agile effort is to develop functionality then different ways that we can apply data governance to that phase of the agile effort is to assure the appropriate requirements. And as I mentioned before, those two words, you're gonna see them throughout this model, that we're gonna assure the appropriate requirements are gathered. That means not too much, not too little, but the appropriate level that's necessary in order to govern the data of the agile effort. We wanna make sure that we can apply governance in that way. We assure that there's adequate development time in these agile efforts. Usually, the biggest focus of the agile efforts is on time, and make sure that we have adequate time and that we have adequate resources that are associated with developing the functionality associated with the whatever it is that we're delivering in our agile effort. We wanna assure functionality and interdependence. So as we develop and test and integrate functionality, we wanna make sure that they work interdependently with each other. So data governance, if they have that level of authority or if they have that level of influence potentially over the project, they can make sure that we're looking at all of these things and that all of these things are kind of crossed off a checklist that we have. They assure the appropriate sign off of the development efforts. They actually assure the appropriate sign off at each of the different steps. So let's look at the next step, at the integrating test step of an agile effort. We can assure the appropriate integration and testing plan. We can assure the involvement of the right people at the right time. We can assure the appropriate data to use throughout this test. I had an organization that I was working with recently using live data as they were demonstrating their release and the problem with that was that the rules said that they couldn't use live data. They couldn't use data that had customer names and addresses. They needed to make certain that that data was encrypted enough that people couldn't recognize true people's names and the true values of the data. So one of the things data governance can do is assure that they're using the appropriate data in order to test in their process. Assure the appropriate testing time that we have enough time to do the testing and to validate and confirm the results in the organization. Move down to the next step, demonstrate the release. Where data governance or where governance can be applied to each phase is that we can make sure that the appropriate audience is involved in those releases, that the appropriate data is used in those releases again, that we're validating and confirming our results, that we're assuring that the appropriate level of release and sign off you can see the words assure and appropriate are used throughout this model. They assure appropriate results documentation of the demonstrate release. And as we move into the next piece, which is the making of changes, they assure that there's appropriate level of change management and the appropriate level of documentation in the appropriate level of follow-up when it comes to things like technical debt or data integration debt. By the way, there's a great article on tdan.com right now about data integration debt and technical debt if you're not familiar with that subject. During the make changes phase, we can also assure the appropriate level of data considerations throughout the project. And as we move on to the next step, the last step, here we go, system testing, we again, we can apply governance to these efforts by making sure that there's an appropriate testing plan that we're involving the right people at the right time using the appropriate data, allowing appropriate time and validating and confirming results before we actually go live with software that's been developed as part of this agile development methodology. So basically, as I mentioned at the beginning of this section of the webinar, it really boils down to two primary things. It's assurance and that it's appropriate. We wanna make sure that management has a level of understanding to make sure that there's the authority for the enforcement of data governance rules or at least a limited number of data governance rules during an agile effort. And we wanna make sure there's an appropriate level of governance that's being applied. So typically, this is gonna require some level of compromise to satisfy both camps. And by both camps, I'm talking about the data camp and the agile camp, it's gonna require a certain level of negotiation. So it's good to have people that are heading up agile efforts and data governance efforts to work together to negotiate exactly what governance is going to look like in those agile efforts. And it requires a level of acceptance to be able to satisfy both camps. We don't want, for example, the agile people, the agile teams to just give lip service to the fact that they're doing governance. We wanna make sure that there's some level of assurance that the things that we're sharing with them are being followed throughout their project methodology. So basically, to summarize the things that I've talked about today, we started out by looking for some common ground to stand on. We talked quickly about the data goals of an agile effort and the agile goals of the data governance program. We spent some time talking about bridging the gap and building understanding, especially at the senior leadership level of where data governance and agile can work together because as I've seen in a lot of organizations, there's been very little effort taken at that level of the organization to bridge the gap and build understanding as to the relationship between agile efforts and data governance efforts. And the last thing we talked about was the different steps of an agile effort and how we might think about applying governance and applying agile governance specifically to those efforts. And with that, the last thing I'd like to do is share with you again, that the topic of the real world data governance webinar next month, we're gonna be talking about governing data governance metadata and governing master data metadata as well. With that, I'd like to turn it over to Shannon to see if we have any questions today. Bob, thank you for another great presentation. And just to answer some of the most commonly asked questions, we will be sending out a follow-up email by end of day Monday with two all registrants with links to the slides, the recording, and all the other matrices that Bob has pointed out today. Although for our hardcore Australian contingencies, you'll probably get it Tuesday, maybe end of day Tuesday. Love you guys for joining so early your time. So just diving right into it. In understanding the goal of supplying good data to an agile project without interfering with the project schedule, how have you seen the engagement of data storage work on agile projects executed? We are being challenged by leaders on this now. That's a great question. That's a fantastic question. So in order to engage sister, so if we follow the Bill of Rights, getting the right people involved at the right time, a lot of it depends on how you define stewards within your organization. The way that I define stewards are that they're people that have a relationship to data, whether they're defining data as part of their job or they're producing data as part of their job or using data as part of their job. If we have data stewards, we wanna make sure that we use the best of the best of the data stewards. So we use subject matter experts that are associated with certain subjects of data when we apply them to the effort. And oftentimes the agile teams are gonna pull in the people that they feel are the most appropriate people, the most appropriate stewards in the different steps of their development methodology. Well, the fact is the data governance team can help with that. We have recorded oftentimes who the stewards are. So if they're looking to say, well, who's the strongest person that knows about our sales compensation process when it comes to certain types of sales in certain parts of the world, well, then we as the data governance team typically have some type of an idea as to at least who the leadership is over that data for the organization. And we can suggest people so that they can involve the appropriate stewards. So it's not an easy question to answer, but we need for them to want from us that we can help them to identify those appropriate stewards and get them engaged. It's not typically a matter of the stewards themselves wanting to get engaged. It's more a matter of the agile teams wanting to get the stewards engaged. Great question. And Bob, it was printed out, I think it was slide 24 or 25. If you wanna pull that back up. Sure. Ray, that number four data governance is an enabler for regulatory compliance. Do you wanna comment on that? That the governance is an enabler for regulatory compliance. Well, as I talked about, data governance typically is looked at from three different perspectives. It's looked at from the definition perspective, from the production and from the usage perspective. And oftentimes the definition and the usage perspectives are the ones that need to be governed the most. So we need to make sure that we've defined the rules associated with compliance in the effort. But we've also expressed the rules to the appropriate stewards of what are the usage rules associated with it. If I'm understanding the question correctly, that's the way that typically organizations enable that way. I just think it was, yeah, it's just a comment specifically, so that's great. And you know, moving on to the next question, we, this particular question is, we are relatively new with our data governance program. We work closely with legal privacy and security departments. With the digital engagement, does it take a while for a review to complete for a project? Is that normal for it to take longer? Well, again, that's one of those things. I mean, remember I used the words assurance and I used the appropriateness. You know, I used appropriate and appropriateness. And so you gotta take a look at what's taking so long. Is it the involvement of the people? Is it the information that's being requested? And if we can limit it and make sure that we're only requesting the appropriate things during the review, that if there are things that might be viewed as being overkill for to the agile team, maybe we can do those independently of them. But we just want to make certain that the teams that are, that the agile teams understand that all of these aspects of governing data need to be covered. We just want to make sure that we limit what we ask for of these teams to things that we know that we're gonna make use of. And as you review your process of what's taking so long, you might find that there's things that you're asking for that you're not even using in the long run, maybe, just maybe, those can be negotiated out or those can be handled in a different way. We're focusing a bit on agile specifically. In agile, there's no formal sign-off. So how to get the appropriate, quote unquote, the sign-off to be achieved? Well, if there's no sign-off, at least approval to go to the next step. And maybe that's one of the things that's missing from the agile efforts and why things, why these efforts so often are late in being delivered or are slow in being delivered is that we're just not focusing on those things that we need to focus on. So again, I'm not sure if that answers the question, but those are the things that I would focus on first. And where can the attendees find the information on technical debt that you have mentioned? On the pages of TDAN, there's an article written by a friend of mine, David Wells, where he talks about integration debt and technical debt. So let me explain real quickly what I mean by technical debt. In the organizations that I've worked with, typically there's kind of like a parking lot where we take things and if we can't address them immediately, we put them into what we call technical debt. And technical debt can continue to build up just like financial debt unless there's somebody who has the responsibility for making certain that that technical debt is being addressed. Oftentimes, that technical debt comes down to specific data issues, whether those issues are data definition, production or usage related. And so one of the ways that governance can assist an agile effort is to make sure that there is some level of follow-up to the review and the resolution of issues associated with the technical debt. And from another hardcore attendee, I just love our webinar community. We're just awesome. It's pending from late night. What I have noticed is that most leaders are wary to start governance. Looking from the DAMA DMBOK, they all say, where do we begin? If you're not familiar with DMBOK, it's the data management body of knowledge produced by DAMA International. Yeah, you know what, it's a big hurdle to get over with a lot of management to get them started. If you're familiar with my presentations and my webinars, the suggestion that I give to people when they're going in to get their management to understand that governance needs to be put in place is start out with the approach by telling them, you know what, we're already governing our data. There are people in the organization that have accountability for the data. It might not be formal. It might not be efficient. It might not be effective. But in most organizations, in order to get to the level of competency that they're at right now, in most organizations that's pretty high, there was some level of governance that was already in place. And so I know that a lot of senior leadership has this thought that data governance has to be brand new and it really has to impact the organization. If we take a different approach with them and we talk to them about the fact that there's already levels of governance that take place, there's already privacy and security and regulatory control that might be going under names other than governance, but we're already governing our data to a certain degree, we can do it better. So if we go into our management that think that it's going to be really difficult and we say, you know what, we can focus on the definition that Bob Steiner uses for data stewardship, which is formalizing accountability for the definition, production, and usage of data as I shared at the beginning of the slide deck. Just let them know that there's alternative approaches and that you may already be part of the way there without even ever having started. Now what if data governance itself is moving to an agile methodology? Any caveats there? Wow, data governance moving to an agile methodology. You know, I'd be very interested in talking to the person who posed that question because I am not familiar. I mean, I know that data governance efforts want to be agile enough so that they will be accepted by the agile delivery efforts that I talked about, but, you know, agile data governance, again, if it really is a thing, it's focused on making sure that we limit to the appropriate level those types of things that we as the data governance practitioners are asking of our agile development teams. Just this particular question, the questioner just read your book, just read non-invasive data governance and see that there is a question list and my organization scores a two on all questions. What have an agile organization in place but tactical management is resisting heavily? Let's say the last part of the question again. I'm sorry. And so we have an agile organization in place but tactical management is resisting heavily. Is resisting heavily to the agile development or is okay? So I guess we can't really have give and take with the person that answered the question. You know, it's typically what I've found is that organizations don't resist agile the way that they resist data governance. And so if they're resisting agile, then maybe they've had a bad experience in the past where the agile efforts, although initially it was scheduled to save money and to deliver a quick and effective results where they've had bad experience through that. With data governance, it's just getting them to understand that data needs to be managed as an asset and that we can formalize accountability where there is informal accountability now and be successful with governing data as part of these initiatives. All right, well, let me see if I can sneak in one more quick question here. Are data modelers or having challenges modeling with agile projects? Any recommendations for them? Well, and the reason why data modelers oftentimes have a hard time modeling with agile efforts is that I'm not certain that the agile teams see the value that comes from the data modeling. And we as data practitioners know the value that comes from data modeling, comes from the capture and the collection and the recording of thorough metadata associated with our data. You know, organizations just need to understand that data modeling, that they need to understand the upside to data modeling so that they can at least allow for whatever limited nature of data modeling can be effective and be appropriate in order to govern the data definition and the database design for the agile effort. All right, well, I'm afraid that is all the time that we have for today. But if you have more questions, keep them coming in because Bob will write up answers to the questions we didn't have time for and we'll get that out in the follow-up email as well. So just a reminder, I will send a follow-up email by end of Monday, Pacific Time with links to the slides, the recording, the matrices and everything else we've been mentioning throughout the webinar. Thanks, Bob, for another great presentation and thanks to our fabulous webinar attendees. You guys are just the best community. We just love how engaged you are with everything that we do and really appreciate it. As Bob mentioned, we will both be in Enterprise Data World in Atlanta in the first week of April. So if you're gonna be there, do stop by and say hello. We'd love to meet you in person. So I hope everyone has a great day. Again, thank you so much. Thanks, Bob. Thank you, Shannon. Thanks, everybody. Cheers.