Search This Blog

Friday, May 31, 2019

Risk Management in Agile

Extending observations from one of the class I facilitated on digital project management, I was wondering how to address the impact of risk management in agile initiatives. Earlier this month, I had a family emergency and I traveled to India to meet a family member who was critically admitted to the hospital. As I discussed the medical condition of my family member with the physician, I remembered one of my earlier speeches where I had discussed the notion of of ECG waveform as the warning trigger of risk in monitoring one's health daily.

I resonated with the ECG waveform and its principles to agile approaches to project management or product development. The ECG waveform represents the heart pumping certain volume of blood every fraction of a second (varies from person to person due to many reasons). From a physiological standpoint, the P wave represents the atrial contraction pumping oxygenated blood into the ventricular chambers. The QRS wave represents the ventricular contraction denoting the rate of  blood distribution. Finally, the T wave represents the ventricular relaxation before the heart is ready for another cycle. It is therefore, no wonder, that one can think of every PQRST cycle as an iteration. The amount of blood consistently bumped represents the velocity.

Now, if this analogy true, then, we can relate to risk also in an agile iteration. When we contract work to other teams or depend on others to complete the work, the functionality of the other organs (e.g.: respiratory systems) to deliver oxygenated blood without any challenges arising from circulation is critical. It is not surprising, therefore, why project managers always relate to the risk domain when procurement domain is involved because non-delivery per contract or non-performance of contracted work leads to the risk of resource overloading.

When one doesn't take care of their personal health properly by following quality policies (such as dieting or exercise), challenges arise such as a heart attack. The same concepts apply when the team compromises on technical excellence in design or addressing quality by design principles in their workflow. The escaped defect therefore represents the heart attack or an emergency trip to the hospital.

When the team members in the team fail to work together, that leads to failure. For instance, the block within heart system causes to resistance to smooth flow. Similarly, resistance to agile practices and lack of the team's self organization introduces the risk of failure.

When the team is not self-organized or demonstrating high levels of team maturity, the scope compromises in velocity demotivates the team. Although heart is much more resilient, overwork or imbalance introduces anxiety and stress and people react differently. Similarly, lack of product vision or constant changes to iteration backlog compromises the team's ability to deliver. Many business challenges can impede the team's ability to deliver as well and become a high-performing team.

Such challenges, when go unchecked, impacts the team's ability to deliver over a longer time-frame. The emergency visits to hospital leads to a loss of trust for caretakers requiring external intervention in the form of medicines or medically recommended rest. Stakeholders can lose confidence in the team's ability to consistently deliver on the strategic product road-map when costs increase more than the benefits realized. Customer satisfaction fatigue can be seen in the voice of customer feedback and lack of adequate referrals.

In summary, I can definitely see how this simple ECG waveform that we can all relate to proves to be emphasizing how risk is pertinent to everyone's health in daily life. If every day is a project, then, every heart beat is an iteration which has the seeds of risks. The warning triggers have to be understood and appropriately managed even in an agile project.

Thoughts? Please share with me.

Tuesday, April 30, 2019

Agile Iterations also involve cost

I was recently facilitating a class on digital project management and bringing references to both agile and traditional frameworks. While the concepts of fixed scope within the time-boxing principles was readily understood, many people in the digital media class mentioned that agile projects don't involve cost or have principles of cost baseline! The students didn't resonate with risk management also in agile iterations. These misrepresentations of agile framework continue to surge and are not accurate representations of agile approaches to project management or product development.

For instance, consider that an agile team is made up of 9 team members. The product owner, agile coach or scrum master, and the development team spend time and are compensated by their performing organization. So, when these 9 members spend approximately 6 hours per day (at 75% commitment to the project), they spend 54 hours (9 members x 6 hours) per day. Considering a 10-day iteration, the team has spent 540 hours (54 x 10 days)  with one iteration. By allowing this iteration to continue with this agile approach to meet the strategic objective, the performing organization has, therefore, spent 540 hours; this time represents the opportunity cost of the organization choosing to allow these resources to work on this initiative compared to another initiative. So, how could an agile iteration not cost anything to the organization?

Let us drill a little more here. Often, people are unable to come up with the cost of an iteration. Now, this may be associated with the fact that agile doesn't favor big upfront planning. In traditional approaches to project management, we come with the WBS with the breakdown of activities worked on by specific resources and associate a resource-level pricing. It is therefore possible to come up with a cost. The similar logic can still be done in an iteration easier because agile is all about team level commitments. Instead of looking at individual resource level pricing (such as what's the hourly rate of product owner?), the agile team can work with the finance department to come up with a blended resource-loaded rate. The financial units within many organizations have such a blended rate and I have received immediate responses to my requests in my experience from the financial department for such a blended rate. Now, assuming the blended rate is $100, one can easily apply this blended rate to the 540 hours in our previous example and come up with a cost of $54,000 (540 hours x $100). So, the cost of an iteration can be found out easily.

Using other heuristics or analogous experience of delivering multiple iterations, one can also come up with a cost of a story point. Now, it must be mentioned that a few iterations should be done before we can come up with a reasonable and consistent velocity as the team matures. Assuming a median velocity of three iterations, if we hypothesize that the team has to deliver approximately 150 story points in every iteration, then, the baseline cost of $54,000 can be divided by this hypothesized 150 story points to come up with $360 ($54,000/150). When the team misses out on completing a 3-point story because of not proactively identifying and addressing the risks, managing stakeholder communication, or promoting the daily collaboration between business and technical users, then, the missed velocity in that iteration costs $1,080 ($360 x 3 story points) of non-delivered value.

By monitoring velocity delivered per iteration against this baseline projection, one can evaluate the CPI (Cost Performance Index). Again, extending the example above, the baseline projected velocity is 150 story points (with $54,000 or actual cost). When the team didn't deliver 3 user stories, the value delivered (Earned Value) is 147 story points (147 story points x $360 cost per point = $52,920). Since CPI is computed as a ratio of Earned Value/Actual Cost ($52,920/$54,000 = 0.98). This means the team is not delivering 2% of the committed value. Agile teams compute this as the Burn Rate, which is the reciprocal of CPI (1/0.98 = approximately 1.02). This burn rate represents how the agile team is meeting the projected budget and since it is >1, it indicates the team requires 2% more budget at a minimum for this iteration. Since agile uses time-boxing principles, as each iteration fails to deliver the minimum required velocity, each iteration costs more money towards the end in meeting the minimum viable product (MVP).

Hope these points are clear in explaining why and how agile projects do not exclude cost. It is critical to understand these concepts and subsequently have a plan to quantify value delivery using good return on investment principles.

Thoughts? Please share your comments.

Sunday, March 31, 2019

Feedback should be FACT driven

As the impetus for increased levels of communication is felt by organizations, the need for being able to address project failures leading to schedule slips, quality compromises, cost overruns, and scope creeps become the sine qua non for effective project managers! Is this communication effectiveness is only limited to project management? Absolutely not! Agile approaches to product development and project management also constantly seek people to communicate. Even the recent state of agile claims increased transparency has not resulted in increased software quality and some contributions come from being able to communicate.

It is true that one needs to engage in several types of communication but communication is a one-way street if there is no engagement from the audience! During corporate training as well as in classroom facilitation, I find that the lack of engagement from the audience makes it difficult for the facilitator or speaker to create a dialog around concepts. Therefore, the collaboration between two or more people is inexorably critical for communication to be effective. And, there lies the challenge in continuous engagement because people have to be open for feedback.

Recently, I heard in one training that one group (say Group A) was following agile and releasing features for the internal teams. But, many of the internal teams asked for features that this Group A claimed are already there. When asked for better communication of these updates from Group A, the response was reading the release plan documents or see the dashboard. In a world of high-tech dashboards, the need for communicating updates in the language that others understand is equally important! Otherwise, communication has failed. High-Tech is not a substitute for High-Touch and people should be open for feedback.

So, I present the FACT driven feedback as a quick check-and-balance. I am not just referring to numbers and stories in the FACT approach. Instead, I am suggesting that feedback be frequent, accurate, constructive, and timely.

  1. Frequent feedback means both parties are able to get incremental updates faster. The context of the challenge is fresh in people's memory to make corrective actions.
  2. Accurate feedback relies on evidence-based data rather than opinions. This element avoids the halo effect from colored thoughts but shifts the focus on the truth. 
  3. Constructive feedback is focusing on the actionable outcomes that the listener can implement as either proactive risk mitigation steps or corrective actions to exacerbate the problems.
  4. Timely feedback centers around the ability of the person providing the feedback to feel the sense of urgency to elevate the feedback faster than relying on status or standup meetings.

When these four elements of feedback can be learned by both parties in a dialog, then, active listening is at its best. This is when collaboration happens for communication to be efficient and efficient.


Thursday, February 28, 2019

Requirements Management: A Value Mapping Exercise

The requirement management exercise is very closely related to the needs assessment producing the required artifacts while documenting the decision-making. It is critical to understand how the value, benefit, and output get mapped in a few critical documents namely the business case, charter, roadmap, and benefits register.

In a nutshell, the business case is the first point of entry in the requirement management. In this document, the accountable stakeholders for product strategy or the business strategy justify the company’s decision to take up the strategic initiative and formally declares the benefits expected out of the initiative. This decision is supported by documenting the specific short-term and long-term benefits by executing the initiative, the extent of market research to justify the need for this initiative, the amount of funding and funding schedule required to carry out the initiative, and finally the specific measures such as the payback period, net present value, to justify return on investment and future opportunities.

When such initiatives are rolled out, these initiatives could be done as a program containing multiple projects because of the extent of management and control required to integrate the benefits gathered from carrying out this initiative as an integrated program rather than as a set of stand-alone projects. Either way, this is when the program charter or project charter is created appropriately. This document names the program or project manager confirms the decision to execute the project outlining the high-level outputs and outcomes, and the authorizes the use of the company’s resources to carry out the work.

Now whether one is developing a product roadmap or program roadmap, you can think of the roadmap as a visual, hierarchical and powerful representation of the what high-level functionalities make up that initiative, dependencies among functionalities or projects within a program, and how the product will grow over time, how to acquire the required funding to support the product or program, and how to align the various stakeholders to ensure the required benefits are realized.

Finally, the benefits register is an artifact that lists all the planned benefits expected to be delivered at various points in the releases or iterations or program and its component projects. 

Having talked about value so much, I have come up with my own way of categorizing value. I call these CVA, BVA, TVA, PVA, and NVA.

The first category is the customer value add. For instance, what does the paying customer want? And, what exciters can we add to keep the customer with us?

Then, we move to the next level of business value add. Examples could be looking at the types of documentation required to sustain the business or training needed for internal and external users.
This business value-add can also manifest as a technical value add. Here, we look at technical debt maintenance. On the hardware side, we can look at keeping the infrastructure current to avoid any risk from using any product beyond their shelf-life. On the software side, we can look at ensuring the code is stable, manageable, and scalable by refactoring the code, automating areas that could benefit from automation, etc.

Another way the business value add can manifest is on the process value add. The processes themselves should act as a catalyst for transforming the inputs to outputs but not add too much overhead. The efficiency improvements through continuous improvement and effectiveness augmentation through operational excellence become the focus here. 

If it is not the customer, business, technical, or process value add, then, most likely this leads to a non-value add. The requirements in this category are to be avoided as they are contributing to some type of waste. In lean management, we discuss the uneven demands or overburden of resources that may lead to eight types of waste. These were discussed in an earlier blog in this collection. Please check out

What are your thoughts on this blog article?

Thursday, January 31, 2019

5A Principle - A mindset about managing change

As organizations strive to increase productivity and reduce total cost of ownership, the reasons to jump on the “agile” train expecting it to solve all challenges seem to raise. Social media has scores of posts questioning agile practices. In my mind, agility is simply a “mindset about managing change”. At the end of the day, if one is truly nimble about embracing the right change at the right time the right way, then, agility should result in a) increasing value to the customer, b) increasing quality to the product, c) reducing speed to market, and d) reducing cost to operations. To achieve these goals, I propose a 5A principle to truly being ‘agile’ These 5A’s are “Awake, Arise, Adopt, Adapt, and Adept”. These stages are cyclical in nature. Let me illustrate these in the sections below. While reading this, think of the “change management framework” in mind rather than treat this as a methodology to implement agile.

Change is the only constant today. All the five competitive forces suggested by Michael Porter are a reality today.  The potential entry of new players, competitive pressures of the consumer, global market refinement and product differentiation of existing players, innovative distribution channels, and intense rivalry among competitors are making the famous economist, Schumpeter's notions of "Creative Destruction" a reality. In addition, disruptive innovation suggested by Clayton Christensen is taking industries over with ideas opening up new avenues of doing business. Unless we wake up to smell the reality, we will eliminate ourselves.

John F. Kennedy once asked people to think of what they can do the country instead of what the country can do to them. Most of today's workforce is still expecting their employers to train them and tell them what to do. People fail to take their future in their hands and wait for the right opportunity. An anonymous quote reads, “If opportunity does not knock, build a door.”  The successful people are those that are not only awake but arise by training themselves with the required knowledge and volunteer to gain the required experience for the right opportunity to knock.

Many fear if they will make the right decision and stumble to move forward. If we walk back on our memory lane in the past, are we all certain that we always made the right decision? If we did, we wouldn’t have the expression, “In hindsight, vision is 20-20.” No one can predict what the future can bring. If fear had ruled, would anyone of us now know the depths of the ocean or the height of the space? What we are today is the result of overcoming fear and not yielding to it. So, don’t worry about making the right decision but proactively work towards making the decision right. We can do that by adopting individual strategies that meet our goals.”

A wise man once said, "Show me a person that has not failed, and I will show you a failure." Life is not about what happens to us but how we react to it. If one has learned from failure and applied the lesson learned from such failure, then, one has turned failure into success. Did you know that Walt Disney was fired from his job for lack of imagination? It was only thousands of failed attempts that got Edison to get us the light bulb. Failure is not when you fall down but when you don’t get up again. So, adapt to the trends, refine your approach, and create your voice.

No matter how much you know there is room for growth. The wise also shares the responsibility to train the next generation. The value of knowledge lies when it is shared. Many claim luck as the special ingredient available only to the privileged. I always used to say, LUCK is also "Labor Under Correct Knowledge." So, find a mentor to enrich your knowledge, spread your knowledge by training and coaching others, and better yet become adept at being a student of knowledge. The more you know the more you understand how little you know. That awareness awakes you to a new reality where learning continues.

I have used this 5A principle during my training and teaching and have found my proprietary 5A principle is a good reference framework for people to improve themselves personally and professionally.

Share your comments and let me know if you would like to hear more!