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

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)

Business Value Metrics

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:

ROI = (Gains – Cost)/Cost

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:

FV = C x (1+r)^n

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:

PV = C / (1+r)^n

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:

NPV = -1000 + 2000/(1+r)^6 = 0

Solving further:

1000 x (1+r)^6 = 2000


1+r = (2000/1000)^?


1+r = 1.1225

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.

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

Posted on: April 25, 2016 05:26 AM | Permalink | Comments (3)

"I'm not afraid to die, I just don't want to be there when it happens."

- Woody Allen