Click to learn more about author Laura Madsen.
Welcome to the Dear Laura blog series! As I’ve been working to challenge the status quo on Data Governance, I get a lot of questions about how it will “really” work. I’ll be sharing these questions and answers via this DATAVERSITY® series. Last year I wrote the book Disrupting Data Governance because I firmly believe that poor Data Governance (DG) programs are getting in the way of data programs being as successful as possible.
Read the previous blogs in this series here and here.
“Dear Laura,
We’ve been “agile light” for a while across our IT teams. Data Governance started that transition with the project work we are responsible for, and, so far, it’s working out pretty well. But what keeps tripping us up is the day-to-day questions about data, Data Quality, or just general Data Governance concerns. What do we do with those?
Concerned in California”
Hello, Concerned!
I feel your pain. When I started experimenting with agile deployments of Data Governance, the tickets that came into us were like a wrench in the gears of my beautifully agile Data Governance machine, and I really didn’t like those wrenches! They mucked up the flow, and they skewed my prediction algorithms (oh, how I loved to fiddle with that thing). After a few choice words and several months of stumbling around trying to figure it out, the answer was right in front of me. The backlog. The short answer is you put them in the backlog — the long answer, since I have a few hundred words left, is this.
Take some time to create a triage methodology for the tickets that come into your Data Governance team. A simple triage method can be based on time (how much time does your team have for this sprint). The trouble with that is very few of your stakeholders are willing to sit by idly while you wait for the clock to tick two weeks. If they found an issue, they expect a resolution, and the last thing they want to hear is you don’t have the time! You can probably get away with it for a few sprints, though.
The best way to approach this is based on the data itself. Not all data is created equal. Your triage method should follow that rule. When a ticket comes in for data that is used all the time, that’s our version of priority one (P1), and you get on that! Yes, it screws with your sprint, but nothing will mess up your life more than the stakeholders that lose trust in you because you didn’t address data issues. Sprints are anticipated work, not written in stone. Make the adjustment to fix your P1 data issues. If something comes in that’s below a P1, put it in the backlog. It can be as easy as that. Of course, there are nuances; maybe it’s not a P1, but there’s a big executive meeting coming up with added pressure, or perhaps it’s at the end of a sprint, and your team has some time.
How do you determine what is a “P1”? If you have data that’s used all the time, such as customer, products, employees, vendors, suppliers (historically referred to as “master” data — I will refer to them as “primary” data), those are great candidates for P1 data issues. You can also identify reports based on the number of times they are used and prioritize those.
The point is the best part about agile is that it’s (wait for it) agile. Plan for what you can; adjust for what you can’t. I’ll admit that when I started, I had a hard time with that concept, but just like multi-linear regression, it gets easier with practice!
Do you have a question about agile Data Governance you’d like me to answer? Email me at Laura at viagurus dot com.