1. Start with Conversations, Not Just Catalogs

Too often, data governance begins with inventorying assets—creating a catalog of tables, fields, and sources. While knowing what data you have is important, it misses the point if you don’t also understand how people actually use that data. The most effective data governance efforts I’ve seen start by sitting down with analysts, engineers, and business stakeholders to ask: What data do you trust? What keeps you up at night? Where do you waste time chasing down answers?

Example: At a manufacturing client, we discovered that the finance team didn’t trust the sales forecast data—not because it was inaccurate, but because they couldn’t see how it was calculated. By opening up the calculation logic and inviting finance to co-design the governance rules around assumptions and refresh cycles, trust increased dramatically. The catalog was useful, but the conversation was transformative.

2. Make Policies Human-Readable (and Human-Centered)

Governance documents often read like legal contracts—dense, intimidating, and full of « shalls » and « must-nots. » If people can’t understand the rules, they can’t follow them, and they certainly won’t feel ownership over them. Good governance translates policy into plain language, with clear examples of what it looks like in practice.

Example: Instead of a policy stating « Data shall be classified according to sensitivity levels, » we created a simple guide with pictures and scenarios: « If your data contains customer names and purchase history, treat it like a locked file cabinet—only share with those who need it, and always lock it when you’re away from your desk. » We posted these guides in team spaces and saw a noticeable drop in accidental data exposure.

3. Embrace Transparency as a Two-Way Street

Transparency isn’t just about making data lineage visible or publishing quality metrics. It’s about creating feedback loops where people can question, challenge, and improve the governance itself. When people see that their input leads to real changes, they become advocates rather than reluctant compliance subjects.

Example: We implemented a monthly « data office hours » session where anyone could bring up concerns about data definitions, access requests, or dashboard confusion. One month, a junior analyst pointed out that our customer churn metric was being calculated differently across teams, leading to conflicting reports. We traced the discrepancy to a legacy field that no one had documented. Fixing it not only improved consistency but also gave the analyst a sense of impact—and encouraged others to speak up.

4. Celebrate the People Behind the Data

Finally, we must remember that data doesn’t appear out of thin air. It’s collected, cleaned, and maintained by real people—often working behind the scenes. Acknowledging their effort builds camaraderie and reinforces that data governance is a shared responsibility, not a policing function.

Example: Our team started a monthly « Data Hero » shout-out in our newsletter, highlighting someone who went the extra mile to improve data quality or help a colleague understand a complex dataset. It was surprising how much this simple recognition boosted morale and encouraged collaborative problem-solving across departments.

Conclusion

Data governance succeeds when it serves people, not the other way around. By leading with empathy, fostering open dialogue, and making transparency a lived practice—not just a policy—we create environments where data is trusted, understood, and put to good use. The technology is important, but the human side is what makes it work.

Next time you’re drafting a data governance framework, ask yourself: How does this help the person using this data do their job better? Start there, and the rest will follow.

L’article The Human Side of Data Governance: Building Trust Through Transparency est apparu en premier sur Studio Initiative.

1. Speak the language of business : Forget technical terms like « pipeline » or « ML model ». Focus on ROI, risk reduction, and growth opportunities. Example: « This project will reduce inventory costs by 15% » instead of « We’re optimizing the ETL ».
2. Start small with a proof of concept : Propose a limited-time, limited-budget pilot project to demonstrate value quickly. A quick win builds credibility for more ambitious initiatives.
3. Use clear, impactful visualizations : A simple dashboard with 3-4 key KPIs is worth more than a 50-page report. Use colors, trends, and clear comparisons.
4. Align with strategic goals : Show how your data project directly supports the company’s annual priorities (e.g., international expansion, cost reduction, customer satisfaction improvement).
5. Involve management from the definition : Don’t present them with a finished project. Co-create the scope with them so they take ownership from the start.

By applying these principles, you’ll transform management from passive observers into active champions of your data projects. Your role isn’t to build technology—it’s to facilitate the adoption of data solutions that create business value.

L’article How to Get Management Buy-In for Your Data Projects: 5 Proven Strategies est apparu en premier sur Studio Initiative.

We have all experienced these rituals that resemble corporate theater. The 9 AM stand-up where everyone recites their little speech. The retrospective where we stick colorful post-its only to change nothing in the end. The sprint planning that lasts three hours and results in totally fanciful estimates. We apply the Scrum guide rules with religious fervor, convinced that the methodology will save the project. Spoiler: it is not the methodology that saves projects. It is the quality of human interactions and the clarity of objectives.

The problem is that agile has become a product. Certifications that cost a fortune, frameworks that pile up, coaches selling digital transformation at a high price. As a result, we end up with teams pretending to be agile while keeping the worst aspects of waterfall. We still plan six months ahead, change our minds at the last minute, and ask teams to deliver within unrealistic deadlines. Except now we call them sprints, so it is supposed to be different. It is not different. It is just more expensive and more exhausting.

I see this regularly in data and product teams. They undergo processes designed for pure software developers, without adaptation to their reality. A data team does not work like a frontend team. Tasks are not always decouplable into homogeneous small batches. Some analyses take the time they take. Some explorations lead in unexpected directions. Forcing all of this into two-week sprints with story points is organizational masochism.

This is where Scrumban comes in. And no, it is not just a buzzword to sound modern.

Scrumban takes what really works in Scrum, namely the regularity of rituals and the visibility of work in progress, and combines it with the fluidity of Kanban. No more rigid sprints. No more mandatory estimates that make no sense. No more artificial demonstrations just to say we did a demo. Instead, we have a continuous flow, work in progress limits that prevent the team from scattering, and rituals that only exist if they bring value.

The beauty of Scrumban is its flexibility. You keep your stand-up if you need it, but you shorten it to ten minutes maximum. You keep planning, but it becomes continuous rather than calendar-based. When a task is ready, you take another one. Period. No artificial stress linked to the end of a sprint. No forced demo of a half-finished feature just because it is Friday and the sprint is ending.

For data and product teams, it is often a relief. These teams need to explore, iterate, change priorities when new data calls the analysis into question. Scrumban gives them this permission without guilt. The Kanban board remains visible, transparent to everyone. Blockages are identified quickly. But the team is no longer a slave to an artificial rhythm that does not match their actual work.

So when to choose Scrumban over pure Scrum? As soon as your work is unpredictable, exploratory, or subject to frequent interruptions. If you spend your time saying this sprint is doomed, we had an emergency, Scrumban is for you. If your tasks vary enormously in size and estimating takes longer than doing the task itself, stop torturing yourself. If your team is mature and does not need a strict framework to move forward serenely, free them from these unnecessary constraints.

Pure Scrum makes sense when you are delivering software with predictable releases, a stable roadmap, and a team that needs protection from interruptions. It is a valid tool, but it is not the only possible answer.

At the core, the real question is not Scrum or Scrumban or Kanban. The real question is: what allows this specific team to deliver value sustainably? Sometimes the answer will be Scrum. Often, for data and product teams today, it will be Scrumban. And sometimes it will be something you invent yourself, because no existing methodology perfectly matches your context.

Pragmatism is the only true agile. Everything else is just corporate religion.

And you, is your team still trapped in rituals that serve no one? What would stop you from experimenting with something else starting next week?

L’article Why Agile Has Become Corporate Theater and What to Do About It (Spoiler : Scrumban) est apparu en premier sur Studio Initiative.