Pirate Lessons in Analytics — Guidelines
Wisdom from the Black Pearl
I am fascinated by the world of fantasy pirates. And while I do enjoy the classics as well as some of the more grounded modern work, no pirate in film has caught my attention like Captain Jack Sparrow.
Please note that we are discussing storybook pirates, with the ships and the open seas and the freedom of being a rogue and a scoundrel and, when we feel like it, saving the day.
We’re just here to have some fun and talk about analytics.
My ship, my rules. Savvy?
Rules
Here’s where we live, mate.
I write quite a bit about Data Architecture and Data Governance. If we want to have useful insights, we need our data to be as reliable as possible. We need our processes and our results to be coherent, cohesive, and consistent.
Designing a meaningful data model requires the development and implementation of a set of processes or rules to ensure the data is consistent, reliable, and, to the extent possible, accurate.
That’s what makes it useful.
At the same time, we cannot be too rigid in our adherence to those policies. Process and standardization must facilitate development, not get in the way.
These pirates have it right. They have a strict and well defined Code.
In some situations, though, a pirate might not always follow the Code as faithfully as they would lead you to believe.
Turns out, the Code is more what you’d call guidelines.
Guidelines
This distinction comes into play quite a bit in the Pirates of the Caribbean series, and I use it fairly often in my work.
Every system has rules. Every architecture has rules.
Every project and development process has rules. So many rules…
The rules are not the key to their success. Yes, they help people learn the systems and get started. They allow us to keep order.
But there is more to it. You need to understand the principles behind the rules. The reasons that the processes are in place.
Once you understand that and see how and why the rules are in place, you have knowledge and you have power. Rather than following them by rote, you can start to apply the underlying principles and really make things happen.
And yeah. When it’s necessary, you color outside the lines.
Direction
The films play on that premise quite a bit, and not just when discussing pirate code and morality. Even Jack’s compass plays it somewhat loose.
Look at Jack’s compass. He spends an entire voyage following that compass, and Will cannot understand. As he notes to Gibbs, “It doesn’t point north”.
Gibbs has an easy reply.
“But we’re not trying to find north, are we?”
The compass was pointing directly towards the Black Pearl.
The compass was not doing what Will expected it to do, so he was willing to dismiss it. But what it was doing, pointing where it was pointing, was helping the crew get to where they needed to go.
That’s all anyone should really ask of a compass, yeah?
Agile
You want a more practical example? Good. That’s a sign of good character, or at least an indication that you’re paying attention.
Let’s talk about agile project management.
The idea is as simple as it brilliant. It has two tenets: communication and flexibility.
- Maintain strong communication. Talk to your team.
- Constantly review your progress and your priorities.
- When appropriate, redirect your efforts where they’re needed.
That’s it. That’s “agile” in a nice little package. And it works.
Now let us consider what Agile Project Management involves today.
Constant meetings. Complex scrum boards. Exhausting documentation.
I’ve been on “agile” project teams where daily stand-ups were nothing more than a series of repetitive status reports that sounded identical from one day to the next. No decisions were even considered during the meetings. Just a litany of “keep me updated” and “let me know when we can close the ticket”.
The actual work, even realigning priorities and making changes, was done “offline” (i.e., outside of the meetings designed to discuss them).
That is not agile. But it is “Agile”.
Maybe your organization does it differently. I hope so.
Conclusion
Data governance is important. No doubt. Standards are important. Even process, much as it grates me to say it, is critical to creating a well-defined and useful data architecture. Or software product.
But we’ve all been in situations where the rules are just too rigid. The processes require more effort than the tasks they are designed to facilitate. Sometimes, a different approach is necessary.
You cannot let yourself get mired in process. You’ll never accomplishment what you need to accomplish.
There will be times when you need to put down the rulebook and get the job done. On rare occasion, you need to salt the book, burn it, and toss the ashes overboard to scatter across the waves.
Don’t let process become more important than progress.
A good process or methodology should facilitate progress, not replace it. When you find yourself putting more effort into tracking the work than actually doing the work, it’s time to refocus. Be agile.
The best processes define a path to accomplishing your goals, but they leave room for improvisation, creativity, and flexibility. That requires some actual thought on your end, so be ready for it. It’s good for you.
An effective process isn’t a strict set of directives to be followed. It really is more what you’d call guidelines.
…Now bring me that horizon.
For more advice on rules and when not to apply them…
