Last weekend while my wife and I were finishing setting up our woodworking booth at an Indianapolis neighborhood street festival, I struck up a conversation with one of the neighbors. I’ve been replaying this conversation in my head all week.  Initially, he wanted to know if the various wood-based items that we were selling was our “day-job.” I explained that my woodworking is a hobby that pays for itself and frees my mind from my professional life as an Agile IT Project Manager.

This got the wheels turning in my head.

He explained that he is the head of a large IT department of a local financial institution. He was interested in my views on undergoing an “Agile Transformation” in larger organizations. I explained that this is the core of where I help Moser’s internal teams and external clients. 

Because I’m genuinely curious on how others approach a substantial process change, I asked about how he is approaching changing his department to be more agile. I love learning what worked, what didn’t, the tools that were used, and how the supported business adapted and adopted the results.

What he told me sounded all-too familiar and made me fear for the outcome of this transformation for this organization.

He explained that he’d read a number of articles in numerous publications about the efficacy of utilizing Agile within IT departments. He personally took the Certified Scrum Master(CSM) class to get a better understanding of the overall process. He was in the process of sending his Project Manager Professional (PMP)-Project Managers to the CSM class and had scheduled several Business Analysts to take the Agile Product Owner class. From our discussion, he clearly understood the steps and procedures of doing the Agile processes.  It also sounded like he was attempting to get people properly educated to make the transition.  However, he then proceeded to let me know that he was going to force his whole department onto teams and start to push a monthly release cadence. He said it would take very thick skin and determined efforts to move his team forward into using stories and working in sprints.

This set off numerous alarms in my head, and, a street festival where I’d been invited to participate was neither the time nor place to debate his approach. All I could think was “at this company Agile will fail, get a black eye, and be shunned because of poor transition; all because someone read a book and missed the point.” Agile doesn’t have to be an internally and organically grown from the ground up, but it definitely shouldn’t be pushed into existence on a one-sided equation.

At its core, Agile project management is about delivering value on an incremental basis back to the business. It’s also about setting reasonable expectations for both the deliverables and how people are treated. For the organization, Agile is a way to better manage the velocity of change.

The Agile Manifesto is pretty clear on the overall philosophy that should be instilled in the process:

“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”


This individual that I spoke with hasn’t internalized these key concepts so that he would give his whole organization the best chance at making the desired transition. If I could reach out to him today, I would strongly suggest that he not make the transition to Agile as it will cause unnecessary disruption to his current level of productivity.

When my Moser peers and I work with clients on finding the right elements of Agile to get them going, we often must remind them that communication, humility, constant learning, inevitable change, and new operating structures need to be created for proper organizational success. “Thick skin and determined efforts” are exactly the opposite of what it takes to delivering value on a regular basis. We tend to spend a lot of time coaching people about the differences in how an agile project will affect them. There are different processes, different mentalities, and different views on how failure is handled.  It takes time to build the momentum of success through understanding the different processes.  It is not done overnight nor with a heavy-handed approach.  

We understand that people and organizational cultures fear change and need to understand how Agile-based change will positively affect daily operations. Being able to communicate and work directly with people on both sides of the IT delivery equation is absolutely tantamount for success. It’s that communication level that drives how a true Agile process is instilled. When an organization has operated under a command-and-control hierarchy with the need-to-know communications structure, Agile can be terrifying. Openness, creativity, and a constant feedback loop are 180 degrees away from someone new or especially someone familiar (now with “training!”) coming in and telling a team how to work and what to deliver by when.

Whereas the gentleman I spoke with inferred that his organization would need a heavy-handed thick-skinned set of individuals to force this change, I would strenuously argue that they need empathetic communicators who are engaged in making certain that everyone is given the opportunity to participate and succeed on projects. At its core, Agile makes certain the individuals participating on a project have as many opportunities as possible to demonstrate their expertise with as little resistance as possible to deliver as much value as possible. Agile project leaders should be open-minded, multi-discipline-experts, and intrapreneurs. They need to be given the authority to work with the business to deliver as much high quality and valued results as the team can do in a sustainable pace. 

Successful businesses aren’t grown overnight. They take persistence, adaptation, evolution to a changing marketplace, and more than just a bit of risk tolerance. I am not aware of any businesses that jumped into existence fully formed, profitable, offering products that people love.  They all took time to get where they are today. Changing internal project management from one thought process to another should be viewed in the same light. No IT department should be expected to jump from pre-planned/traditional project management to Agile overnight. To change an organization, management will need to be persistent in their objectives. They’ll need to adapt expectations on when and how things will be done. They’ll need to evolve their own thought processes towards their staff and teams. Finally, a tolerance of risks, and even (gasp!) failing on occasion will need to be built. The organization also needs to gain the ability to learn from these failures.  Only then will they be able to create products that the business will love.

If that gentleman I spoke with does happen to see this, please get in touch with me. My peers and I would really like to help you transition to the delivery state you think you're capable of!



This is from personal professional experience. Not cited sources.
One source is embedded in article (Agile Manifesto)