Get certified - Transform your world of work today

To Trust or Not to Trust?

That Is the Agile Question

02/04/2014 by Michael Aisley

For centuries, if not millennia, humans have struggled to introduce logic and structure into their world. From architectural designs dating back thousands of years to the latest technological innovations, we try to balance logic and the fundamental laws of physics with emotions and human attributes. Software engineering disciplines face similar challenges; they combine elements of sound engineering practices and human artistic talents to create the marvelous technological wonders that we are so fond of and can't imagine our world without. One could argue that we can't imagine any intelligent world, within our universe, without some form of computing technologies.

So, where does Agile fit into all of this? Agile was introduced as an alternate software development framework focusing on the "agility" component of system design, promising to achieve more with less. While the benefits of Agile are realistic and have been proven beneficial in the industry for years, the concept remains the easiest to explain but the hardest to implement, and to implement well. One of the underlying challenges responsible for most failures in adopting Agile -- whether on a large or small scale -- is the human psyche. Agile, in its most basic form, advocates a number of principles that are "foreign" to the human psyche and that defy human norms that we have formed over the centuries.

One of those principles is trust. And trust, in the world of Agile, comes in three different flavors:

  • Trust yourself to be able to attain the level of maturity, autonomy, and collective accountability in a work environment that is based fundamentally on transparency and a sense of shared vision.
  • Agile team members trust one another, which basically takes the first level of trust and nudges it a little higher, making it more challenging but still attainable.
  • Executive management trust developers to make the right decision as to what they can deliver, when they can deliver it, and at what level of quality.

Some of these decisions are critical in nature. Decisions include what the development teams can deliver; when it can be delivered; and how shippable "chunks" of software can be tested, validated, and deployed. Most likely, based on Agile best practices, the software will have to be reworked several times to get it right, and all while the customer is watching every step of the way.

Sounds like something that would make anyone feel a little uneasy, never mind the company executives that bear the brunt of the outcome. Looking at this approach from the executives' perspective, one can easily see their point of view and develop a sense of empathy. However, industry data and statistics seem to tell a different story. Over the past several decades, software development programs using Agile as a framework succeed, on average, three times more than those using Waterfall models. In addition, organizations that enjoyed the full support of their executive management have successfully and seamlessly transformed their entire enterprises into Agile "shops," further increasing the success rate of their software projects. Other benefits include reduced cost, increased customer satisfaction, and a higher rate of employee retention.

With all that in mind, one can't help but wonder where the human psyche went wrong in not trusting in what promotes our interest, while taking great risks in pursuing work environments that advocate unpredictable outcomes, lack of transparency, rigid frameworks that cannot respond to change, and a number of other aspects of traditional work environments that defeat our stated objectives and those of the company. The obvious question is: What will it take for executives to trust something that can only advance their corporate interest?