Myth that Scrum is a Magic Wand to Solve all Project Issues

Common Misconceptions

People think that just by moving to Scrum all their issues will get resolved and magically all timelines will be met, no budgets will ever get overrun, all people will be happy, all customers will be happy, all changes come free and so on….

What Really is Scrum?

Scrum is a framework for solving Complex Adaptive Problems. Complexity means “Unknown-ness”. The Unknowns can be on requirements or on solutions. Where things are unknown, you cannot make detailed plans and just track the plan to closure. In such situations where things are unknown, what you see in front of you can be the only decision factor. Taking decisions based on what you see and constantly Inspect and Adapt based on what you see is called “Empiricism” or “Empirical process Control”. Scrum is a framework which sits on the “Empirical Process Control Theory”. For known problems (requirements known and solutions known), you will not need the inspect-adapt approach. The approach used for known problems is called “Defined Process Control”. Waterfall framework is based on “Defined Process Control”


One must understand that Scrum does not necessarily reduce cost and timelines. In Empirical process control, there will always be a feedback structure since the decisions are taken based on what you see. That means, we think about short-term in detail and long-term at a high level. When we see the results of short-term, we get feedback and then we inspect and adapt based on what we see. Therefore, there may be repetitions due to the feedback structure. Repetitions may mean that some re-work may happen. One must not think that just by doing Scrum, the cost and time will be lesser. If we use Scrum for problem statements which could have been solved using waterfall (or Defined process control), then unnecessary overheads and unnecessary inspect-adapt cycles may increase the cost and timelines. My recommendation is to choose the right framework for the right purposes. Taking a “one-size-fits-all” is not a great idea.

The teams are not necessarily happy doing Scrum. In the Scrum way of doing things, the timeframes are short. Delivery cycles shrink to a few week cycles. There is a constant pressure on teams. Many times, you will notice comments in the team like “Waterfall was better”. Scrum is actually Pervasive. That means people don’t like this drastic change in their lives. This change touches people’s lives. My recommendation is to ensure that every organization first implements a culture which sustains this pressure. The earlier model, where there was “push culture” should change first. Management should not create unnecessary pressure on the teams. Agile principle number 8 should be implemented first “Agile processes promote sustainable development. Sponsors, Developers and Users should be able to maintain a constant pace indefinitely”

The business teams are not necessarily happy doing Scrum. The Business teams were used to pushing accountability conveniently on the technical team’s side under the umbrella of a few terms like “Managed Services” or “Managed Outcomes”. The IT companies also marketed these terms like “Managed Services” to create differentiators for themselves. The Business teams suddenly start feeling the heat when they are held accountable for ensuring that the delivery happens properly and making sure that they have to work with the technical teams on a day-to-day basis. In Scrum, we define the accountability “Product Owner” where participation from a Business perspective is extremely important. My recommendation that the Business Teams must be made to understand that Accountability cannot be outsourced and one cannot toss the accountability on the technical side. The business should be brought in sync with the Agile principle “Business People and Developers must work together daily throughout the project”. Scrum emphasizes that the right people take the right accountability and accountability cannot be outsourced.

The Business teams have conveniently understood that “Changes are free in Agile and Scrum”.  One has to understand that no changes are ever free. There is always a cost associated with a change. It is just differently looked at in Scrum. In Scrum, we tend to give importance to more valuable features. That means, the less valuable features go down the product backlog and may never get implemented. So, pushing the teams to do all requirements may not be a great idea, else the cost will obviously go up. My recommendation is to follow the Agile principle number 10 which says “Simplicity – The art of maximizing the work NOT done is essential”. The business has to know that nothing in this world is free and we need to learn to compromise less-value features for the more valuable ones


Scrum is not a magic-wand solution to solving all problems. In fact, if you do things incorrectly then the problems will multiply. It is better for organizations to understand Scrum and Agile correctly and apply only where required. “One-size-fits-all” is not a great approach.

Myth about every Sprint Output resulting in a go-live to production

Myth about every Sprint Output resulting in a go-live to production

Common Misconceptions

Most people feel that every Sprint MUST make an Increment which HAS to be sent to production and given to the end-users for using. This is actually not true. Sometimes, it is not possible to produce Incremental “production-ready” outcome every Sprint

What really is the outcome of the Sprint?

Scrum defines the “OUTCOME” of the Sprint as an Increment which is “USABLE”. Usability is associated with getting feedback and not necessarily “Go-Live”


  • Sometimes, in a short sprint it may not be possible to create an “Go-Live-Ready” product. However, every Sprint must result in a deliverable where feedback can be received. The feedback may happen from internal stakeholders and not necessarily the end-users
  • Sprint should be considered separate from “Release”. While “Release” is not a Scrum term, most teams use the word “Release” to describe “Go-Live-Ready” outcome. Generally, it is observed that multiple Sprint outcomes can be combined together to create a “Release”. However, this is also not a necessary condition. Sometimes, teams may create multiple “Go-Lives” within the Sprint itself. It is important to understand that feedback is necessary every Sprint so that we know as a Scrum Team that we are going to achieve the Product Goal (Long term Goal). The intent of Sprint should be to optimize the probability of achieving the long-term objective and the feedback received should be used to optimize this probability. Now, the feedback may come from internal stakeholders or end-users. Important part is that feedback should come every Sprint.
  • While this article says that it is not necessary to create a “Go-Live-Ready” outcome every Sprint, that does not mean that we create “Documentation” as output. We CANNOT be doing a “Requirements Sprint” which creates a “Requirement Document” as an output. We CANNOT be doing a “Coding Sprint” to create a “Code” as output. If we create outputs such as Documents then what we end up doing is “Outputs” (which are of no value) instead of “Outcomes”. “Outputs” do not necessarily result in “Outcomes” which are of business value or feedback-able value. “Outputs” do not necessarily result in feedback where we can check progress towards the Product Goal.


Sprint creates an Incremental outcome which is called Increment. The Increment should get the Scrum Team feedback, which will optimize the probability of meeting the Product Goal. The Incremental outcome may be a “Go-Live-Ready” outcome many times within a Sprint or sometimes over multiple Sprints. The Increment should never be an output which is not a valuable outcome.

Myth – Scrum Master being the Mandatory participant of Daily Scrum

Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

  • Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
  • Developers sync up daily so that the plan for next 24-48 hours is effectively done
  • Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
  • Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

  • Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
  • Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
  • Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
  • Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
  • Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
  • If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
  • Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
  • Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.


Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

Working in Agile Way – Some Metrics You can consider

Some Sample Agile Metrics

Each team needs to define Metrics that help them inspect and adapt. Below I have given some metrics PO as well as Developers can use

Measuring Value –

Scrum is a Value Framework. The focus is on “Value delivered to customer” rather than “scope delivered as per plan”. It is then clear that we need to find a way to measure “value”.  How a PO will measure value will be different than how developers will measure Value. The table  below shows some sample Metrics that can help the PO and developers do the same

PerspectiveSome Metrics
PORevenue Feature Usage Reduction in Complaints Increase in CSI….. NPS  
DevelopersDefects Leaked Prod/UAT First Time Pass Rate  Tech debt

Measuring Frequency-

Agile manifesto states the importance of delivering value early and in a continuous or frequent manner. Measuring the frequency of delivery will help  the PO and Developers to

PerspectiveSome Metrics
POLead Time Release Frequency  
DevelopersVelocity Sprint Duration

Measuring Day to Day Work

While measuring the Value delivered and the frequency of the said duration gives PO and Developers

PerspectiveSome Metrics
PO# Of Times PBI (Story)need to be re-negotiated or acceptance criterion updated How many times PO has seen a feature before Review
DevelopersWork prediction– burnup, burn down , WIP , CFD Planning Quality – Estimations, sprint planning value (# of tasks identified Vs Time spent) Operational Excellence – Broken Builds , automation %, test coverage , code quality Self Organization Index – how many tasks they needed outside help Cross Functionality – “T Index”

Metrics in Agile :: Getting Started

Do we need Metrics in Agile Projects?

We saw in earlier article that traditional metrics do not help when working in Agile manner. The question then comes to mind is do you really need metrics while working in Agile?

The answer is a definite yes – When done well, Metrics provide us with transparency by giving quantified information that does not depend upon individual perception. This quantified information helps us to inspect the work we are doing and value we are delivering. The inspection then allows us to adapt our way of working to improve the value we deliver

In other words, metrics help us to work in an empirical manner.

What should we measure while working in Scrum?

In My experience there are 3 major dimensions where Metrics helps us to inspect and adapt

  1. Value – Are we delivering Value?
  2. Frequency – Are we delivering value frequently enough?
  3. Day to day Metrics

Perspectives in Metrics

For each of the metrics above, developers as well as Product Owner  will need different information to inspect and adapt their way of working and metrics need to be defined accordingly

Traditional Metrics Do not Help in Agile Projects

Traditional Metrics are often centered around measuring planned versus actual. They measure efficiency of scope delivery.

The focus is often around measuring the efficiency of the delivery be it the schedule or cost adherence, Scope delivered or quality of the delivery.

Some of the usual metrics companies track are

  1. Schedule and Cost Variance
  2. Volume Of work delivered (KLOC)
  3. Productivity
  4. Requirement adherence /Rework

The above metrics help us to see if the teams are delivering as per plan – But in Agile we believe that while planning is indeed quite valuable – plans need to be updated often. Then these metrics do not seem relevant when plans are being updated very often

Another key point missing in the above metrics is the focus on value – These metrics measure only “what work the team did” they do not measure “what Value was generated

Myth – Sprint Review being the review of the Developers done by Product Owner

Common Misconceptions and Negative Implications

·        It is a common practice for a Product Owner to come up with a set of requirements in the Sprint Planning and disappear during the Sprint. Then appear directly at the Sprint Review forum and conduct the review of the Developers work during the Sprint Review.

·        By doing this, an important opportunity of giving feedback continuously is lost. The feedback becomes a big-bang-end-of-the-sprint activity

·        Since Product Owner is seeing the product first time during the Sprint Review, it can become difficult to take feedback from stakeholders

·        If Product Owner brings along the stakeholders to do a Sprint Review, the Product Owner ends up acting like the “Other party” and does not build confidence in the team doing the work

  • When the Product Owner sees the newly increment only at review time, Sprint Review becomes a gate that holds back value from reaching the users. When the Product Owner sees the increment during Sprint an opportunity is created to release value earlier


·        The Product Owner owns the product. Therefore, it is important for the Product Owner to participate in the product development continuously and constantly provide feedback.

·        The Product Owner has to build confidence with the Developers. Developers being left alone is not a great idea. The Product Owner should not behave like an outsider and should not sit on the other side of the table. Once the Product Owner wears the “Product Owner Hat”, he/she is first part of the Scrum Team and then part of the Customer or Client or Stakeholder team

·        Developers must not fear the Product Owner. Feedback is not a cause for worry. Feedback is good. The earlier you receive the feedback, the better it is for the Product

·        Typical steps in the Sprint Review that are seen useful by many teams could be as below

o   The Product Owner should invite the relevant stakeholders for a Sprint Review

o   During the Sprint Review forum, the Product Owner should sit with the Developers

o   The Product Owner should thank the Developers in front of the stakeholders for the work done

o   The Product Owner should take ownership of the product during the Sprint Review and collaborate with stakeholders to make it a working session

o   During the Sprint Review, the feedback should be from Stakeholders and not from the PO. The PO feedback is assumed to have been taken already during the Sprint

o   The stakeholders and Product Owner should think about the next steps based on market place conditions and make adjustments to the Product Backlog


·        Sprint Review should be a working session between entire Scrum Team and Stakeholders

·        Product Owner should be reviewing the product with stakeholders with help of the Developers

·        Product Owner should have provided feedback to the developers continuously throughout the Sprint and should not be seeing the product first time during the Sprint Review

This post is republished under my name @ Myth – Sprint Review being the review of the Developers done by Product Owner (

Myth :: PO should NOT part of Sprint Retrospective

Common Misconception

Product Owner is considered a “Client” or “Customer”. So, most people feel, how can you invite a “Client” for an internal forum to discuss “what went well, what did not?”


  • Most Product Owners indeed behave like a “Client” or a “Customer” instead of a Scrum Team Member. Therefore, the Developers do not consider the Product Owner a part of them and consider him/her as an outsider. The Product Owner should be first part of the Scrum Team and then be a “Customer” or “Client”
  • Product Owners often ridicule the teams or shout at their teams for not understanding the requirements properly. Product Owners often escalate against the teams to the Line Managers of the Developers. This creates a divide between the Product Owner and the Developers. The Developers then don’t feel comfortable about opening up in front of the Product Owner. The Product Owner’s job should be to get the Developers to feel comfortable and put the “fear-factor” to rest. This means, the Product Owner should be empathetic, calm, show patience and be looked at as a Leader instead of a manager.
  • Sprint Retrospective is a forum to see what went well and what did not go well. This increases the effectiveness of the next Sprint. If the Product Owner is not there in the Sprint Retrospective, then effectiveness improvement will be looked at only from the perspective of the Developers. The Developers are doing the technical work for the Product itself. So if the Product Owner is absent in a Sprint Retrospective, the effectiveness improvement cannot be done from the Product perspective
  • Sprint Retrospective is a good forum to discuss the DoD (Quality Measure for next Sprint). If the Product Owner does not attend, the Sprint Planning of the next Sprint may be an issue since DoD is not finalized.


As a part of the Scrum Team, the Product Owner is a mandatory participant of the Sprint Retrospective. Sprint Retrospective is an excellent forum to thrash out any opinion differences and plan for improvements and everyone from the Scrum Team must participate.

Scrum Master the solver of all impediments – An Anti Pattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Scrum Master should solve all impediments

  • In the 2017 version of Scrum Guide the accountability of the Scrum Master was mentioned as “Removing impediments to the Development Team’s progress;”. This sentence was often misunderstood and it was assumed that Scrum Master is the one who runs around and solves impediments.
  • The term “Facilitator” is commonly misunderstood as a “coordinator”. Most teams come from a waterfall background and are used to having a Project Manager. In most organizations, the Project Manager is nothing more than a PMO who coordinates and does administrative activities. The essence of facilitation is to make it easy for the team to get to conclusions and decisions. Impediment solving is only one aspect of the Facilitation.
  • Most organizations implement Scrum Master as a replacement for the PMO responsibilities and expect Scrum Master to run around and solve impediments.
  • From the outside, this looks to be a great idea to have developers do the work and Scrum Master run around and get the administrative stuff done.

Negative Consequences of having a Scrum Master solve all impediments

  • One of the fundamental elements of Scrum is “Self Management” where the team manages itself. The Scrum Master’s job is to teach the team to be self managed and cross functional so that they can get the work done.
  • Team members other than the Scrum Master might be better qualified to solve an impediment
  • People often then shrug off their accountability and expect Scrum Master to be the PMO and even solve problems which they could solve internally
  • Problems are often too complex to be solved by one person and therefore Scrum Master may not be the correct person to solve the problem
  • Viewing an impediment from different angles helps to find effective solutions
  • Many problems have to do with the way how people work together, solving such a problem cannot be done by one person

What could be done to avoid this anti-pattern

  • The first line of defence for the team should be the team members themselves. The Scrum Master must teach the team to do this and not push everything into Scrum Master’s plate
  • The Scrum Master should not get overloaded with solving impediments. The Scrum Master should be an observer, a coach and making sure that facilitation is done.
  • For impediments which actually need Scrum Master’s help, only those Scrum Master should focus his/her attention on.
  • Scrum Master should use his anticipation skills to anticipate issues so that the team can start looking for solutions a little bit in advance.
  • In short, Scrum Master should become a coach and facilitator rather than just being a PMO.
  • To clarify the actual accountability of Scrum Master with regards to impediment solving, the sentence has been reworded in the 2020 version of Scrum Guide to “Causing the removal of impediments to the Scrum Team’s progress” – which essentially means that it is not necessary that everyone just dumps all impediment solving on the shoulders of the Scrum Master.

This article is re-published on WORLD OF AGILE website –

Hardening Sprint – An Anti Pattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Hardening Sprint seems a good idea?

Scrum Teams are under constant pressure to deliver features. The stakeholders and Product Owners often push the Developers for going to production as soon as possible. 

In these situations, the developers often postpone a lot of work to be done later. Examples include – documentation, code cleanup, defect fixing, commenting of code, hard-coding, bypassing checks etc.

Then the Scrum team introduces a “Hardening Sprint” after 4-5 Sprints to take care of all these pending activities. Therefore introducing Hardening Sprints is generally considered a good idea by a lot of teams.

User of Hardening Sprint introduces following problems

Pending work increases. Many times the Hardening Sprint does not get taken and the work just keeps accumulating

It becomes more and more difficult to tidy up the mess

Teams end up forgetting things later on

Increase in the possibility of the defects since things get fixed later

What could be done instead of Hardening Sprint

Follow the agile principle of “Simplicity” – the art of maximizing the work not done. That is, don’t push more features. Try to complete a lesser number of features with all things done.

Slow down – focus on quality rather than speed

Make the Definition of Done more stringent

Focus on engineering practices such as Automations, CI/CD, Automations, TDD

Say NO to a hardening sprint. Do not keep pending activities. This article is re-published on WORLD OF AGILE website –