Funny Fact of Change

We always resist change when it comes to our lives. But when we seek it out, we are happy with the results.

Be it an organization or team restructuring, a new face of life (new location, new house), we tend to attach it with us if we seek it out or are in drivers seat. If it is done at behest, we tend to squirm and wiggle uncomfortably to move and adapt. In these zones, we tend to be on our own to seek the change.

This paradigm taught me few lessons on how to handle change.

1. Germinate a change organically. Keep creating the need till it is felt. Try placing stories on how current situation is screwing us up. What problems needs change to make our lives better (if only some one can get it done).

2. Readying for change is important yet difficult than realizing and rolling out change: Most of us are receptors of change. We are treated as passive adopters. We are considered to switch ourselves as it is wired to react most often than act upon. This kind of works in production factory setup. However, later generations have figured out that getting unions on side of changes makes for better execution.

3. Fears rule when reflection for change: When we get an opportunity to comment on what the change means to you, we are at creative best to bring out all black hat thinking to fore. We can predict and provide for enough reasons on the pitfalls if executed.

Now, this is a good thing as opposed to labeling them as laggards or cynicists or a critic. Stereotyping is a major error of leaders and managers at highest level.

Why is it then that these are not elicited during planning phase and we rely on change as a risk to take chances on the workings of change ?

Importance of Sprint Retrospective: Distinguish between Repetitive practices vs Best practices

When you see or hear a case that seems to resonate with your past experience, we are often prejudiced to state that we have seen similar case in past and that we overcame it with a certain solution and a way. We tend to repeat that again.

This is wrong premise and is a classic case of perceptual error. Often than not, it results in a sub-optimal working condition.

It is really important to repeat only the best practice and not repeat a practice that worked earlier. This is where project retrospectives help.

Project/Sprint Retrospectives help identify as to what we did, how it worked, what are the best aspects of the practice that should be carried forward, what can be improved in the current system and then document them as a best practice. What ever worked well in a given transaction is recognized for a spot reward, but is not essentially disseminated via the global knowledge board in intranet.

email Templates is a classic example to explain best vs repetitive practices. In my projects, we first decide on the formats of email for various regular communication areas - status reporting, Budget (efforts, cost) allocation, work pull from Kanban, issues/dependencies attention, etc.What we do is decide how we would craft the subject line, how the messages will contain the key information and what are ideal time to expect these emails. This way, when ever we are in a meeting (daily standup) or my meeting with management stakeholders and clients, it is easy for search and finding the relevant emails. With the mind tuning to see the key points in familiar areas, it is easy to be efficient.

While these templates are by themselves a good practice, we have realized that the formats of emails that worked in one project needs improvization based on sprint team understanding, comfort and ease before adopting it in next project. Hence we have a best practice to have email templates, but we distinguish it and do not  repeat the formats from one project to another.

This way, we not only innovate and explore better, we develop a keen sense of intuition as to what works and what is a value-add in a given constraint, situation or culture.

Does your retrospective allow for discussion in identifying the repetitive vs best practices ?