A while back I stumbled across a great blog post from a guy called Greg Ferro with his musings on ITIL. It’s a very good read in its own right and can be found here.
Unusually however, the pages of discussion and comments underneath the article, arguing both for and against ITIL, contained just as much insight as the main article itself. A lot of people felt so passionate about the subject that they took the time to relay their own personal experiences in a really considered and articulate way.
This slideshow below is just a collection of some of the best comments against ITIL – I’m not trying to be balanced here. They are largely posted ‘as is’, but some comments have been combined on the same slide just to use the space wisely.
Btw, I’m not personally commenting on ITIL’s merits – but as ITIL is seemingly ubiquitous in organisations everywhere, it is rarely challenged and doesn’t seem to have a feedback loop – which is one of the reason’s I found the post and comments so interesting.
The original Joel Test is a work of genius – it allowed you to assess the quality of your development teams in under 5 minutes. By answering the yes/no questions, it steered you into thinking through each of the points and understand weak points in your process.
It was written in August 2000 (that’s before Windows XP was even released) and is still very relevant today, which suggests that a lot of IT teams are still making the same mistakes they were making 18 years ago.
I’ve heard one developer sum up the Joel Test perfectly when he said, “the beauty of the Joel Test is its simplicity vs its effectiveness”.
Just as the original did, these tests deliberately cover the basics. I have intentionally not included tests such as “are you agile?” or “do you do DevOps?” as a lot of people misunderstand these concepts and unfortunately they sometimes get thrown around as management buzz-words.
Just for the record, I have worked mainly as a data warehouse & BI developer for financial services firms in London, within IT teams ranging from 2 people to 100s; if I had spent my career working as a web developer for Facebook or Amazon then I’m sure my tests would be quite different.
Remember, Yes = 1 point. No = 0 points.
11 or 12 points
Keep doing what you’re doing
8, 9 or 10 points
Keep going but analyse where you can gain efficiencies
7 or under
Stop what you’re doing, call a team meeting and make a plan
01 – Does your team have a goal… and do all your team members know what it is?
Do your team members also know what their individual goals are and those of the company?
This is universal and applies to any team/individual and is not really about having goals – which all companies will have – it’s about whether or not they are being communicated down the layers and making sure everyone is striving for the same success.
Benefits of having clearly understood goals
Much more cohesion between teams when people pull in the same direction.
Goal-relevant activities take up a lot more of the overall effort than goal-irrelevant activities.
Managers cannot motivate teams by assigning out a series of seemingly unconnected tasks.
My experience navigating Tableau security as a novice…
I recently upgraded a Tableau 10.1 estate to Tableau 2018.1. I used the opportunity to completely rework the security from the ground up.
When starting out, much of the guidance I found on the net was focused on the many individual components that make up a Tableau estate.
While I’m certainly not claiming what I have done is best practice, I hope it will trigger some ideas and serve as a starting point for your own implementations.
This guide doesn’t cover licensing although that is something which is definitely worth understanding if you are implementing a Tableau security model. If you need to learn about Tableau licensing then this article does a great job of explaining both the old and new models.
When I joined my current employer, they had just started an informal project with 6 BI developers to deliver a host of new reports against their new data warehouse using SSRS 2016 Standard.
These are the standards I put together to try and bring some consistency to both the reports and the environments.
Like with any standards, my goal was to address the main areas whilst not being too onerous by concerning ourselves with minute details. It was also to provide a steer on items which end up being arbitrary decisions such as the names of data-sources.
Hopefully it can act as a starting point for your own organisations. I’ll look to cover the rationale behind the access model in another post.
The document, which also contains details on how to setup the project configurations can be found here.