Resisting Visualization

Once you visualize the work, you can improve it! I have heard this in many occasions and from prominent experts. When you visualize the work,  you actually arrive at shared visible understanding which allow actions to be logical consequence. Actions are stemmed from understanding the principles of flow, bottlenecks and the five focusing principles.

Resistance means the effect of change has started. It resembles our body resistance to the medicines which indicates our bodies are actual responding.

I came across the following specific situations which practitioners resisted visualization:

1. Visualized bug as red stickies on feature cards

Developers felt their pride is affected by exposing their defective work, specially when the feature card has the name of the developer. Testers tried to demonstrate their value-add by securing minimum number of defects. Management was expecting some defects but was not considerate to developers. Management considered testing as Quality Control instead of being part of the value stream. Management criticality towards defects created sense of attribution to developers showing defensive attitude instead of collaborating to fix defects.

The solution is up rising against the resistance by considering the following options:

  • Review and change the value stream.
  • Ask testers to go directly to the developers to fix the defects.
  • Perform root cause analysis of some of critical or periodic defects to identify process improvements instead of attribution.

2. Advanced skills user stories

Features are broken down into user stories which some of them require advanced technical skills. In one team we found that the advanced user stories can be delivered by 1 developer in a team having 6 developers. This was confrontational to many developers because we make it visible that they can work only on normal skill user stories and not the advanced ones.

Alternative options for smoothing the resistance is to provide design role to the advanced developer. This can create a design stage prior to development, which resolved the technical-design challenges so that the rest of the developers can work on advanced user stories.

3. Decompose features into smaller units each of 2 weeks length

Decomposing an epic into features and then into user stories was challenging. This specially when it came to sub-products needed to be released which are represented as epics on Inbox of the value stream. I found designers were nervous against decomposing such new sub-products because of technical dependencies, unable to estimate because of the novelty of the work, and having critical clients.

The visual board made such previously masked behavior to become obvious. Diplomacy strategies of delaying such sub-products can’t work anymore.

In positive perspective up-rising against such resistance can change organization habit of being late in releasing such sub-products.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s