Project Management



About this Blog


Recent Posts

The Trust Equation

Communication in Co-located & Distributed Agile Teams

Trust: The most betrayed fellow in Scrum

Good recipes to fail in Scrum

Business Value Metrics

The Trust Equation

Recently I have been reading through a very good book "The Trusted Advisor" and thought of sharing the good learnings from it.

T = (C + R + I ) /S

This is the trust equation offered by David H. Maister, Charles H. Green and Robert M. Galford in their book " The Trusted Advisor". Actually all the four parameters defined in this equation has to do with the trustworthiness of words,actions,emotions and motives.

Here T = Trustworthiness , C= credibility , R = Reliability , I = Intimacy and S= self-orientation.

Credibility of words, Reliability of actions, Intimacy of emotions and self-orientation of motives.

Trust has multiple dimensions.A person can trust someone's expertise but distrust his motives (i.e.self-orientation). Similarly a person might trust someone's brilliance but dislike his/her style of dealing with (i.e. intimacy).

As stated by the authors in the book, winning trust requires someone to do well on all four dimensions i.e. C,R,I and S.These dimensions are discussed in brief below:

Credibility :This concept includes notions of both accuracy and completeness.Thus focusing on both rational and emotional part. Rational part includes checking the facts, logic and someone's experiences to assess whether one is accurate.Completeness is assesses emotionally.Thus accurate points to "believable" and completeness points to "honesty".

Credibility requires a moderate amount of time to establish.

Reliability : It is about whether someone thinks that a person is dependable and can be trusted to behave in consistent ways.It is based on judgement and the number of times a person has had interactions with someone. Judgments can be "borrowed" from someone, as in to check if a person is reliable or not, but it also changes once a person has interacted with the someone assessed on reliability.Reliability is action oriented i.e. it links words and deeds.A very good definition of reliability explained in one word is

Reliability is the repeated experience of links between promises and actions"


Reliability is the repeated experience of expectations fulfilled".

Intimacy :The most common failure in building trust is the lack of intimacy. If you are able to freely talk with anyone about the difficult agendas then that shows intimacy. As described by author in the book

The most common failure in building trust is the lack of intimacy".


Intimacy means emotional honesty but a person also needs to be careful and cautious to know how much information could be shared and up to which extent to a particular person.

Intimacy is about the emotional closeness concerning the issues at hand".

Self-orientation : It means to be more interested in yourself. It could be anything that keeps us focused on ourselves rather than on the person or people being served.As explained by the authors ,many clues are there to identify self-orientation, enlisted are few of them:

  • A tendency to relate someone or customer stories to themselves
  • A tendency to give answers quickly
  • A need to too quickly finish their sentences
  • Closed-ended questions.
  • Passive listening

There are many other clues to identify the pattern. Now how to overcome such behavior:

  • It is advisable to talk to the customer or person as a friend, be concerned for them,their well-being.
  • Try to make their concerns your concerns.
  • Be honest about your level of interest
  • Pay attention by interacting intensely, one-on-one.

Now the above trust equation could be used to assess the customer or person relationships.A new customer and for old customer the trustworthiness will differ.This insight can then be used to get insight into why it is so and what can be done for it.

Posted on: June 11, 2019 02:12 AM | Permalink | Comments (3)

Trust: The most betrayed fellow in Scrum

Trust. This five letter word in my observation is the most sidelined and neglected in many or most of the projects running in many organizations. In my recent observations of few projects, I can see the trust put up by the customer to its epitome in the beginning and which decreased or became nil as the project progressed. This is a thought provoking situation where in the foundations of customer-vendor relationship or two-parties should be on trust but the ground reality is the opposite.

I am not proposing any solutions instead trying to put forth my observations of such scenarios occurring in the agile projects. Many of the projects using scrum or any other framework as such, haste-up to produce the end results instead and forgetting about to build up the trust with the customer or within the team. Scrum guide says “When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.”

Thus trust is being achieved via commitment, courage, focus, openness and respect. But what is happening in the current situation is that neither the teams are committed to achieve what is desired nor do the teams have the courage to upfront tell the reality to the customer or share the real picture within the team. Eventually teams lose focus in delivering the business value to the customer and to the organization and this happen when they have not understood the agile values and principles well.

If all the five values are not imbibed and lived up by the team will ultimately lead to loss of trust, either by the customer or by the organization or by the teams on themselves. Below are my few of my observations for each value.

Commitment: As I observed individuals are not committed to the team, a scenarios could be that many individuals become part of the scrum team when the sprint starts and when the sprint is in progress few of them leave or some new individuals become part of the team. All this is done without considering the effect on productivity. Also this disrupts the team harmony, team bonding, and a sense of oneness and ultimately trust is lost among the team members.

Courage: Team members lack courage to flag the impediments to either the scrum master or discuss the issues within the team. They fear to open. Also team members commit to the customer and don’t have the courage to say “no”. Many a times their “Yes” is ambiguous. Product Owner operates in a command and control way and dictate terms on how he will work. Scrum Master does not have the courage to protect its team as he fears to ruin its relation or repo with the customer or product owner. All this leads to lack of trust within the scrum team.

Focus: Sprint goal is absent thus the team loses focus on what it is building. Sprint length is increased either by the team or product owner says to the team to increase the sprint length by another week so as to complete the remaining tasks. Rather than focusing on the team, the Scrum Master is more involved in solving the issues related to billing of the resources, performing parallel procurement activities, acting as a proxy SM to other team(s). Scrum Master is thus unavailable when required by the team and the team loses trust on him. Product Owner is not having any product backlog or he is not clear how and what to prioritize in the product backlog eventually the team loses focus on what or how to build and loses trust on the PO.

Openness: Team members often work in silos by not sharing or helping others proactively. Also if one of the team member share some idea or ideas of improving something then the other team member is not open to accept or adopt it. There are many barriers of egos within the team members. They are most of the times not comfortable of sharing their own perspective thus there is very less bonding among them. This all leads to lack of trust within the team.

Respect: Within the scrum team or team there is lack of respect. The development team believes that the scrum master is someone who is just to schedule the team meetings. He is considered at times an overburden, a non-technical person who does nothing. Team thinks that as he is not coding he is not doing anything. There is a lack of understanding by the team about the role of a scrum master. Apart from this the team members also do not respect each other as there are superiority or inferiority complexes arising out because they are known by their roles such as developers, testers, release leads etc.

If the focus of the scrum team is on building trust then both the customer and the organization will be benefited. Similarly if each scrum team member is honest in sticking to these basic scrum values then I believe both the customer and the organization will achieve the desired business value and satisfaction.

Posted on: May 31, 2018 07:04 AM | Permalink | Comments (6)

Good recipes to fail in Scrum

Scrum framework is just like cooking good food, though it all come by experience but following the best practices will optimize the result and ultimately a satisfied customer. Recently I got a chance to observe few projects which said that they are following Scrum and then went on to fail and close within few months. I will say it was one of the very good experiences for the team, and a good paradigm of the adage in agile world that “Early failures are good”.

In this article I have noted down all those recipes which I observed, which can lead to a bad dish or to say dissatisfied customer, a failed project etc. I am not suggesting direct solutions instead just identifying what were the shortcomings which paved the way for a project to fail by not properly following or adopting Scrum framework.

Recipe # 1: The very first recipe to fail was that the team was not very well aware of the Scrum or Agile framework. Neither the team was initially made aware of the basic know-how of what all scrum roles, events and artifacts nor were any formal trainings provided to the team. Adding to that there was no planned budget for any of the trainings to be organized for the team.

Recipe # 2: Product Owner who is one of the important pillars of the Scrum Team, was absent for the team. There was temporary arrangement done by appointing a single person, who was the product owner of some other team to act as the product owner for few other teams. No thought was given whether the appointed PO has the technical or domain or required PO skills. Eventually the team struggled as the PO was not able to answer the queries put up by the development team.

Recipe # 3: One important observation related to PO was that he was changing the scope of the user stories in between the Sprint. No only this the acceptance criteria for the stories were also changed mid-way of the Sprint. It seemed there was a lack of ownership by the development team and also lack of clarity about the ownership of the product backlog by the PO. It happened to be more of a command and execute approach been followed by the PO and he want to dictate the terms on what and how much the development team should work. I can say here that this situation occurred as there was lack of clarity by the PO about its role and responsibilities.

Recipe # 4: The development team was not technically competent enough (there was not a good mixture of experienced team members with good technical and domain knowledge) in order to address the technical issues and thus the team lacked cross-functionality.

Recipe # 5: Development team spent a lot of time in discussing on the problems thus eating up a lot of their time during the sprint execution. Although they could have instead included one user story to research and come up with a solution.

Recipe # 6: Product owner dictated which stories to be taken up in a Sprint. There was no negotiation between the development team and the Product Owner regarding the scope of the stories. There was no buy-in by the team on which user stories they could complete within the Sprint. Ultimately the team lacked confidence and clarity on how to work on the stories.

Recipe # 7: Communication happening in silos:  product owner was not communicating to the team instead to only few members within the team. Also product owner considered SM as a technical Lead and was communicating to the Scrum Master seeking technical clarifications from him.

Recipe # 8: The development team was not having any definition of done (DoD). Neither the development team cared to write a definition of done nor the Scrum Master helped them in knowing what is DoD resulting in non-acceptance of the user stories by the Product Owner.

Recipe # 9: Sprint retrospectives were either not conducted or happening with only product owner providing its point of view, either few development team members participate in the Sprint retrospective or the participating members do not speak or share their observations.

Recipe # 10: Development team had members working in silos. They lack trust and confidence to speak up either with the product owner of with the Scrum Master for any of the impediments they face. The team just following few scrum practices for the sake. There was as disbelief by the team members in any of the scrum practices.

The most vital observation which made this recipe good to fail is that the management was less supportive of the Agile Methodologies and lacked knowledge about the Scrum framework. They still have that command and control approach which suggests that the teams should be kept well within the reins which eventually hinders the development teams to become self-organized and cross-functional. Not only this the management or the leadership team lacked faith the Agile and were merely pushing the teams to adopt agile for the sake of their customers. There was no gravity and commitment seen by the leaders to be agile instead the focus was to just do agile.

I assume such situations many of us would have seen or are observing which are happening across an organization and it requires a change driven from the top by amending the organizations culture and involving everyone in an organization.

Posted on: May 28, 2018 08:00 AM | Permalink | Comments (10)

"I am not bound to please thee with my answer."

- William Shakespeare