Pretty good post, but I think it is generalizing possibly a bit too much and could be misinterpreted:
1. 'ask yourself “is this going to make me deliver the product faster?”. If the answer is no, don’t do it'
While on a whole it's true, but some aspects of process (change control, QA, etc.) can:
a. make the delivery of the product go more smoothly,
b. increase the quality of the product,
c. decrease time needed to fix bugs, fix data, or eat crow after product launch, and
d. decrease chaos, confusion, and late hours spent trying to figure out what part of several issues caused some other issue.
2. 'nobody cares what tools you use'
Not true. Some shops hate (insert anything here) with a vengeance or have something in place that prohibits what you could use or how you could do something.
At the same time, I agree for the most part that users, on the whole, don't care how it is implemented.
That said, I certainly agree with the notes on Cucumber, etc. being something that seems good to the developer but that the business becomes less interested in as time goes on.
I really enjoyed doing full-on XP before with index cards, etc. Luckily we did that with our manager representing the customer. Whenever there has actually been a customer truly involved in the process directly, no matter what you do with wireframes, showing them results at end of iteration, etc., the customer (whether it be one or many) always has a personality and thought and work processes that affect the development process. You can slap Jira and workflow, etc. on it, but it doesn't matter. You have to work with the customer- there is no choice.
The shops may hate it, but if the software can be better written in a different language and the software is important for their business it doesn't matter - either they use the best or some other company does which then replaces them.
Most of the places this happens are properly already ineffective companies - which doesn't notice they aren't effective anymore and therefore gets eaten by bigger companies.
There are sometimes integration costs, though--- if the company runs almost everything on a Microsoft stack, and you deliver them something that runs on a typical Unix stack, or vice versa, it's not going to necessarily be very smooth for them, even if the actual functionality is great.
I think that is where the "best for the business" disclaimer comes in. You need to make the decision based not only on your own development efficiency but those you are impacting too.
A recent example is at my current client, quite a large company with a lot of "legacy" investment. I can't work without using git as part of my workflow any more, but I need not mandate it for this new project. Instead we stick with svn, use git-svn to give us the features we need, and bananajour for sharing code easily amongst ourselves. We've in a sense sandboxed ourselves so our preferences don't impact the infrastructure team.
As tends to happen, they eventually start to wonder what all the fuss is and want a demo of why it's cool. Now others are using git-svn too, the barrier to overcome throughout the rest of the business is rapidly decreasing.
I realise it's an easy example, but with a little creativity there is often a similar solution to most problems regarding platform/framework/etc. Not always, but often.
For the most part, I agree with this, except where people do care what tools you use for the wrong reasons. For example, a VP of Something dictates that you use DB2 just because he wants to be on the good side of IBM. Or VP of Something Else says you can't use Apache because she distrusts open source and says you have to use IIS with your Java application.
1. 'ask yourself “is this going to make me deliver the product faster?”. If the answer is no, don’t do it'
While on a whole it's true, but some aspects of process (change control, QA, etc.) can:
a. make the delivery of the product go more smoothly, b. increase the quality of the product, c. decrease time needed to fix bugs, fix data, or eat crow after product launch, and d. decrease chaos, confusion, and late hours spent trying to figure out what part of several issues caused some other issue.
2. 'nobody cares what tools you use'
Not true. Some shops hate (insert anything here) with a vengeance or have something in place that prohibits what you could use or how you could do something.
At the same time, I agree for the most part that users, on the whole, don't care how it is implemented.
That said, I certainly agree with the notes on Cucumber, etc. being something that seems good to the developer but that the business becomes less interested in as time goes on.
I really enjoyed doing full-on XP before with index cards, etc. Luckily we did that with our manager representing the customer. Whenever there has actually been a customer truly involved in the process directly, no matter what you do with wireframes, showing them results at end of iteration, etc., the customer (whether it be one or many) always has a personality and thought and work processes that affect the development process. You can slap Jira and workflow, etc. on it, but it doesn't matter. You have to work with the customer- there is no choice.