Going Agilish — Making the Switch Without Breaking the Place

Bringing Agile into a corporate IT environment that has not asked for it is one of the hardest things you can do in this industry. Large, well-established IT organizations have often spent years — sometimes decades — building their processes, standards, and ways of working. That history does not disappear because someone in leadership decided it was time to go Agile. And if you treat it as though it should, you are going to have a fight on your hands.

Here is the thing though. In my experience, once teams actually make the switch, most of them like it. They see the benefits quickly. They get more visibility into their own work. They feel less like cogs in a machine and more like people with real ownership over what they are building. Most will never go back. The resistance is rarely about Agile itself — it is about change. About uncertainty. About being asked to operate differently in an environment that has not changed around them.

That distinction matters, because it changes how you approach the problem.

Prescribing Agile Does Not Work

Slapping an Agile label on top of an established PMO and calling it a transformation is one of the fastest ways to make people distrust Agile before they have ever really tried it. The same goes for prescribing a framework across an entire IT organization from the top down and expecting buy-in to follow. Mandates create compliance, not commitment. And compliance without commitment falls apart at the first sign of trouble.

When that production issue hits, or that deadline slips, the people who never believed in it to begin with will point straight at the methodology. "We did not have these problems when we did things the old way." And in that moment, it does not matter how much evidence there is to the contrary — you have lost the argument, and possibly the initiative.

The Agilish Approach

This is the core of what I call being Agilish. You practice Agile values and principles from day one, but you introduce Agile methods gradually, within the constraints of the environment you are actually in — not the one you wish you were in. You train and hire key advocates who can help carry the message. You bring people up to speed one step at a time. You show the value before you ask for the commitment.

Most importantly, you get started. The conditions for a perfect Agile implementation will never all exist at once. Waiting for them to does not make the ground more fertile — it just burns time.

Start small. Pick a team, a project, a problem worth solving. Do the work. Show what is possible. When the results speak for themselves, you will not need to sell Agile to anyone. People will come looking for it.

That momentum — teams pulling Agile into their work because they want it, not because they were told to — is what real adoption looks like. It is self-sustaining. It does not need a mandate because it has something better: evidence.

Make the switch to Agile in an Agilish way. One project at a time, within the real constraints of the environment you are working in. That is not a compromise. That is the strategy.