We’re almost a month into the New Year which means 80% of people have abandoned their resolutions. In this Inc.com article, the two main reasons include being unreasonable about your resolution, and the word resolution itself.

I didn’t have a New Year’s resolution this year, and generally haven’t for some time. It used to be because I thought it was crazy to improve something in my life once a year, but more recently it’s because forcing myself to follow a ritual for the sake of following a ritual didn’t give me any motivation to follow through with it.

As humans, we love rituals whether that’s the annual holiday party with family and friends, playing hockey on Sunday nights, or going to that awesome burger place with your buddy who lives in a different city but you still make time for a regular ritual nonetheless. We label our rituals at work meetings, and we complain about how much they suck, or how useless they are, or about having too many, but these are rituals and ceremonies that are vital to making progress in our organizations.

When it comes to making time for change, whether it’s an agile transformation, digital transformation, new system implementation or what-have-you, the urgent work usually takes precedence over the important work. As change agents, the work the organization says is important often takes a back seat, and we end up competing for people’s time and attention who are delivering products, dealing with outages, and other day-to-day activities.

This month’s LCMA theme is Finding the Right Time for Change and these stories are ideas you can try in order to make more time and space for change.

Ritual Inventory

I was working with an enterprise-sized organization that was starting a huge program that would ultimately affect most of the people working there. They wanted to figure out how to make the most of agile knowing they weren’t going to transform the whole program into an agile delivery model. Let’s leave those reasons out because a bonus tip of this article is, meet your clients where they’re at, push them when necessary to give them options, and ultimately let them decide what’s best.

One complaint was adding more meetings to schedules that were already packed because this program had so many stakeholders, decision making couldn’t happen without a large group of people. In my experience, people usually try to cram meetings into an already busy schedule because they feel they have to which means people are up earlier than normal, scheduling meetings through lunch, and working late hours to do their day job because there were too many meetings.

We designed the new rituals necessary for this program and then made a ritual inventory that listed all the meetings, the purpose of them, what decision making groups and teams that were part of the program and decided on who needed to attend each one:

Then we started taking people, teams, and decision making groups of the list unless if it wasn’t absolutely critical they attend. Some people were able to get some time in their day back, others were not, but ultimately it provided clarity of purpose.

Piggybacking Habits

No one likes dealing with IT change management, but in some organizations, especially highly regulated ones, it’s important to have solid change records for auditing purposes. In another organization, the IT change manager was constantly chasing people to cut their change records for upcoming releases.  Instead of calling another meeting, we piggybacked a 10-minute standup meeting on top of an existing program-level standup meeting.

Every Monday, Wednesday and Friday we would have 20 – 30 project managers, business managers, and directors attend a daily standup for 15-minutes to talk about any risks, issues or blockers. This organization typically did releases on weekends so when we finished our regular standup, we’d ask anyone who had a release on the weekend, or anyone who was planning to release on the upcoming weekend to stick around for 10-minutes.

We created a big visible release wall, and turned this over to the IT change manager who’d ask if there were any issues from the previous release and to make sure people were ready for the upcoming releases:

Beg, Borrow, and Steal 

The idea in this tip probably happens more than you might think. Have you ever begged a management team to get on their agenda? In one organization I was assigned to be the agile coach for a new department. Yes, someone assigned me to fix their teams and people, so I was already starting from a bad spot. I asked around and eventually found a friend of the manager who could introduce me for a quick chat over coffee.  After a brief chat, I begged her to let me have the last 10 minutes of her standing weekly team meeting to introduce myself, tell people why I was there, what I did, and the offer for help was there for those who wanted it.

While I was assigned, meaning I had to coach them, any change agent worth their salt knows you can’t force anything on anyone no matter what so I default to a pull-based stance to find the movers and people who want help. Turns out the delivery team didn’t want much help, but the way they managed their roadmap and programs needed tuning. I didn’t spend any time with the team, I ended up working with their program lead to synchronize their backend roadmap with the front-end roadmap team that was under a different directorship. Long story short, over the next year the roadmaps were merged and a couple of backend people were moved to the front-end teams to remove as much of the dependency as possible.

The lesson here is, find a similar ritual and repurpose it versus adding something new.

Sunsetting Rituals

When it comes to transformational change, we often add rituals without taking away others. This is especially true with a shift to agile. Teams are stuck doing old-world activities and then have all the new agile activities piled on top. In another enterprise organization, leadership hired an outside firm to create an agile testing process. There is a whole pile of wrong in that statement, but bear with me here!

Testers had to adhere to the new policies but still had to do all of the old world activities as well which meant there were times when they’d pull all-nighters in the name of QA. In fact, a couple of people had to go on stress leave because they were physically ill from working there. Long story short, when we had to report on how ‘agile’ was going, we told the leadership team they should be ashamed of how they treat people and we fired them as a client.

It’s a good idea to combine tip #1 with this tip. Create an inventory of rituals, including ones that are temporary, and have a plan to sunset rituals when they’ve served their purpose. Think of it this way, have you been through a renovation where major structural changes are needed? A couple of years ago we had part of a wall removed in our house. The contractor had to move some pipes and venting and told us the only way to know for sure was to crack open the wall and see what needed to be done. We agreed and his hypothesis was bang on.

They built a temporary wall to hold up the ceiling while they were re-routing the vents and pipes. That took extra time, but it was necessary. After they moved everything and had the structural engineer verify everything was groovy, they took the temporary wall down.

Other Priorities, Not “No Time”

As a change agent, I’ve always believed my primary responsibility is flexibility. When faced with the no time problem, I shift people’s language towards priorities. That is, you don’t NOT have time, you’ve chosen to prioritize other things. That leads to a dramatically different conversation about what is truly important. There will always be days when delivering is more important, I believe taking a stance of doing the simplest possible thing that maximizes impact by minimizing disruption is the best way to make time for change.

Next week our monthly members-only LCMA lean coffee is about the importance of rituals, how to create them, change them, and how to know when it’s time to sunset them.

Jason Little
Author, Lean Change Management at Leanintuit
I began my career as a web developer when Cold Fusion roamed the earth. Over the following years, I moved into management, Agile Coaching and consulting. The bumps and bruises I collected along the way helped me realize that helping organizations adopt Agile practices was less about the practices, and all about change.
In 2008 I attended an experiential learning conference (AYE) about how people experience change and since then, I’ve been writing, and speaking, all over the world about helping organizations discover more effective practices for managing organizational change.