Trust as a Basis For an Agile Mindset
Christopher Eaddy
Psychologist, Author, Trusted Advisor, Hypnotherapist, Team building, Business Strategist
We’ve finally gotten to the root cause of what allows some companies to excel and others to struggle and even “fail into non-existence.” It is often not the techniques of production, sales, or product line. Moreover, the thinking that pervades the culture and the ability to change that thinking without disruption appears to be the key to the door of business success. The ability to respond to customer demands and changing marketing conditions is the backbone for being and staying relevant in almost every industry. The Agile Mindset may not be the holy grail in all industries where some companies reach high performance levels but it notable that the ideas that undergird it are beneficial for every individual.
*Agile Mindset: An agile mindset is about creating and responding to change in uncertain and turbulent environments. It's about thinking through how you can understand what's going on in the environment, identify what uncertainty you're facing and figure out how to adapt as you proceed (SmartInsights 2019)
Food For Thought: If this mindset is the key, then why have we continued to challenge and change management styles, rave about new research showing different ways to engage personality types and group dynamics, or even promote proven “old” philosophies with new twists as a way to invigorate personality or group synchronicity? Perhaps, we should spend our time getting to know the core element of what makes companies great and what keeps them great. (Adaptation and Constant and Never-ending Improvements CANI)
And by the way, I am not saying or promoting in this writing that any or all of the methods, practices and systems changes, projected by any other author or “thinker” is valueless – I am simply proposing that if we are to help our companies stay solvent and profitable, then we have to start at the core or root cause of the conditions that cause inflexibility and failure without learning. We must look at what improves business agility and business capabilities.
It seems that to get to a place of success and sustainability there must be an endemic philosophy of belief and direction in any group dynamic. This dynamic allows employees at all levels to rally around and carry the “flag” forward as a unified entity. This unity should be based on how leaders, responsible for building culture, initiate and sustain the kind of ecosystem in a company or group where people buy into the culture and it accelerates them toward success.
Proposal: Trust and Flexibility.
To get to this kind of culture, I propose Trust as the critical element for any team and particularly software development teams. This includes almost every company or will, as every company even if they have not already realized it, will become a software company in the near future (at the least they will be dependent on a software company). As a result, whether your company develops software or has teams that rely on it, or even teams that produce products or provide services- Trust amongst the members of the teams and their ability to be flexible will determine team, unit and organizational success.
I had once learned from a forward-thinking motivational speaker that everything “rises and falls on leadership”, and I still believe that the philosophy is rooted in the right place, but I am no longer beholden to that way of thinking. I have noticed over several decades that in most cases leaders are an important part of business capability and that trust and flexibility are more important. (Leaders at all levels can be replaced- Trust and Flexibility cannot). Interestingly, as I propose this line of thought I would also offer that these characteristics may remain as foundational to any company’s success now, as they will in the near and distant future. They are immutable.
From a technology perspective I think this notion and foundation of trust and flexibility is the make or break way of existing as a company. Henry Ford (the father of the American automobile industry) once said, “Be ready to revise any system, scrap any method, abandon any theory if the success of the ‘job’ requires it.” He was able to do this several times and his people still followed his lead to being able to produce a car in 93 minutes versus 12 days as they had in the past. He also stated, “Businesses that grow by development and improvement never die.” These two statements are benchmarks of Trust and Flexibility
It seems reasonable to assert that trust as an isolated factor is either based on some behavior that triggers belief or it is based on consistency. Here, expectations create the same paradigm associated with habits (where we simply expect on autopilot and often unconsciously something to occur). This ultimately leads to a relaxed sense of expected outputs aligned with behaviors.
So, how does the framework of agility related to software development increase trust in organizations and teams or is it the opposite; is trust fundamental to developing an Agile Mindset? Perhaps the methodology or practices are what creates the environment of trust; so, how does trust in this way help to stabilize the Agile Mindset?
In as brief a writing as I can, I will answer both questions so that we have an understanding of how to create trust and then allow that to undergird our Agile Mindset or enhance it.
Shortly after the agile manifesto was created in the early 1990’s people, as happens with all new ways of thinking, suffered the gauntlet of resistance, disapproval and fault-finding with the Manifesto and it continues today. In the late 1990’s one study looked at Trust in Agile environments and I will draw upon some of the salient points to help clarify the answers.
Organizations aspiring to be (versus doing) Agile, who want to employ many different agile techniques or practices to function in improved ways need to understand what is required to develop and maximize the mindset once it is established. If as I have mentioned, trust is based on either behavior or consistency we will get to see it in both realms as we delve further.
First, I want to acknowledge that there is a plethora of data and studies that examine trust in software development ecosystems, however few have examined trust in an agile context with even less focus on how specific agile practices may contribute to trust. So, we will briefly look at Trust as a Behavior and Trust as Consistency and contrast them to the findings of this study as it was done in an Agile environment, looking at teams.
Trust as a Behavior / Trust as Consistency
There is the myth that says we cannot regain trust once it is “lost” In reality, we can always do something to rebuild or even renew trust. Trust is measurable and thus we assert value to its measured results and because it can be created or destroyed, we can and do adjust our feelings and opinions about trust quite often.
When we speak about Trust as a behavior we have to consider several factors.
1. Credibility. This speaks to our confidence in and our commitment to something. The factors that influence credibility are a. Integrity - Walk the talk (especially when no one is looking) b. Intent- Motive/agenda/being genuine c. Capabilities- Abilities/knowledge d. Results - Track record/Consistency.)
2. Behavior itself. This is the trust account that we share with other people. It quickly refers to the function of credibility but is actionable based on principles. Typically, these actions include straight talk, transparency, righting wrongs, showing loyalty, being respectful, courage in confronting reality and being accountable.
The intent of the study was to examine how three agile practices, - the daily stand-up, iteration (sprint) planning and iteration(sprint) retrospective - support and facilitate trust in agile teams. It was based on the hypothesis that trust could be developed by engaging in certain agile methodological practices. The result of the findings revealed that while factors such as environmental conditions and personal characteristics of team members must be considered, agile practices can also contribute to building trust among teams and even its broader members. The study also revealed that a deficiency in at least these three practices can highlight the existence of a lack of trust.
For clarity, using the word practices in this context implies a “common way of acting”, which is accepted by a group of individuals as the “correct way to do things” and generally agreed upon by the group.
The objective of this study was to explore how trust amongst agile team members in an organization can develop and be nurtured as a result of using agile practices. Assumedly this in turn would lead to the development of positive team outcomes such as fostering better relationships/cohesiveness amongst team members or improved team performance. Previous studies highlighted the importance of trust in agile teams (Das and Teng, 2001; Mayer, Davis and Schoorman, 1995; Nerur et al., 2005, Arten, 2017), but little has been said about how the use of agile practices can increase or decrease trust among team members, which is the motivation for this research. This particular study was selected amongst many for several reasons.
1. Based on the structure of the study, I would deem it scientifically sound, suggesting the results would be valid and reliable and 2. It found other factors that were not specifically focused upon but noticed as a result of the study.
PRACTICES IN BRIEF
Scrum Influenced Practices
The Daily Stand-Up The daily stand-up is a short daily status team meeting lasting a maximum of 15 minutes typically conducted at the same time each day. The meeting is conducted with team members explaining briefly 1. What they accomplished since the previous meeting 2. What will be completed by the next meeting 3. They indicate any impediments that may prevent them from completing these tasks.
Iteration (Sprint) Planning The iteration planning session is a meeting that takes place at the start of each iteration where the team collectively defines and plans tasks that must be completed during the upcoming iteration.
Iteration (Sprint) Retrospective An iteration retrospective is a meeting that is held at the end of each iteration where the team reflects on what went well in the iteration, what did not, and what could be improved for future iterations.
*Teams are groups of individuals that collaborate, are dependent upon one another and have one or more tasks to perform in order to accomplish various team goals
The Issue of Trust
Trust has been studied in many different contexts, yet there is little agreement on a single definition with the term used in so many-different-ways. An example of trust was presented by Lewicki (1998) who stated that “trust is the confident positive expectations regarding another’s’ conduct (words, actions and decisions)”. A second definition by McKnight et al. (2014) defined trust to mean, “one party believes in, and is willing to depend on, another party”, which is of great importance in an environment where individuals must interact and work together to fulfil a common goal. Trust, or a lack of trust, can exist between individuals, groups and organizations with trust fostering cooperation amongst parties and a lack of trust causing suspicion or a lack of confidence in other parties (Armstrong, 2019).
Individuals with different personality types, experiences and cultural backgrounds vary in tendency to how likely they are to trust others, with levels of trust evolving or eroding over time as they interact with each other and observe each other (Mayer et al., 1995, Das and Teng, 2001). Distributed teams face other challenges such as lack of control, lack of cultural understanding, miscommunication, limited opportunity to communicate orally due to time differences and lack of team morale and maladjustments to change, etc.
Team members that collaborate and trust each other are imperative for the success of any agile work in organizations. This issue when examined showed that no matter the team challenge or ease of the work, some developers found it difficult to collaborate easily as a result of being used to working predominantly on their own (Nerur et al., 2005). Individuals or teams must believe that:
? Each individual within the team has the ability, knowledge, and competence to complete the tasks required ? They must also have high personal and moral integrity. ? It was also found that trust between team members and management often was difficult to establish for two reasons.
o Managers did agile things but were not committed to the mindset
o Some managers would not allow the teams to become self-governing and organized as they tended to micro-manage the teams.
Therefore, it is just as important to maintain and strengthen organizational trust as well as the trust between team members. It may take some time and effort for an organization to build a culture of trust amongst team members, however it is possible that this may be facilitated and supported by using agile practices. This led to the research question: if teams are to be self-managed and yet sufficient to effectively communicate with stakeholders, can they in fact learn to trust by using agile practices.
Teams interacting with one voice, interacting with stakeholders and representing their own interests (as a team), must know that it is urgent and important that they develop trust between themselves and their management. In current circles this is known as training up to and through management, so that, as the teams build trust they learn to trust the organization and the organization learns to trust them. So how does agile practices contribute to building trust in agile software development teams and can this type of trust be the basis for having an Agile Mindset?
The Results Are In
Anecdotal: “The team looks out for each other and makes sure that when some- thing goes wrong…it is very much a team effort to fix it.” And so, I focused on this anecdotal as I think it represents the Agile Mindset needed for teams to succeed. If things go wrong, then failing and LEARNING become prominent and the team works to fix the issue allowing all to learn from the undesirable outcome; All the while being adaptable enough to shift towards correction versus continuing to develop in isolation. This is clear indication that there are open minds that are flexible and consistent to have built that trust.
The findings also revealed that:
1. All team members on the three teams examined, believed that their colleagues are competent and can complete the tasks allocated to them.
2. Individuals working on designated tasks learn better ways to do the work. This expertise allows team members to trust their colleagues in that they all know close to the same things and can help each other.
3. Members of the team believe their colleagues are honest about their estimation of the work as they are familiar with the effort towards tasks themselves and can relate to the voice of their teammates.
4. They completely believe that when their teammates say a task is done according to the acceptance criteria, it is done.
5. Also, they found that when teams developed an Agile Mindset where being agile was part of the way they worked, (based on using agile practices), their managers did not micro-manage them for long and most allowed them to: a. estimate independently b. deliver independently c. make decisions on their own when it affected the team.
6. Lastly, it was found that managers who were not amenable to letting their teams develop and help them grow were not trusted and in some cases before the end of the study, were removed from those positions as managers.
In the end based on the study, researchers could not say that using agile practices was the only factor in creating trust. What they did conclude was that by using them when teams demonstrated consistency and demonstrated behaviors equal to expectations – trust improved amongst team members and managers too.
It can easily be surmised from at least this limited study that by using Agile practices you may be able to enhance trust amongst people in the organization and with teams. This does have implications for the initial thought of Trust as a basis for an Agile Mindset. Agile practices can lead to Trust and perhaps we have seen a glimpse of a future research topic, one that implies that behavior – “being a certain way or behaving a certain way” may yield the same level of results as Consistency does when it relates to building trust.
Conclusively, we can say yes “doing agile things” might lead to an Agile Mindset but many of us have our reservations and the studies do not prove this irrefutably. What we can conclude is that if a team or an organization understands the Agile Mindset and has the propensity for flexibility, they can enhance their Agile Mindset. Trust in the organization that allows teams and individuals to experiment (knowing that if the product or service does not come out as planned, it will get fixed as a priority) is tantamount to success. This leads to the behavioral aspect of trust which is the demonstrative nature of expectations; for both the team with each other and the org/stakeholders, as well as by the stakeholders and managers towards the teams. In either case the agility framework almost in a “social engineering way” can enhance and increase trust levels amongst teams and in organizations.
|Trust: As agreat basis for an enhanced Agile Mindset.
On the other hand, we cannot say conclusively that trust is absolutely necessary for an Agile Mindset to exist. What we can say is that if trust is present then it will be easier to use agile practices because of a first nature perspective; that is to say, I am being agile, so when we use agile practices we are creating a more trustworthy ecosystem to work in. What this also implies is that we can use (by way of choice), trust on a personal level or inside of an organization to build, grow and stabilize an Agile Mindset.
Technology Leader, Architect, and Builder of solutions enjoyed by millions
3 年I'll file this comment under a headline of "Look inward before looking outward." I definitely enjoyed the article and the comments about trust in others. Your approach is that it is important to trust others around you, teammates, managers, executives, etc. and that way, the organization can benefit from an agile mindset. It is exactly what most companies are after. However, I think that there is another element of Trust that gets overlooked and probably should get an article on its own: trust in yourself. I believe that lack of flexibility in approach is sometimes rooted in people looking to their managers for their support and guidance. However, I think that much of the problem in today's environment, especially in larger organizations where people have had high tenure and relative stability, is that they do not trust in their own abilities to learn new approaches. They also fear that by changing an approach that they, themselves, advocated for previously, may be a sign of their own lack of capabilities, where some of their peers will say "I told you so" or, worse, "I told EVERYONE so, just not you, because I didn't think you would listen." I think the root of the issue is a false certainty, often from top-down, that anybody really knows what the future will hold. This sort of thinking compels us to try and forecast 3-5 years from now, calling for "targeted architecture" or standardization on long-term investments in technology or approach. This will limit an organization's ability to stay nimble and adapt in the way you addressed in your article. It is exactly the point of the Ford quote: "Be ready to?revise any system,?scrap any method, abandon?any theory?if the success of the ‘job’ requires it." Ford's world was glacial in speed compared to today's challenging marketplace, so I wonder whether Ford would update his quote to put more of a short-term emphasis on how fast companies really need to change. A startup would call this flexibility a "pivot" and investors and customers often praise them for their maturity and fearlessness, usually resulting in tremendous growth or at least a rapid understanding of whether a market or a product is truly what they thought it was. However, sometimes a large corporation would call this flexibility a "miss" or a "failure in long-term planning" and is often career limiting if you get it wrong... after all, making a wrong decision means you were wrong when you made it, and that means you made a mistake, and mistakes mean you are personally deficient in some way, and being personally deficient is impossible for any of us to really accept. Reams of books have been written about it and we see it every day on TV in all walks of life when reality distortion fields and spin is common practice to mold a world to fit the decisions made at the time. So, before trusting others, I believe that you need to trust yourself. You need to have confidence in your ability to make the right decisions at the time, and re-make those decisions (preferably quickly) if you discover you zigged when you should have zagged. You need to personally commit to learn as much as you can about technology, finance, marketing, whatever it is you need to know to make better decisions. You need to avoid self-serving bias to try and rationalize bad decisions when you should be working hard with your team to pivot and make the right ones. You need to be honest and transparent with your team and model the behavior that everyone claims they want in others. You need to have an agile mindset before you ask your team to have one. And that is a fact... Trust me. ;)
PKT @ProKanban.org, PST @Scrum.org, Agile Leadership Mentor/Coach/Guide, Agile Coach@SAP, Psychological Safety Coach, SAFe SPC 6.0 (23xTE), Scrum.org(x13), SAFe LPM?, RTE?, SDP?, COKRP1&2, DevOpsInstitute(x5)
3 年Christopher Eaddy lovely post ??! Thanks for sharing your wisdom. ??
SAP and AI Architect, Engineering Leader, and Team Growth Enthusiast - Building the Future with Passion and Purpose
3 年Thanks Chris - you just made me adjust my keynote to reference this nice write up ??:) - thanks for putting this together , was really a good read