fiercemanage

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"

also

" 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.

Alistair Cockburn (https://agilemanifesto.org/authors.html)-- one of the signatories of the Agile Manifesto has very well described about Communication Models in Agile via his book Agile Software Development.He explained that the most effective and efficient mode of communication is face to face communication.

Although this is not always the case, and practically speaking the needs and the desire for communication for both people and the teams changes. Few of the ways explained below suggests how the needs and desires changes as per demanding situation (distributed teams):-

1.Meeting rooms-In order to desire for peace and quietness, certain sound barriers like closed meeting rooms, small or half walled cabins ensure that a person obtains peace as desired.

2.Asynchronous communication methods: methods like voice mail, email and text messages serves as asynchronous communication methods.These methods are needed in situations when a person needs time to think and act and if the person is not present all the time.

3.Written communication: like letters, forms etc. which require a person to ponder and come up with an idea or strategy or inference.

4.Telephone: Sometimes people use this type of communication in order to help them help in diluting a particular person's overly strong personality.

Co-located Team Communication :

On top of the above communication methods, Osmotic communication is suggested as one of the effective communication strategy which not only helps the teams to strongly bond together but also helps in faster resolutions of the issues.As per this communication strategy team persons who are required to communicate a lot (like developer, testers, deployment team or configuration teams etc. .There could be other combinations as well depending on the situations or project's requirements) are seated nearby. This helps them to overhear each other in their background. In this way these team members learn (mostly unconsciously) about what all issues are current or e.g. what is an urgent bug to be fixed, what is the latest priority of the customer to be worked upon. etc.Eventually the team persons overhearing can act fast on the issues.

Cone of Silence is opposite to osmotic communication. In this communication method , the team members who wants to communicate are separated form the rest of the team so that they do not disturb the other team members.This sometimes helps in increasing the productivity of the team member who needs silence to think and perform his work.

Bus length on the other hand is the communication strategy wherein people are put in closer such that they are seated at a distance less than a bus length. This communication strategy is based on the Bus-Length communication principle which states that the communication between people reduces as soon as their (walking) distance exceeds the length of a school bus.

All the above communication methods will be effective if the team(s) are co-located. Also in all the above communication methods the most common fact is face to face communication which helps in building the emotional connect among the team members which eventually leads to increased productivity or team velocity etc

Distributed Team Communication:

For distributes teams (teams which are geographically separated and by timezone): For such teams it is not practically possible to achieve face to face communication. But the teams could achieve effective communication by leveraging the potential of different communication tools like:

1. Asana for task or workflow management

2. Skype or Google hangouts or Organization provided communication channel for calls

3. Atlassian JIRA for issue and project tracking

4. Various JIRA plugins including Confluence which is a collaborative wiki tool to share knowledge effectively.

5. Yammer for discussions, knowledge sharing within the team(s).

6. A Team can also create and share small video snippets in order to explain what has been done for the day so that another team can catch-up and start working from that point.

7. Pair programming via shared machine (aka virtual co-location)

8. Aha to create product road maps.

9.Planning poker for estimation.

10. PivotalTracker for project-planning.

Find many more agile tools (including Agile communication tools) on http://www.opensourcescrum.com/

Distributed teams , however should be allowed to choose their own communication tool from a variety of options. The team should best judge it by doing and learning.The main aim in such distributed teams is frequent and effective communication.

Read this short article on remote teams

To summarize, I tried to put up communication methods for both co-located and distributed teams in Agile, also compared the advantages of different communication methods.

Agile teams inspect and adapt any particular communication strategy or methodology as per their need.

Comments and suggestions are welcome. :)

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.

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.

In Agile and Scrum, business justification is continuously verified and assessed. A project should make sense in all phases of its life cycle, and it's important to keep assessing the business value in in agile projects. It also helps in deciding whether to keep the project running or to terminate/close it. The business value of an investment is usually assessed in the financial terms.

While reading about Agile and Scrum, we run across terms such as ROI, NPV, and IRR, but we are only made acquainted with these concepts theoretically, not quantitatively. In this article I have provided a few methods by which business value is calculated. I hope they can help those of us who are working in Agile environments or projects.

The following are the quantitative methods used to determine the business value of a project:

1. Return on investment (ROI)
2. Internal rate of return (IRR)
3. Net present value (NPV)

Return on investment (ROI)

To calculate the ROI, we take the gain from an investment and subtract the cost of the investment. Then, divide the total by the cost of the investment as follows:
 

It is a simple calculation that indicates the bottom line of the return on any investment. ROI can be used as a starting point for sizing up any investment. One major factor that is not considered in an ROI calculation is time. The NPV and IRR equations below consider the time value of money.
 

Net present value (NPV)

The value of a dollar today and the value of a dollar one year from today are not the same. If the market interest rate for the year is r, then we multiply by the interest rate factor to move the cash inflow from the beginning to the end of the year. This process of moving the value or cash inflow forward is known as compounding.

The formula for calculating the future value of cash inflow:
 

where FV = Future Value, C = Cash flow, r = interest rate, and n = time.

Now suppose we want to calculate today's value of $1,000, which we expect to receive one year from today. We would have to move the cash inflow backward in time. Thus, the process of moving the cash inflow backward in time, i.e., finding the equivalent value today of a future cash inflow, is known as discounting.

The formula for calculating the present value of cash inflow:
 

where PV = Present Value, C = Cash flow, r = interest rate, and n = time.
 

Internal rate of return (IRR)

If we know the present value and cash flows of any investment opportunity, but we don't know the interest rate that equates them, the interest rate is called the internal rate of return (IRR). IRR is also the interest rate that sets the net present value of cash flow for a particular project equal to zero.

Here is an example to help you understand IRR: Suppose you have an investment opportunity that requires a $1,000 investment today that will pay off in $2,000 in six years.

In this scenario, we will need to find the interest rate (say r) at which the NPV of the investment is zero by solving the following equation:
 

Solving further:

Here r can also be called the interest rate you would need to earn on $1000 to reach a future value of $2000 in six years.

On solving the equation, we get r = 12.25.

Here, r is the IRR of this investment opportunity.

These methods are only a quantified way of calculating the business value for a project. There are various others that are not discussed in this article, which also can help in determining the business value for a project.

Reference
Berk, Jonathan and Peter DeMarzo and Ashok Thampy. Financial Management. Pearson Education, 2010.