Noted psychiatrist and author M. Scott Peck starts his first and most famous book with this simple statement. “Life is difficult.” His writing became popular because at some level everyone agrees with that statement. This fact is most true when life brings changes. Everyone faces the challenge of change differently and reacts to it in their own way. Landing somewhere on the scale of fight or flight, it is ultimately a personal journey. But this is a technology essay – isn’t it?

If your organization is undergoing a technical modernization or digital transformation[i] how your people respond to change is an often-hidden factor in the success or failure of the project. This is not a technical problem, but a problem that has huge impacts on technical approaches, project planning, and budgets.

It is tempting to limit this problem to the business side of the story. Many of us in consulting, or internal IT have run into business people who seem to never want to change. They are happy with their Casio calendar PDA, and can’t seem to work and shockingly don’t love the smartphone you offer. They appear to be luddites and fight hard against adding budget to update important systems or bring in new tools. But even modern Agile teams suffer from these problems.
How often do you see these things happen? The agile rock-star developer is great when you let him develop on his own, but in the team, he is more trouble than he is worth. One agile team is successful in a pilot project, but adding more teams and divvying up the work means that the first team seems to take steps backward and the new teams can’t seem to get it together. Or the product owner who did such a great job on the first project they were overseeing can’t seem to get her mojo back on the next project.

There are reasons why these challenges may not be technical, methodological or a miscalculation. Rather it could be the way that the individuals’ brains are processing the situation. No area of human study has exploded more in the past decade or two than our study of the human brain. Neuroscientists have been able to map how the brain processes information and our responses more than at any time in history. What they have learned is that most of our responses to stimuli are automatic and reflexive. So, I am literally not aware of what is happening but I respond nonetheless. This leads to all kinds of trouble, but there is hope. Another major finding is that our brains are more adaptable than we had understood. As a result, through careful attention we can and do change our reflective responses.

So, what does that mean for the troubled project? There is more good news, Agile ceremonies have in them some very good brain practices which enables individuals and teams to grow and adapt to change. These practices need regular re-emphasis and attention to be effective but they can work.

  1. Stand-up Meetings: This practice is so common in agile scrum that it is taken for granted. When it is, I see teams meeting in conference rooms sitting around tables. This casual approach causes our bodies to relax. The signal to our brain is that there is nothing to pay attention to. If done casually it reinforces our reflexive actions. Then when we realize that there is something different or unexpected it is perceived as a threat and “fight” or “flight” responses kick in. So, stand-up. Call the team to attention. Brain science says that what you pay attention to is what drives change in the brain. Acknowledge as a team that change is necessary. Repeat that often.
  2. Two-Week Sprint: To change our reflexive responses it takes practice. Once our attention is captured by a pattern we want to change, we need to set goals and practice. Brain science says that what you pay attention to is what drives change in the brain. Acknowledge as a team that change is necessary. Repeat that often. In the sprint planning think about what the metrics or evidence of change might be. (Perhaps it is how people respond when code is peer reviewed, perhaps it is the team adopting a mantra like “I am glad I can change”.) Then try it for two weeks. One other thing that brain science shows – and this is kinda freaky – is that when in a group one brain changes it can pull other brains along too. So being in a team working together on a practice for a dedicated time is really the best way to make change.
  3. Sprint Retrospective: Finally, the sprint retrospective is a wonderful tool for enabling change and learning. However, this is only true if the team really pays attention to everything going on. Often the retrospective is limited to tasks – how easy were they, did enough get accomplished? These are important questions. But if adaptability is to be improved, then the retrospective needs to also embrace deeper questions. The team should notice and be free to communicate how easily they adapted to stressors. Mindful practices like body scanning are useful to notice how our bodies are communicating responses to stimuli at an unconscious level. It may seem silly to have a group of people resting quietly for 15 minutes in a sprint retrospective, but the insights gained could ward off team meltdowns and project troubles.

Change is hard. All new things require creativity, openness and hard work. Fortunately, teams are a great place to make changes. I have been to a number of Agile training sessions that identify culture as an important element of any modernization transformation. What is not mentioned is how the agile ceremonies can be the source of the cultural changes. Knowing how these things effect and are effected by our brains, opens the door to change that is much more lasting and profound.

[i] Any technical change is relevant, moving from a home-grown system to a commercial-off-the-shelf (COTS) system, scaling up your systems, changing from an old technology – like mainframe, or adding new offices as you grow.

About the Author

Neal Smith, VP, Digital Services, is a proven leader and innovator and has the essential knowledge and experience to successfully build and deliver the needed services of Agile Software Development, DevOps, UX (Design Thinking), Business Process Management, and Organizational Change Management. Neal has been highly engaged in the transformation process moving into a Digital Service focus and has contributed greatly in the efforts to formulate the current strategy and direction. He is responsible for the creation and service delivery of our UX Practice and has been instrumental in the visioning, development, and implementation of the Salient CRGT DevOps Toolkit.