 Hello and welcome. My name is Shannon Kemp and I'm the Executive Editor for Data Diversity. We'd like to thank you for joining this month's installment of the Data Diversity Webinar Series, The Heart of Data Modeling, moderated by Karen Lopez and sponsored today by IDIRA. Today, Karen will be joined by an esteemed guest speaker, Tamara Clark, to discuss data governance in an agile, crum, lean MVP world. 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. And we very much encourage you to chat with us and with each other throughout the webinar to do so. Click the chat icon in the top right corner for that screen to activate that feature. For questions, we'll be collecting them by the Q&A section or if you'd like to tweet, we encourage you to share and highlight their questions via Twitter using hashtag heartdata. As always, we will send a follow-up email within two business days, containing links to the recording of the session and additional information requested throughout the webinar. Now let me introduce to you our speaker for today, Karen Lopez. She is a senior project manager and architect at InfoAdvisors. She has 20-plus years of experience in project and data management on large, multi-project programs. Karen specializes in the practical application of data management principles. She is a frequent speaker, blogger and panelist. Karen is known for her fun and sometimes snarky observations on data and data management. Mostly, she just wants everyone to love their data. You can follow her at Datachick on Twitter. Karen is joined today by, again, like I said, by guest speaker, Tamara Clark. Let me turn it over to Karen to get us started and to introduce Tamara. Hello and welcome. Thanks so much, Shannon. Welcome, everybody. Yes, I'll introduce Tamara shortly. But I also wanted to say thank you for idea for sponsoring. It's always good to have vendors participate in the community of webinars and blog posts and everything that are happening on data versity. So we're going to talk about all the mean words of agile and scrum and lean and MVP and those things. And as a reminder, you can tweet all this. Both Tammy and I are watching the hashtag heart data. And by the way, this was a picture released this week by Astro Tim Peek, the UK astronaut currently up on the space station, because I always need to have a space picture in my presentation. So Tammy and I have worked together on some volunteer things before, and she's a frequent speaker and she blogs about data-related things, specifically about SQL Server and some of the SQL Server reporting features. But she's also a chronic volunteer like me, and she loves data too, which is why I have her helping me out today. But also, as usual, you're the panelists as well. That's why we open up the chat to everyone so you can chat with all the other attendees. And if you have a special question that you'd like to see addressed, please put that in the Q&A because I'm more likely to see it. So we will start out with our polls. I want to know who you are, and I'll get the poll started just in a second. So I'm asking you to fit yourself into one of these buckets of a data governance person, a data model or data architect data analyst, some sort of dev DBA other technical person, some other type of architect, or just a plain old other person. If you're another person, you can throw what you are, since you don't feel you fit into those buckets into the chat, so we can kind of get a good feel for what you do. And while that poll is going on, some people are having a hard time figuring out which bucket they belong in. That could be a data governance problem. Cameron, where would you put you? Oh, she's muted. So it looks like the poll is closing in a second now. Hang that mute button. Oh, we got somebody from the data model or architect analyst. There you go. We've got some scrum masters, some agile coaches, product managers, all good stuff. So I can show the poll results. So we have about 21 people saying they specialize in data governance, about 51 data modelers, which is kind of, I would expect that, since this is the data modeling series, about nine of you are devs, and other tax, three other architects, and 14 others. Developer, architect, process improvement leader. That's good. You could have picked one of the buckets or not. So then we have poll two, and I want to know, does your organization have a formal data governance program? And by formal, I mean, like, written down and used and having the full life cycle of data governance. So you have about 20 more seconds. Maybe five seconds. And in the poll results, we can see that we have about 27 of you have said, yes, you've had a data governance program for more than a year, 26 of you, so about the same amount. I'm not saying yes, but it's just starting 33% of you saying not quite yet, and nine of you saying no and likely not. 41 of you didn't answer. Maybe that's because you're busy typing up all your tweets and everything. But if you don't have, if you voted no and likely not, I'd love to hear some of the rationale in the chat. And I see yes sort of. I need to give you some sort of things in there. Yeah, the organization has one, but it's not followed in my immediate area, yeah, because your team is special or something like that. So now my next poll. This one, you know, I made this one binary intentionally. Does your organization use any of these new methods of agile data scrambling? Just anything other than no formal methods at all. Just people go and do work. And that's because I knew everyone would kind of say something in the middle. So much like my contentious issues presentation, I'm trying to get you to make a, actually make a vote and supply something that we can talk about. We've got about 20 more seconds. We call ourselves agile but our cowboys. Yes, I think I've even used that term in one of my presentations that, you know, there's agile and fragile. Some people are drawn to certain parts of agile but not the other parts that make it work. Okay, so I'll share those results with you. So 91 of you, that's quite a big number. Say your company does use these, what I call modern development methods. 21 said no and 35 probably wanted to vote somewhere in the middle and didn't. Okay, so those are the polls we have. And I'll just flip through those slides really quick. So actually the thing that sort of surprised me about it is that so many people had formal data governance programs, maybe because lately I've been working on troubled projects. Part of the issue is that there is a lack of a formal data governance program. Whether or not it's called that, there's a lack where just each development team gets to do whatever they want and use the data however they want. And what we're going to talk about today is really more about what data governance is, what do I mean by these methods, and where do they intersect, and then some gotchas and some overlaps, maybe some warnings, and really talk about how do we make data governance and data modeling to a bit, since this is a data modeling webinar, how do we make that all fit together? So just like every other IT method, data governance has several different definitions because we as an IT profession are really lousy at doing what we do. We want our business to have a single definition or a single version of the truth, but we don't hold ourselves to that. So Bob Siner, who's also a speaker and blogger at Dataverse, has a data governance practice, and his definition was data governance is the formal execution and enforcement of authority over the management of data and data-related assets. Now I've added the highlighting here because these are the types of words that most modern development shops or teams do not want to use, and they consider these terms to be an affront of everything they stand for and believe in, and this is the classic conflict between people who are measured, compensated, rewarded, and punished based on completely different outcomes. So we on the data governance or data modeling side, we generally are about formalizing things, enforcing data integrity, having the authority to say no, this is what's going to keep our CIO out of jail, and to manage things. It's data management. Modern development methods quite often sprung up. At least the start of it was under the belief that any formal management enforcement authority or any of these things was what was keeping software from being completed. So Gwen Thomas, a friend of mine who runs the Data Governance Institute, her definition is a little bit softer on the terminologies. Data governance is a system of decision rights and accountability for information related processes executed according to agreed upon models which describe who can take what actions, with what information, and when, under what circumstances using what methods. So her definition of data governance really is about not prescribing what your data governance is, but being able to understand, to be able to set up a framework for data governance that's the right fit for your organization. Then there is a professional association, DGPO, which is a group of practitioners that has a definition. It's a discipline that provides clear-cut policies, procedures, standards, roles, responsibilities, and accountability to ensure that data is well managed as an enterprise resource. So again, this also uses words that are typically important to data quality and IT quality, but there are also words that are sometimes expressed as being the opposite of agile or scrum or lean or MVP. So what does Karen have to say about this? Well, I say it's good that we have data governance now. So back in the olden days we had data and we had no governance, or we had information and we had no governance, or we had knowledge and we had no governance. So we have data governance programs. They're being funded. They're being implemented. But one of my sort of snarky observations is I have no idea why we need to give all this governance stuff another name and its own program. For me, governance is just sort of the definition of any professional practice. And when we get through what are the features of it, you know, I kind of think that it really should just be accepted as part of how we do data management. So for instance, we don't really have something called engineering or architecture governance. In fact, the governance aspects of those professions are baked right into what we consider professional engineering or professional architecture. So while I do really think it's good we have data governance and we have them funded and we have business people as part of the process and we get the backing of management, it's just so weird for me to think that data governance is an optional component to managing people's data. And I mean customers' data, vendors' data. To me, data governance shouldn't be a separate thing. We have to have it a separate thing because of our history of IT and our history of development. But my goal in life is to have the concept of data governance go away and all the stuff included of it just be considered how we do IT. One great feedback, the difference is the business is not used to having standard methods and it's really owned by them. So the definition of some of the rules and policies and strategy for data definitely owned by the business. But I see it as the same thing as if we were building a full campus for our company and it had buildings and HVAC and power centers and utilities and everything. We would never be allowed to consider doing all that engineering and architecture to build a campus for like the big Apple mothership that's being built. We wouldn't have an option of saying well the business doesn't want to have grounded outlets because they don't like looking at three-hole prong things. They just wouldn't be allowed to. And no true engineer would really want to build something that way because it should violate his own personal feelings about what electrical engineering is or what installations are. But I get what you're all saying. This is really the reason my thought is in a bubble thought cloud is because I'm just sharing that among people, data people and governance people about how I feel about it. One of the things we send by saying we need to have a data governance program is that it's something optional that can be turned on or off. And I think none of the content of data governance should ever be optional. It ought to just be how we manage data. So why data governance is important. Well, a lot of the lean methods came up and are still very much embraced by people who don't work within the giant ecosphere of an enterprise organization. So when someone says, well, I use this on my project. We use lean and it worked really well. We got everything done. It was a lot faster. But then when you ask them about their project, they were building a 100% self-contained e-commerce site that was web based where they were defining their business and their software and their infrastructure and their technology all at the same time from a green field. Yes, like in a silo. And some silos are great. If you're building the next big killer Facebook, you're probably not going to do that inside a large enterprise complex living and breathing organization. You're going to do this all on your own. And a lot of the lean and agile methods work very well that way. If you decide that you don't want to support doing business outside of the state of California just because you're going to keep it small and manageable, you can do that. If you work for a global retailer, your project team probably cannot decide that probably. So we have to do most data governance inside a massively complex set of architectures where we have multiple tools, overlapping tools, redundant tools, old versions of tools. We have mostly vendor applications, so Salesforce and Oracle, financials and PeopleSoft and all these large ERPs. We have small legacy systems. We have other packages we bought. And now we throw in the cloud, whatever that is, and whatever someone wants that to mean, even more complex. We've got feeds with external data, redundant internal data, conflicting data, poor data quality, missing data, unused data. Our data is complex. And then we have all these methods that have overlap. We have methods now for infrastructure and DevOps, methods for development. We have data methods. We have accounting methods. We have compliance methods. We have all this stuff going on. And that makes governing the data a lot more harder than someone just building a one-off self-contained system. So there's some facets of data governance. These are kind of compiled through a lot of the sources on data governance, the books, the people I've mentioned so far. But generally, they fall into data quality. And most of my clients start a data governance program because they've had some really serious issues with data quality. They've also implemented data stewardship, which is about assigning a business person, sometimes in conjunction with an IT person, to help curate the data, find sources of data, set the rules for individual data items, and help enforce some of those rules. There's outside compliance, like legal compliance, privacy compliance, security compliance, payment system compliance, your own company's rules. There's understanding infrastructure and architecture to help you implement your data governance. There's the business making the decisions because a lot of data people get tied up into the, well, not everyone has a first name, last name, or middle name, but the company itself might make a decision that, yes, that happens, and here's the way we're going to handle it. So your data models aren't reflection of the real world. They're reflection of the world your business wants to see and work with, and our job as data modelers is to help the business make that right decision of how they want to do the business. And then every data governance framework talks about implementing standards and then about not just rolling this out and say, okay, everyone, data people, we're kings and queens of the world, you shall go and follow these tablets. No, we need to have monitoring and metrics and find out if these rules, strategies, infrastructure tools are actually giving us the returns or protecting us from the risks or keeping us compliant, and that becomes a giant feedback loop. So where does it help? Well, almost like everything that's being proposed in the world in IT or anything, is we don't do anything unless it saves money. But some data governance things clearly save money, like avoiding fines or getting rid of duplicate data or helping us make better decisions. It allows us to satisfy our customers because messing up customers' data and making data problems customer problems is very annoying. I have a whole presentation on that one. It helps us retain customers. I know I've left companies that can't keep my orders straight, that can't keep things in stock. Target Canada went out of business because their data and their stock never matched. I mean, that's a big deal. And it also leads to results, to returns on investment. But if you've attended one of my webinars before, you know I have this other definition of ROI of risk of incarceration because keeping your CEO and your CIO out of jail is part of your job, even if they didn't put it in your job description. And then innovation. I have many projects I've worked on where we weren't able to implement either competitive features or to roll out new ones because we literally did not have the data or the right data quality in order to respond to what the market wanted from us. So by having good data governance, it allows us to easily measure when we can innovate and how fast we can innovate and can enable innovation. It definitely has a big impact into data and business analytics. So Tammy, this is where your thing is. Like you're working on reporting and BI and analytics and these things. If your data, if you can't find the data or the data's crap, doesn't that harm you in getting the reports and everything out? It does. And it sometimes paints the wrong picture. Yeah. And people make decisions off the wrong data, right? Yeah. And that's not good. Yeah. So one of the things I use in one of my examples recently is this whole concept of you just need to know that in 1986 or 87, 7 million children disappeared off the face of the earth. And that can screw up your trending analysis. It could screw up. But do you know where that came from, Tammy? Did they clean up some social security numbers? Yeah, something like that. So up until that point, you could claim dependents, which are not all children but pretty much are, on your tax return just by writing down how many children you had. And funnily enough, many people overcounted their children when they could get like a $1,800 deduction for each of them. And so the IRS implemented that if your kids were over, if your dependent was over the age of five, they now needed to have a social security number. And the next April 15th, these millions of children just went away or ran away or the parents, I don't know what they did. And then finally now we're in the U.S. where now any dependent has to have a social security number. So if you're going to claim your dog, it has to have a social security number. And so this data governance feature, that whole having to have a social security number is kind of a data governance thing, like we will only count commissions for which we have an actual trackable sales order. So I worked with a company that let sales people report their sales separately from their actual sales orders. And then once they put in that rule, it turns out their salespeople had overcounted their sales. Can you believe that? I think in the movie Fargo it was a lot like that too. So data governance then also reduce costs. So if you have more accurate data and you can rely on the data, you're able to cut costs and it allows the whole organization to be more responsive. And not just the business people, but the IT people, because there's no point in managing bad data or data you don't need or lots of duplicate data. So how do we establish a data governance practice? Well, like any program, you start out by taking an assessment of where you are now. What tools are you using? What development processes are being used? Not what people say they're using, but finding out what we're actually using. Finding out if we've been penalized or had findings by regulatory bodies. Finding out what our staffing skills are. Finding out what models we have. What our business and customer pain points are. What the IT pain points are. So a lot of people think this whole data governance versus the devs is something, while I say it's an ongoing conflict, we actually need to listen to what the devs find as their pain points. If every little change they want to the data model takes three months, that's a pain point that data governance could fix because part of our data governance strategy could be we're going to take away waste and we're going to take out processes that aren't helping us. And then, of course, third party audit findings are really important for taking care of. So some deliverables from these are, in general, you end up with a strategy and some policies and tools and processes. It doesn't mean that, you know, every team is going to use the same tools. Every team is going to use the same process. But what you have is that former measurement you just took against some metrics that you're going to roll out to find out if having multiple tools and multiple processes is working against what the company wants to get out from IT and from business processes. You often end up with new roles and responsibilities. So things like data stewards, data analysts, curators, maybe some dev roles that are more focused on data, maybe some new reporting roles, reporting analysts, those things. Definitely, you usually end up with more data quality roles and methods. Data modeling often ends up being literally something you have to do in order to drive out waste and redundant data and incorrect data. And then new monitoring, reporting, and analysis of results. So in Gwen's framework paper, which I highly recommend, it's very accessible to understand and follow of establishing a data governance program. You know, what she says is, this is what almost every program rollout looks like in regardless of what you're talking about, but you need to figure out what your return is going to be. You need to do a roadmap. You need to plan it. You need to get funding. You need to design the program, deploy it, then actually execute it, and then monitor, measure, and report back. And we're going to come back to the slide in a minute. So what are these agile and new methods? Well, as I said in one of my agile presentations this year, I love working on those projects. It's the fragile ones that I hate working on. And as I said, I specialize in turning around troubled projects, which means I see mostly fragile projects. So a lot of the gotchas I'm going to list is not because I'm anti-agile. It's because I have to fix so many of these problems. So if you're going to be working on an agile project or even a scrum one, which is based on agile, the best thing to do is go find the agile manifesto. I think it's agilemanifesto.org. And go read them and then memorize them because you're going to use these principles in guiding project teams about data governance. So these are all great manifesto items, satisfying the customer, welcoming changing requirements because changing requirements are a fact of life because either business people can't remember or can't decide or the world's changing around them, whatever it is, that you welcome changing requirements even late in the process, that you deliver working software frequently with always a preference for shorter time. And this is my favorite manifesto item having grown up in a time when we cut project phases into six-month increments and we often didn't see working software for a year or more after we started requirements. I mean, there are some specific cases where that has to happen, like in federal acquisition rules, say that all the requirements must be done by one organization and all the implementation must be done by another. It makes it hard to do them both at the same time, but it can be done. But delivering working software frequently is an important part. That business people and developers must work together daily throughout the project. This is sometimes the shocker to business people that they have to be involved daily, that you have projects around motivated individuals. Now, motivated individuals sometimes attracts really great people to work with and sometimes that means people who are obsessed with doing things one way. And the hard part is trying to keep people motivated without them being overly obsessed and that applies equally to us data folks and the development folks and the other people on the team and give them the environment, the sport they need and trust them to get the job done. And we'll come back to that one. And the most efficient and effective method for conveying information is face-to-face conversation. Now, while I agree with that manifesto, I have not worked on a project that allowed me to work face-to-face with everyone on the project. I think it's been longer than 15 years because we have diverse teams, we have teams that are with partners, we have people who are all over the world. So, while I do enjoy face-to-face conversation, I can't make that happen. And the next part of this is the key thing to Agile. For the most part, Agile development methods is about the software, the production of software on the project. Now, that doesn't mean that you can't have an Agile data governance process and Agile accounting reformatting project. You can have an Agile HR process. As a matter of fact, this is the buzzword to throw in front of every program. But that's not what I mean. Agile manifesto and everything tied to it when we talk about Agile development is focused on the software. So, most Agile projects don't expect to build out a server farm. They don't expect to have to buy desktops for all the users. They don't expect to have to evaluate and acquire a database management system. It's about building the software. Agile processes promote sustainable development and everyone should be able to maintain a constant pace indefinitely. So, what that means is run a marathon every day. Well, in order to run a marathon every day for most people, that means going slowly and taking lots of walk breaks. It doesn't mean sprinting a marathon every day. Technical excellent and good design. This is one that I have memorized that I use all the time because my definition of good design involves good data quality. Maximizing the amount of work not done. Just let that one sink in. That means that I want to do the least amount of work. I only want to do the work that needs to be done. And we data people have sometimes been guilty of learning a process in 1986 and still trying to do all the checklist items from it because that's how we learn to do it and we aren't able to tailor the cost benefit and risks deciding what needs to be done when to what's happening today. Self-organizing teams are also a feature and that at the end we reflect on what we're doing and try to figure out how to become more efficient. So I think that's all important. The reason I have these memorized is sometimes my processes need to be agile and my team doesn't want them to be. For instance, I want to be iterative. I want to make changes. That's part of the agile. Everyone needs to buy in and be able to make one of these principles available to them at least. So very quickly, this is how a typical agile or scrum development process looks like. We have those blue bars are sprints. So you do lots of sprints, sometimes all at the same time. A sprint typically lasts a week to three weeks, closer to two. And you code really hard and you do a couple of sprints and then usually depending on what process you're following, there's a sprint where you kind of catch up and either deal with backlog things or parking lot of things or use it for when your sprints are out of sync, whatever you need to do. So that's sort of the sprint, sprint, take a walk, break, sprint, take a walk, break, sprint, sprint, how you can maintain the constant pace. But a typical sprint works like this where you start at the beginning and you start with your input of a backlog and stories and everyone gets those and those are the outcome of sprint planning and everyone does those and then they hand off the stories to everyone and the first thing the developers say to me is where the heck's our database, right? Because I got the stories back here, which is really like the use case or the business story, like what is this about? And I've got all these questions that I need to ask about in order to do a data model, but there's no time because these people want a database and I'm still trying to do requirements because my story has something like and then we charge sales tax if we have to and I know that that's a huge story all in one little sentence. So what happens is everyone's frustrated and everyone hates what's going on and pretty soon the developers say, okay forget the data architect and the data models, we'll just build the database as we go along and that's not good data governance. So one of the things that goes wrong with data governance in Agile is that the requirements are out of sync. There's no room for stewards or anyone to understand. There's no room for any of this to happen because everyone's frustrated with the timing. So how do we fix that? Well the way we fix it is from a data modelers point of view the data models and the data modeler need to be part of the sprint planning or even before so that they can get a headway and get the right requirements for the developers who are waiting on mostly a database. They still like my lovable, beautiful data models but even that's not usually enough time. So what I recommend is that the sprint planning that I'm working on isn't going into this sprint, it's going two or three sprints ahead and that gives me this time to work on requirements, get things clarified, but that also implies that something way back here had to have happened before we start this sprint. So the key to making not just data modeling but any data quality, understanding what needs to be encrypted, understanding what the security and requirements are, understanding what features we're going to use in the database, all of that needs to happen long before we hand something over for the coders to happen. And that sounds like it's anti-Agile but it's not really. It's about doing the right amount of work and reducing rework and not having a lot of wasted time because someone threw together a database design that isn't going to work in production. And SCRUM, which brings us, you know, the concept of these backlogs in the sprint planning and being able to do the sprints has also important values that are very much like the manifesto and they sound really great in the manifesto. Oh, manifestos sound really good, actually. It's that those are important to understand but to understand what they mean under the covers and how they typically get misinterpreted on a fragile project, which I'll leave for another presentation. So then there's Lean. Lean software, so Lean came out of the manufacturing process specifically at Toyota, so physical manufacturing and is now being applied to the software part of the world. So the number one thing, eliminate waste. That sounds really good. The problem is one person's definition of waste and another person's definition of waste, you know, that can be different. We can make sure everyone's learning. We're going to decide things as late as possible but deliver as fast as possible. So you can kind of think about, you know, where there could be a disconnect here is deciding late as possible. That sounds good. Like, don't set things in stone six months ahead of time because the world's going to change long before you get to build on it. But deciding something really and key important that also needs a lot more work before we can actually implement it, that works against most data governance processes. Empower the team. So you notice Agile and Scrum and Lean empower the team. And I think that's really great. Like hire great people, give them the authority to make decisions and get out of their way. Who does not want a boss like that? The problem with what empower the team means on fragile and broken projects is don't let anyone review their work. Don't let anyone, even someone who's an expert in that field, tell them that they might be doing it wrong or that they might be sending the CIO to jail. It usually means on the most broken teams, let the most inexperienced, untrained person do it because they can do it a lot faster than they experience people. And that is true. That's the physics of resourcing. The person who doesn't know how to properly secure a piece of data is probably going to take a really fast, easy-to-break way of doing it because doing it right is hard. That's why every other profession has specialists. Build integrity in. So build it into your processes. I'd say build it into your data and see the whole picture. These again all sound great until you see how dysfunctional team members might try to build them. So what do they mean by waste? Work that's not finished. Extra processes. Features you don't need. Getting moved around from tasks. Waiting for something to be done. Moving for the sake of moving. Building defects into your thing and management activities. Now, if you're a data governance person, your developers are going to see extra processes around all the data governance. That's all they're going to see. They don't care that somebody else in another building says that we should not be using those security numbers in this design because we don't need them. That overview for them is going to be seen as an extra process. Extra features. I've had a developer tell me we're not going to do any privacy or security stuff. After we've built the systems, then someone can come in and add that to it because that's an extra feature. Management activities. So that could mean a lot of things, but usually data management is included there. Oversight, audit, reviews. Tammy, what would you see as a management activity that you think actually needs to be done? Oh, I mean, there are some working ones. Well, I think management activity is a time sheet. Yeah, stay out of my way. Let me get my job done. I think one of the times I like managers to be bulldozers, like go get what I'm waiting for. Move on, so I'm not wasting time, right? Yeah, exactly. So that might be cool. So get rid of my waiting. Stop pulling me off to go fight another fire, right? Let me finish this or get someone to finish that other work, right? I think we all agree that defects cost us time, but then we have to manage that against, you know, fail fast, which says don't sit around trying to make the perfect data model or the perfect database or the perfect design. Let's get something going and write down what needs to be fixed. Now, this is during the development process. I don't mean this during the production process, but all of that's important, too. So what are the lean processes for software? We said do all these things. Oops. The minimum viable product or MVP. Now, MVP is usually for startups. Minimum viable product is the process of developing a product, which usually is mostly a 100% software product, software and services that is pared down but still can be released. So that's the important part. It usually has enough value that people are willing to use it or buy it. It demonstrates all that it's going to be in order to retain those people. And the most important part is that it provides this feedback loop to guide future development. So the easiest case of minimum viable product, now Cortana is listening to me. When did I say Cortana? So the easiest thing to, that you might have seen personally, have you ever seen one of these, Tammy? It's a website. She said, hey, we're going to build something. We've got a website and it's called Free and Easy Money. And you go to the website and it's one of those beautiful parallax with barefoot women on the beach walking but just a copy of her feet. She's carrying a guitar and there are people in the background and there are trees and birds. And it uses all this marketing speak and it says, you know, we're going to make your life easier. We've got a new way and we are the bank machine for people who love music and data. And you're thinking, that sounds great and you scroll and you scroll and you scroll. But it doesn't tell you what it actually is and it just has a sign up box. It says sign up to be one of our, to get an invite for our product. Have you ever seen one of those? I think there was a rash of those not that many years ago where everybody was coming to market with Twitter, the new greatest Facebook, the new greatest MySpace. Yeah, so all of that. That's actually the minimalist, minimalist example of MVP. And that is basically, that's the first test of, I built a website and I can get people to hand over their email address just because the story I wrote. So that's a way of testing whether or not it's worth it for you to even start building something. Yes, vaporware is also what it's called. But it's not, vaporware is something that goes on for months like that. So basically the minimal, minimum viable product is that. But most MVPs are something with a little bit of something. So in one of the stories that I heard, you know, what you want, you don't want to go off and spend two years or five years building the next best Facebook and then deploying it. What you want to do is build maybe one feature of the next great Facebook which might be, oh, I don't know, Facebook Messenger. So you're trying to take away, you know, maybe chat or iMessage or something. So you build this thing, the next great Messenger, and you get people using it. But it's just a little simple chat thing. And you tell them in the future they'll be able to share their stories and their videos and their folders and they'll be able to like and rate and all that other stuff. And then yes, and it is, like what we call prototyping, the difference is it's still production. A lot of prototyping has, you know, truly faked out things happening on the background. Not that some MVPs don't, but, you know, you have these things going on there. Now, here's the key thing if you're in the enterprise. It's usually technical products used by technical users. Why is that? Because we technical people are willing sometimes to get in early, to be an early adopter, to put up with, you know, mostly functional feature-lean products, to get in early, maybe grab that handle or that avatar or that login ID or get our own name in the URL or get our own name as the user name. We're willing to do that, even if nothing really becomes of it for another couple of years. Now, I'm making this sound all bad and it's not, it's because it's all about feedback. Early feedback, feedback, and then some feedback so that you're not spending any time building things that end users don't want. So what you can see is you're probably not going to use minimum viable product for your accounts receivable system because we already know that there's a huge complex mass of things that have to happen inside a project like that. But if you are building the next Facebook or the next Twitter or the next thing that we've never even thought of, you would probably use MVP. But the reason I brought this up is that I don't personally think there's a whole lot of enterprise stories that fit well with this MVP method. So a lot of times some dysfunctional teams want to latch on to these new methods so that they can just do their work unbothered, ungoverned, unconstrained, unreviewed. That's for broken projects. So where do these all intersect? Well, here's Gwen's data governance process. Really, the hard part about data governance is, so this was my how to fix agile. It doesn't even come in until, you know, right in here. When we're starting to deploy the governance process, I can actually do it. So it fits inside this Chevron-y arrow-y thing. And we will use, we will do lots of other things that are happening there because in addition to governing data, our reporting systems and our curating systems will all be part of this process. The disconnect is when people try to, data people try to involve the devs heavily develop or involve a sprint or an agile project team into this part of it. So just like most data people don't care how the network got set up, we just want to trust the people that they did it and it's going to meet our needs. The agile and scrum people just want to know what's going on here and how it's going to impact them. And they might also have some inputs into the monitor and effectiveness of it all. And it might also integrate with their own monitoring and effectiveness projects. Let me just check. Where do they intersect? Remember I talked about sprint planning and preahead sprint planning. The sprint planning I think must take into account data governance. So there must be planning and resourcing allocation for security, compliance, privacy, data quality, all of those things. If sprint planning thinks we'll just add that at the end or it's going to be taken care of and what data we're going to use, it's going to fail. But remember those red words. Agile pros do not want to hear words like constraining and standards and reviewing and authority and enforcing. We're still going to do all that, but I highly recommend that we find the right vocabulary for it and that might include things like using the word test and defect or issue and use their issue management system, all of those things. Also does it intersect? Well, I picked on these three manifesto items of working software is the primary measure of progress. So if my data is wrong, it might be fast and the software might work. But if my data is wrong, I'm going to use this against the team and say that our project is not working because the data is wrong or you're using the wrong data or you're not protecting the data or you're going to send the CIO to jail. All of that is part of working software and if they don't agree with it, we can go to the CIO and ask them is working software include the definition of keeping you out of jail, just let us know and we'll adjust our process. Technical excellence and good design enhances agility. I've used that one a lot. We need to reflect on what's working, what's not, and make adjustments. That's how I get my involvement in split planning off in several sprints ahead. But you're going to find obstacles along the way. Kamie, you've run into obstacles before, right? Yeah, that's about every time I do something. But people want to do, I mean people are being rewarded and compensated, measured and punished for doing things fast and a lot of stuff we're talking about, yes, it's going to be perceived as slowing them down but really we're trying to get them to not have to do rework or not have to log a bunch of defects. That's my pitch to them. And there are these extensions to agile which may or may not be true. One of them is that you can't have anyone who's got a title with administrator architect or manager anywhere near the project team. And that might work if you're building your own next big Facebook. It doesn't work well on enterprise systems. Test driven development, part of most of these, I absolutely love it and adore it. It means doing testing often, like every single 15 minutes and every single change and I use test driven development even for my data models and databases. Those four letter acronyms there is no big modeling up front or no big design up front. That's true. All of these things don't have you do the entire data model and the entire design for the entire project before you even start coding. But many people interpret it to mean not doing any modeling and not doing any of those things which is wrong. Paired programming, also a feature of it. I tell people I do paired programming with data stuff not at the tool level but at the white board level and then there's blocking and I will render this example of not supporting data governance. There are people who believe including the author of this that you should fit to management and say that you've done things, say that you're following a process, fabricate tests, fabricate test results so you can get around the pain of dealing with paper pushers and it's so hard to deal with that he recommends that you make it a revolving role on the project so that people, so that not one person has to deal with these horrible data governance data model or data steward people. The first time I had this happen on one of my projects, our chief data governance officer was also someone who reported directly to the CIO and funny enough she backed me up on why that was no longer going to be a process project. So for data governance in lean, I think bringing models to the table is lean. It eliminates waste, you're not duplicating steps, I think bringing all the great metadata we have to a project is lean, but forcing lean projects to implement an entire data model or every single feature in it may not be lean. Now by the end or by a certain delivery date of a project, yes, but we can't waterfall like things on top of a lean project because the goal of lean is fast and efficient much like agile. I think our data governance programs, the deployment of them should follow a lean process. So rather than take two months to put together your strategy and another two months to do each of the phases and then say going forward, starting today, every project, every step, every task we have to move on and implement data governance in your project, I think all work will stop, a lot of people will leave, a lot of processes will fall over, a lot of projects will be delayed, incur a bunch of costs and someone will come along four months later and cancel the data governance process. Finding the right metrics to report because lean and all these are about measuring the effectiveness of your processes and tools, finding the right ones is key, and lean isn't just an excuse for sloppiness or lack of compliance. And then MVP, this was the hardest one for me to tag in because it really depends on what minimal ends up being in the minimal viable product. For a data person, if all they're doing is collecting first name, last name and email address, we can give them the one and a half tables and maybe that's our only role and we can make sure if we have a requirement to encrypt that data or protect that data or allow people to change it or whatever it is that we have to do, we can help them decide what minimal is. If it's a much bigger thing than maybe we have more. I imagine most of our roles would be for compliance monitoring, data quality sure, but compliance, keeping people out of jail. But I said before, I don't think it's typically an enterprise method, although at a couple of data meetings I've been to recently, people have asked me, we're going all minimum viable product, and I said good luck with your tax system. So your 10 tips, you should learn about them, not avoid them, you've already got a good start because you're in this webinar. You should actually request to get training on these things and you should request to go on the training because it's not enough to just know these buzzwords and manifesto level stuff, you need to know how the manifestos and how the principles are actually being going to be implemented. You should learn all their lingo, you should use it, you should be able to describe data modeling and data governance in context of these methods. You should try to get sprints or phases or releases ahead. You should be able to bring models to the team, not just tell them, okay, it's going to take us six months to develop them, and you shouldn't back off even if they're initially hostile because they've likely been to a course where they have been told all data modeling is evil, all documentation is evil, data governance is a bad word, you don't back off from it, but you should also not be a roadblock to the teams. So then the final tip is I think we in the data production should use, consider these methods for our own deliverables. I mean a lot of the fragile projects that go on, even the data modeling team has no policies and procedures, they don't use test-driven development, they don't have an issue management system for putting things that they'd like to do or cut out a scope for the data models, backlogging and parking lauding and all those other terms, that we should get much better at continuous delivery and being part of a DevOps process to deliver our DDL and our data models and all the other deliverables we have, we should consider eliminating waste from our processes. Like we should literally go leanify all of our stuff and that we should figure out if we're doing something new, what's the minimum viable product for that. So before I go here, I'm just going to take a look through the questions. Tammy, did you have any questions or insights or stories? So I worked on some agile projects as the data person and you're right, they don't like you. Getting that training is also important because now you understand what they're trying to tell you that they're talking about, right? At least you have a leg to stand on. So it is kind of nice that you now are on the same page. Yeah. And I've had the fight to get on the training before because it doesn't have anything to do with data. I'm like, oh, your system is not going to have any data. You're not going to use any databases. Yeah. Well, then the data person should be on this, right? I like this don't call bad data crap because crap can be put composted into something good. That's really great. Thanks, John. I did. I love that one. I may have to retweet that one. But if modeling is data governance, doesn't that have to be actually first? Well, all of the modeling has to be done when you do data governance. Although most data governance programs, in order to write your strategies and come up with your data quality rules, you need to know about your data. So some type of modeling happens. But that might be a completely different type of data modeling than, say, the physical database design or data store design that happens on a project. It might be conceptual or logical modeling. Which then, because that's not software, would be outside a lot of these methods. Yep. And data governance is like security. It has levels, definitely. So there is no one method called data governance. I tried to use the word data governance programs and frameworks when I talked about all these. Not see the role of product owner. So product owner, that depends on if you're doing software as a service or developing a software product, then the product owner, that term sometimes is the same as business person because your business people, if you're building software to sell or rent or whatever, you're in the customers and you might not even know who they are yet. But even inside enterprises, we have product owners for software projects. And that's definitely the person that, like a team leader or project manager, helps everyone on the team find the right balance between governance and performance and agile development. And that's all part of the planning, negotiating and collaborating and also reflecting the fact that we're all getting compensated to do things that might conflict with each other. So making data run fast sometimes conflicts with making the data have high quality. Or getting software out the door fast sometimes has a natural conflict with getting the data right. And so you find that right balance. Yes, many levels of abstraction and modeling and detail. And yeah, I like the more cowbell too. So it looks like a lot of the questions in the Q and A were about everything I predicted they would be. Yes, you will get the slide deck probably on Monday. Yes, there will be a recording probably on Monday. Although Monday is a holiday here, so maybe not. No, I promise Shannon I'll get it to her. And we're three minutes over. But usually what we do now is go on into the webinar but we stay on to have some other discussions. So Shannon, over to you. Thank you Karen and thank you Tamara for joining us this month. Such a pleasure to have you with us. And thanks to Adira for sponsoring today's webinar. Yes, always to them. And thanks to of course as always to our attendees for being so engaged in everything we do. We just love the chat when it's on fire like that. So here I go stopping the recording.