“…would smell as sweet,” fabled PHP developer Juliet Capulet once said.
How often do you see folks arguing, “That’s not Scrum!”, “That’s not FP!”, or “that’s not microservices!”? If you’d like more examples, I could provide you some.
I value practices and modes of thinking like Lean, Theory of Constraints, and microservices, but these aren’t goals in and of themselves. And (to my shame for trying!) I’ve never seen anyone convinced of something by saying, “That’s not Lean!”
These names are so polluted and confused anyway. Ask 5 developers what object-oriented programming is, and you’ll probably get 6 answers.
What’ll matter to you is, “Does practice X help me achieve goal Y?”
This presupposes a few things:
- You know what goal Y is
- You know the sequence of steps your org takes to deliver Y
- You can measure how long those steps take, how long work waits between steps, and how often the work is correct when it arrives at its next step
- You can for a hypothesis around how X might change those measurements
- You’re willing to follow the results to their logical conclusions
Now, please don’t take this as wishy-washy, “we don’t know anything with certainty,” and “there is nothing that applies everywhere.” I very much believe that technical practices like test-driven development and continuous delivery will make your organization more effective, in large part because adopting them will change your organization.
That said, there are extreme circumstances where they may be more pressing risks. You might look askance at someone using a dirty towel on an open wound, but what if blood is hemorrhaging so quickly that the risk of blood loss outweighs the risk of infection? You probably wouldn’t want to always operate in that kind of scenario, but it happens.
Don’t get caught up on names. Get caught up on understanding your goal and how something you do affects realizing that goal.
