Pull vs Push Approach to Change

“We used to do personas and UX before you guys came in and told us to do Kanban”

As ridiculous as that sounds to some of you (me included) think of the perspective of people new to Agile/Lean and who are learning this new process all the while doing their day jobs.

I remember many years ago asking my CSM trainer if we should be estimating bugs. I was new to scrum and didn’t know any different. Saying that nowadays is likely to get me thrown out of the Agile club, and I might even get my secret decider ring taken away.

An interesting point about the quote I opened this post with is that it tells me this person has elevated out of Shu (apprentice) and is ready to transition to Ha (journeyman).

Push techniques can be valuable when an organization doesn’t know what they don’t know. Push until you’ve crossed the line and wait for the push back, that’s a signal coming from the system that it’s starting to understand and think about what’s going on. That means questioning tactics, questioning the use of some processes and techniques. As stressful as it can be at times, it’s a good thing.

Looking at the Satir change model, people don’t learn if you drag them through chaos, they learn by working through it and sometimes that sucks, especially for me. It’s hard for me (as and Artisan, SP or helper) to let people thrash in chaos until they’ve hit the transforming idea.

This won’t always work, obviously, but as you dance with the system, sometimes you need to step on its toes to provoke chaos every once in a while, yet also recognize when they’ve hit the transforming idea so you can start pulling.