Signatures of Distrust in Agile Teams

Trust is one of the key attributes of any successful agile team. Its lack hurts the velocity and increases the stress level in members. This, in most cases, is unsustainable. I would recommend a thesis titled, 'The role of trust in strategic alliances' (Michaela Weinhofer, June 2007. Baltic Business School, University of Kalmar, Sweden). Two simple definitions of trust from the references in the thesis are:
  • Combination of credibility, predictability, and straightforwardness, and
  • Decision to rely on another party under the condition of risk.
The cooperative relationship required to achieve a common goal can hardly ever be built with distrust. The reason I say "hardly" is because experts (referenced in the above thesis) think cooperation and trust are independent entities. The relationship may be cooperative but not productive. I would also highly recommend The SPEED of Trust: The one Thing That Changes Everything by Stephen M. R. Covey.

For an agile team, how will you know that you are in a distrustful relationship? Here are some symptoms:
  • Perpetually prioritizing new functionality over defect fixes.
  • Continuous scrutiny of velocity, deep interest in individual developer velocity, pressure to sign-up more points than velocity.
  • Questioning story estimates beyond a reasonable limit.
  • Avoiding story splits fearing 2 plus 2 won't add up to 4.
  • Comparing actual effort to estimated effort.
  • Key leadership (technical and non-technical) entrusted to non-team members
  • Attempt to pile-on stories mid iteration in the interest of getting more done.
There are many reasons contributing to above situations. It could be lack of awareness or lack of experience with Agile. But don't discount the possibility of distrust as a driver.

[ Image taken from: http://www.rockwerxclimbing.com/3292.xml ]

Guilty of a Process Diagram - Don't be, just be Smart

"Let's not get this process too heavy", "We'd prefer lightweight over the traditional heavy". Everybody has got process diagrams, even in the Agile sphere. You don't believe me? Ask any Agile manager and you'll get at least two; a defect triage process diagram and an iteration lifecycle diagram.


Replacement for Common Sense
You probably have a process diagram that you loathe and scoff at. Usually processes are proposed and adopted to replace common sense and then, even worse, compliance is monitored. If you have to have them, processes should be guidelines to remind folks of the steps and sequences in case there are doubts. The idea should be to provide support to those who need guidance; beginners or occasional troubleshooters.

Analogous to an Elevator Pitch 
Based on observation (haven't come across a research on it), I have concluded that most people prefer simple processes but fall in the trap of creating complicated ones. That calls for a couple of rules of thumb:
  • Start so simple that you void the decision box. If you are using decision boxes, chances are you are in the realm of questioning people's common sense. 
  • Expand a process area only when team members are missing the boat. If team members repeatedly fail to execute a certain step, question its need first. 
In gist, a process diagram should be a very high level happy day path free of clutter designed to handle unhappy day scenarios. An analogy for a good process diagram is to an effective elevator pitch; crisp, clear, and simple.

It is important to understand the 'why', specially if you have to innovate. And if the 'why' is clear, there's no reason you'd ever stand complicated process diagrams.

[ Image taken from: http://www.basement.org/2005/12/weird_naked_white_collar_guys.html ]

A Case for Enhancing the Agile Triangle

The Iron Triangle (Project Management Triangle) is an antithesis of Agile mindset. Jim Highsmith recognized it and proposed the Agile Triangle. It seems that the value vertex, releasable product, is still narrow in its focus. It is talking just about product/service value. It is restrictive to only customers and shareholders. How about Employee/Team Value? Or, even intermediary value focused on enhancing the core environment and sharpening the saws. For better software, we ought to think of empowerment, leadership and mentorship.


I want to make a slight modification to Jim’s triangle and add Intermediary/Internal value to the Value vertex. We just can’t ignore that anymore. That’s how continuous improvement happens. That’s when you take time out and act on retrospective tasks. That’s when functional product ownership balances itself out with technical product ownership.


An Agile approach to product delivery encompasses enabling the people and infrastructure. We just can't think at the project level anymore. We ought to start focusing on the whole organization. It is untenable to continue delivering external value without investing in internal value. The risk of not doing so is to put continuous improvement on the back burner.

A new normal, but a bad normal

In the last few years, I have been focusing on Agile Pathologies. My thesis is that as individuals we exhibit certain patterns of thinking, reacting, and politicking that usually impede Agile adoption. At times it is outright contrary to what Agility is all about. We can blame the tools, spaghetti code base, team distribution or whatever else you have, but Agile adoption is a people challenge.

A few in the industry discounted my views. Some examples:
  • "People behave in fairly predictable ways."
  • "That's within the realm of normal human response."
  • "80% of projects fail because of lack of attention upfront."
We are considered knowledge workers and supposedly can intelligently deep-dive to fix our problems. Under this misconception, we have built a culture of band-aiding the broken bones when it comes to people issues. This is the new normal, but it's a bad normal. 

With Agile manifesto, the software development community for the first time officially declared people to be more valuable. If we really believe that, we have to try hard to identify a pattern in people problems, and address their root causes. Or else the debate will not cease, “Is Agile the best way to write software, or is it the way best people choose to write software?”

Just as any good constitution or a body of law isn't of much consequence without understanding the basic principles and right execution, so is Agile. By execution, here, I mean responses to emerging problems and situations. Good Agile environments need relentless focus on improving people issues. More importantly, they require that we are hawk-eyed in spotting pathologies.

[Image taken from: http://www.zimbio.com/pictures/UXs56SKql2q/Italian+Team+Training+Session/3EfoOAs1Rqt/Marcello+Lippi ]