The Hardest Thing

On our last installment, we discussed unreasonable expectations out of your team and your organization. Undertaking an Agile transition is neither easy nor convenient, though many vendors sell tools in this manner. The need for improvement, promise of speed and morale increase usually traps people into expectations that often do not match reality, and these are compounded by a lack of patience. Not only do Agile implementations take time and effort, but the CHANGE in MINDSET takes an even larger effort across multiple lines in most organizations. Not being prepared to make this commitment is one of the more common and catastrophic failure modes when a company is trying to change it’s culture.

Patience is a virtue that is almost impossible for individuals to master. In terms of organizational patience, things are all the more difficult. When an organization takes a major change and has success, one can expect books to be written, experts to be touted and those that successfully pulled off the change to move to “greener pastures”. But we rarely learn from success – failure is a much better teacher. What happens when a change of a large magnitude is attempted and only partial success is achieved? What if the thought was right – but the vision was too early to market (a common issue with Technology)?

In our application, patience has to do with a few distinct items – time for the team to understand, grow and own the change, emotional capitol required for management to change the way they see the team and other lines of business, and “regular” capitol to evaluate, train and build those key roles and people within the organization. A change in thinking is one of the most difficult things to do with an individual. Compound that to an organization, and you can see that the challenges are daunting. Let’s explore what is required in terms of time required for the team.

Most organizations that I have worked with have a team in a crisis, and this is usually the last straw before the team breaks. Not usually an ideal time to implement a major change, but sadly all too common. In the best case scenario, the team is stable but is facing an impossible project. In the worst case, the team is in flux, having lost or in the process of losing leadership or team members. In BOTH cases, this is probably the worst time to start thinking about a different way to do things – or, if the team is a good team, maybe the best. In my experience, nothing helps a team gel better than facing adversity and coming out at the end of it a better group of professionals. But the leadership and the environment have to change for this to happen. In the case of an impossible project with a stable team, it is helpful to have a timeline that allows for the team to “fake it till they make it” with a strong hand at the wheel – almost like Agile on rails. The person leading this kind of effort needs to make amends in areas of releasing responsibility to the team, while assisting them in moving forward rapidly. At the end of a few sprints, re-visiting training, having constant and useful retrospectives and REWARDING SMALL SUCCESSES is incredibly important. With this kind of support in place, just to get the team to understand the basics takes about three months at least. Because the team will have a hard time separating success and the process, as well as clarity to digest the full impact of the concepts. In point of fact, it is important for this team to experience a successful sprint, a failed sprint and a normalizing sprint in order to get the wheels of the mind in motion. It is always necessary to re-visit training after the three month mark, and to have a less urgent project to cement the practices. Each iteration in this framework introduces new concepts, and learning takes a longer time than under “normal” circumstances. Too many things are changing all at the same time.

The second scenario, a team in flux is much more difficult to manage. The basic challenge here is to mitigate the emotional challenges the team will have to work through in the process of learning a new way of doing things as well as dealing with a project or specific effort. In this case, if at all possible, it is important to minimize the complexity of the effort, so that the natural hit to performance is as separated from the Agile process as possible. The changes within the team can be welcome or unwelcome, but always result in a morale hit at first. This hit cannot be ignored, especially if we need to replace the resources that are being lost. For this type of scenario, it is important to go slowly in changes, starting with the basics and allowing the excitement and success to help bridge trust. More than anything, fear and suspicion must be overcome in these situations before trust can start to grow. As any person involved in Agile can tell you, Trust is a basic cornerstone of team building – and completely necessary to get change in place regardless of methodology or leadership style. In terms of time, the time required to get to a fear reduction will vary with each organization and team, but a coach needs to be extremely sensitive to times of emotional expression, and tempering speed of change and building of trust. It is always good to have a small defined effort so that the team can see the benefits, but dealing with less than desired outcomes in sprints need to be carefully monitored and processed. It is more important to build a team up in this circumstance than to "cross the finish line" and have a massive re-build exercise afterwards.

In order to better measure how the process is going, an organization needs to understand the timeline that it normally takes for change to occur given the specific situation it is in. In some cases, this will match a project timeline or a perceived timeline at the start of an engagement. In many cases, the time to fully transition will exceed even a large project by some amount of time. If the organization is aware of what needs to happen, and can work with a coach to map out a success plan, achieving the overall goal can be extremely feasible. But care must be taken to make sure that WHAT is being measured actually shows progress to the overall GOAL, instead of a specific effort or team. This clear definition and review of metrics not only greatly reduces noise on the engagement and hits on the vision, but can show greater results in the team or teams that are working with the coach. Remember, a change in culture usually involves much more than just a development team and the IT part of an organization! Capturing this up front means that we can bake in the change in culture at multiple fronts in the beginning, making a transition much more likely to take hold.

So, who is involved in this type of change? Why is it that a Development Team is usually the driver in innovation? Though there can be multiple reasons for this, usually organizations that have development teams have a large amount of innovation capital within the IT organization. Helping these teams to change usually results in a display of work efficiency to teams that are closely related to development, and then takes hold when most of the teams are involved in some adoption of tools or processes. Agile methodologies are NOT secluded to development, and many of the tools and processes have roots in areas OTHER than software development. So, why not help the immediate corollary organizations understand what the team is about to undertake? Why not review what kinds of thinking, leadership and collaboration changes are about to take place, and ask and help others think about how to put that in place? A good coach should actually bridge this question early on - a great coach will probably work with leaders in these other organizations early on. These departments are key to encouraging teams and groups when things go in a less than ideal direction. They can help reinforce the thought behind the exercise, and help seed the culture change at their own level, with ownership in participation and success.

The key to putting this in place is getting the right people trained in what they need to be aware of in order to get started. Too much information can kill a process change because it will give too many directions to look at. Too little information can allow for the existing inertia to stifle the effort before it begins. Working with the right amount of departments, giving a plan and the right information at the right time, and walking with the teams hand in hand always results in a good start. In addition to helping teams train in the right sequence, identifying the leadership roles that the organization currently has as well as the ones that will be needed usually helps with the on-going efforts that result from such exercises. When these people are identified, it is critical to give them not just the information they need at hand, but to actually consider getting these leaders prepared with certification training, leadership training, management training or any other tools they will need to be successful in leading the change once the coach is done. If this is not taken care of, the chances of a long lasting success are jeopardized, and the organization is held back from growing to the next logical steps. At AI, we are exclusively interested in helping our clients to learn to grow on their own, stepping in and tuning only as needed.

The last items to think about with relation to having the patience to make a change work for you is this - an organization has to make sure that the right size team is in place relative to the task at hand. Not only in terms of leadership, but in terms of actual work. This is especially true in the Technology front, but the effects of a wrong sized team reverberate across an organization. In terms of technology, more than one team may be needed depending on the size of the organization, the type of work and the kinds of projects. The need to define and identify the right people within a team is critical. For example, if a client deals with User Experience, and a project team consists of Developers and DBA's with no UX or UI experience it can make the project effort more difficult than it needs to be. In this case, getting a UX team member can help out tremendously. Knowing what is needed for the effort, and going out and staffing a team properly goes hand in hand with the changes that organizations need to make in order to be successful. It can help in many more ways than the obvious, and especially in minimizing the pain associated with having to have patience! I hope this information is positive for you, if you need help with culture change, please feel free to drop me a line.