Trust – The Real Agile Change Agent

Over the years, I have heard just about every excuse imaginable as to why someone cannot do agile. In my opinion, most of these excuses are fear based. Most people fear change. How many times have I heard, “We’ve always done it this way.” Amazingly, even when their way is not working, most people will cling to it like a drowning person to a life preserver.

Don’t get me wrong; I know change is not easy. Having been a lifeguard in my youth, I also realize how difficult it is to get someone to trust you enough that he/she will stop fighting, grab a hold of the life preserver, and let you pull him/her to shore. Most people release the life preserver rather quickly after getting to shore. Some, however, will cling to it until they can shake off their fear.

My job as a coach is not to pry the life preserver from the client’s hands. My job is to get the client to release the life preserver. As many of you know, this is not an easy task—especially when the client is afraid of being pulled under into unknown waters. In the client’s mind, the life preserver may be a sure bet. The water, on the other hand, may be full of unknown, possibly nightmarish, possibilities.

During my career, I have found that clients on the business side of the house are more willing to let go of the life preserver and tread into the unknown. Most of these clients want to be able to collect customer data and present it in such a way that a sales team can quickly perform an analysis and data scrub to determine what, if any, extra discounts and special offers they can present to their clients while on sales calls.

The technical side of the house, however, is usually another story all together. On more than one occasion, I have had teams and organizations tell me that they cannot do agile because they absolutely must identify and collect all of the data sources and data before they can even think about doing anything else. These individuals tend to cling tenaciously to the life preserver.

While I will admit there are certainly times when you may need to do all of the data mapping and gathering exercises before you start “sprinting,” I have found this to be the exception rather than the rule. As many of us have experienced, data modeling and mapping can sometimes take weeks if not months to perform—depending on more factors than I care to discuss here.

However, far too often teams and organizations will use this as an excuse not to use agile frameworks or processes. My guess is that they do not want or support the concept of breaking down silos and creating teams that consist of members that have the “right” skills to do the job. Many times, I have been unable to get a fulltime data expert on the team, so I had to have a sprint that consisted only of data mapping and gathering.

When situations like this come up, I normally meet with the Product Owner and/or key stakeholders and explain that without these resources on my team from the start there will be inevitable delays in delivering anything of business value as quickly as they desire. In my experience, I have found that most business people understand this and will pressure the IT organizations to provide the needed resources; sometimes this works and sometimes it does not.

In the end, the successful allocation of the needed resources will depend on the importance of the project to the company as well as how much political pull the Product Owner and key stakeholders have. In my opinion, it will also depend on the client’s ability to let go of the life preserver.

Delivering real business value to the client is a top priority. Convincing the client that your team requires fulltime people with special skills, such as a DBA or UX, so you can deliver slices of real value during each sprint can be difficult. In the end, it all boils down to getting the client to entertain the idea that there may be a more efficient and effective way to do things.

Trust is a key element in the process of getting the client to let go of his/her “old” way of doing things so that he/she can step into the “new” agile way of doing things. In my opinion, trust is based on integrity; so I believe this trust should be based not only on the skills of the coach but also on his/her character. As the client gets to know the coach and sees him/her working day-in-and-day-out to ensure the best possible outcome for his/her organization, his/her trust will grow.

Change is inevitable, and it is constant. The job of the coach is not to change the client. The job of the coach is to facilitate change for the client. As stated earlier, the coach’s job is not to rip the life preserver out of the client’s hands; his/her job is to make the client feel secure enough to release the life preserver, and thereby his/her organization, into the coach’s outstretched hands.