Rather than change MAXDOP or Cost Threshold based on CXPACKET waits (especially logged by that script -- it's a bit incomplete), I'd rather look at the plan cache.
In there you can see execution plans for queries (assuming your cache isn't too volatile), whether they went parallel, and what their cost is.
That way, you're changing things based on your actual queries, and not just on aggregated numbers.
If you're not sure how to do that, start here with sp_BlitzCache (full disclosure, I'm one of the authors). We'll tell you all sorts of stuff about your plan cache from the XML in there.
EXEC dbo.sp_BlitzCache @SortOrder = 'cpu'
A generic run will get you information about your top 10 plans by CPU (though you can choose other sort orders like reads, duration, and more).
And generate overall warnings, plus some info about the age of your plan cache.
As long as your plan cache is reasonably stable, you should be able to see fairly typical plan costs.
Since you have CTFP set to 50, you may see some serial plans with a cost near but under that, and start A/B testing them for performance with parallelism. One way to do that is Trace Flag 8649.
If you see queries with a lower cost benefit from going parallel, you may want to consider dropping CTFP down to a lower number so they stand a better chance of going parallel.
Quick edit: if your plan cache isn't helpful for some reason, you should probably invest in a monitoring tool if you're serious about performance tuning this server.
Hope this helps!
