I’ve been to quite a few DevOps and Agile transformations, big and small. Some just want to up the coverage of their tests (not recommended!), others want to revamp their team structures, and some want to change their process.

There are other points of view as well: Many internal and external consultants who want to make a difference try changing things but end up failing for many reasons.

My advice, which I’ve learned the hard way (like anything of true value) - is to have a good “Why” in your head at all times.

“Why am I doing this?”, “What’s the point of this change?”, “What are we trying to fix by changing this?” , “What is the cost of NOT changing this?”.

You have to have a really good answer for all of these, which are just a variation of the age old “What’s your motive?” question.

Not only do you need to have a good answer, you need to fully believe that this answer is what would really drive things for the better. If you’re aiming to change something and you yourself are not sure there’s any point in doing this, or tht it could actually succeed, if you can’t even imagine a world where that success has been accomplished, a realizty where things have changed (be it a month from now or 5 years from now) - it’s going to be very difficult.

Change always has detractors and naysayers. And even though from their point of view there might be truth to their reasons for not agreeing with you, their truth should not hinder your own belief that this change is needed.

Where this “Why” comes in handy the most, for me, is when someone comes with a really good argument for “Why not”. You can’t know everything and you can bet on being surprised at some of the good reasons people give why things shouldn’t be done or cannot. Or why they think things will not succeed, or are doomed to make things worse. It’s really handy because at those dark times, where you’re even unsure in yourself that this is the right thing to do, you can come back to your original “Why”. And remind yourself why this makes sense to you. And you can use that “Why” to measure any fact you encounter, where it still holds true or not. If it no longer holds true - you might have truly discovered or learned something new and would need need to possibly change strategy or goals.

Here’s an example of “Why” that I have used:

“Developers should have fast feedback loops that enable them to move fast with confidence”.

Strategy:

• Teach about single trunk branching technique

• Teach about Feature Flags

• Help team design a new branching model that reduces amount of merges

• Help team design pipeline that triggers on each commit

• Get the pipeline to run fast, in parallel, on multiple environments

• Teach team about unit testing, TDD and integration tests

That shoudl get a team far enough on that “Why”. And here’s what happens in real life, especially in large organizations:

Every bullet point above will be challenges, cross examined, denounced as the devil, offered multiple variations that seem to be close but are not, and very few people will be able to automatically support it in many teams.

But this “Why” is what keeps my moral compass afloat. No matter what is the discussion - and especially if it becomes confusing, or goes deep into alternative suggestion land - I keep asking myself if that “Why” is being answered. And I can use it as my main reason for each one of these things, because it is absolutely true in my mind - these points help push that “Why” - and doing them in other ways might seem like it’s close but can push us farther away from it.

Always have a “Why” - and you’ll never be truly stumped, even when confusion takes over.

You could have many “Whys” - and not all of them will be in play at all times. But for each action you push for, there should be a “Why” behind it.

In my mind it reminds me a bit of TDD - any production code has a reason to exist: a failing test at some point that pointed out that this functionality is missing. Tests are the “Why” of code functionality.

In DevOps and Continuous Delivery, a big “Why” can be “We want to reduce our cycle time. “ Then from that you can derive smaller “Whys”, but they all live up to the big one, and support it.