Self Managed Team

Scrum Believes in Self Managed Team. That means, the team has the autonomy to organize itself to best complete the work items. Scrum has a completely different attitude to the conventional approach in that it explicitly puts the responsibility of solving problems into the hands of a self-managing team. There is no provision for someone to “make sure” it all goes OK, there is no “safety net” should things start “going wrong”. Scrum believes that the most appropriate people to solve a problem are those who need to deal with it.

  • A key part of self Managed team is that, whatever the solution/design/approach the team comes up with, it is more likely to take into account local issues and current, relevant knowledge that it is more likely to work. This also has an added benefit in that, when things get hard, the team are much more committed to making things work as it is their decision/solution etc. They will find ways for it to work, whereas if it were someone else’s decision they would be less motivated and may say something like “I didn’t think it would work, but it’s some one else’s problem”
  • Previously even a supposedly “empowered team” had a project manager to fall back on, someone who would carry the can if things went wrong (and perhaps take the glory if things went well) and so, when the crunch came, they knew the responsibility would be taken up by someone else.
  • The vast majority of problems (or opportunities) facing our companies and teams today are complex ones. Everything we come up against, or ideas we come up with involve ever-increasing levels of complexity that usually cannot be solved by one person’s mind. Therefore we need to harness the motivated minds of a team where the value of the whole is greater than the sum of the parts.
  • There is nowhere to hide in a self Managed team, everyone is responsible for the performance of everyone. No individual team member is held accountable.
  • Self Managed team can greatly increase productivity, motivation and satisfaction for all concerned. This, coupled with more suitable deliverables is a true win:win scenario. However, in order for the benefits of self-organization to take root and bear fruit, we need a conducive environment for it to flourish. We need to have a culture of “all information is good information”, an understanding that “everyone did the best they could given the circumstances”. What matters is the project success rather than individual success.

Note – earlier version of Scrum Guide mentioned the term “self Oragnized”

Myth about Scrum only being useful for small projects

It is a common mis-conception that Scrum is only useful for small projects.

The fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution. Read more to find out more

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

  • Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
  • Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.


The size of the project has nothing to do with the use of Scrum or not.

  • Scrum is based on Empirical Process Control Theory.  Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
  • Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
  • Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

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

Myth about Sprint Planning consisting of three parts Part1, Part2, Part3 vs Topic1, Topic2, Topic3

Many teams imagine Sprint planning as 3 parts being done serially – one after another. However that reduces the collaboration among teams – Let us understand why

Common Misconceptions and negative implications

Most teams implement Sprint Planning as three parts – Part 1, Part 2 and Part 3. The Product Owner comes in part 1 and 2, helps with setup of the Sprint Goal (WHY) selection of functionality (WHAT) and then the Developers sits and thinks over the technical (HOW) during the Part 2 of the sprint planning. The implication of this is that PO then does not get involved in the detailing and the road-blocks that team faces and technical feasibility problems that result during the Part 3 becomes a back-and-forth discussion between PO and Developers. This obviously results in a loss of productivity.


  • The whole Sprint Planning process is an iterative, incremental and collaborative process and therefore there are three Topics and not three Parts to the meeting.
  • First topic – WHY – is the business objective
  • Second topic – WHAT – is the selection of the Product Backlog Items which may help achieve the goal. So, it is forecasting what items should be part of this Sprint.
  • Third Topic – HOW – is the discussion of details and feasibility of the items and the help required from Scrum Master or Product Owner to get this done.
  • So, you can consider the WHAT and HOW are iterative in nature where the HOW revolves around the WHAT and joint discussions are necessary. There are possible considerations that may happen to the WHAT because of the HOW. Technicalities do influence to a large extent on WHAT can be done and what cannot.
  • The Sprint Planning Event can end with a decision on THE WHY – Sprint Goal, a forecast of WHAT needs to be done and the HOW for at-least a few things to be done over the next few days. However, the Sprint Planning PROCESS does not end with Sprint Planning EVENT. The Product Owner and Developers keep doing the discussion on the two topics – WHAT and HOW throughout the Sprint. Many-a-times, the teams do these detailed discussions on the HOW for the WHATs after daily scrums on the plan for next 24-48 hours.

So, my recommendation is not to call the Sprint Planning as Part1, Part2 and Part3 but iterative, incremental and collaborative process of Topic1, Topic2 and Topic3 which starts with Sprint Planning and continues throughout the Sprint.

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

Some Ideas Formally Included First Time in The Guide – Product and Product Goal

Scrum always was a framework to deliver complex products. However the 2020 Scrum Guide defines “product” and Product Goal formally for the first time

Scrum Guide now formally defines the terms product and product goal

Scrum always was a framework to deliver complex products. However the 2020 Scrum Guide defines “product” formally for the first time . The guide defines scrum as “a vehicle to deliver value”.

A product has a clear boundary, known stakeholders, well-defined users or customers üA product could be a service, a physical product, or something more abstract.

üIt has a clear boundary, known stakeholders, well-defined users or customers üA product could be a service, a physical product, or something more abstract.

This definition clarifies the misconception that a product is a tangible item and a service which is inherently intangible can not be termed a product and as such scrum teams cant work on a service , the guide now states transparently that

  1. A Product has has a clear boundary, known stakeholders, well-defined users or customers.
  2. A product could be a service, a physical product, or something more abstract.

A product goal is defined as the long-term objective for the Scrum Team. It describes a future state of the product which then serves as a target for the Scrum Team to plan against. This goal is included in the product backlog and in fact is a “commitment” that drives “what” gets added in the product backlog.

Scrum team has one product goal and the team must fulfill or abandon the goal before moving on to next product goal

Scrum Guide 2020 – What’s New?

Scrum Guide 2020 – What’s New?
Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Excitement is in air. The new scrum guide is out. Like always there is a great curiosity among agile enthusiasts to see how the guide to scrum has evolved.

Over the years Scrum Guide has changed considerably. A very key point to keep in mind would be that “Scrum” has not changed – Jeff and Ken have inspected and adapted the guide to Scrum so that Scrum is articulated clearly and concisely.

Here, in this series, I have articulated my understanding and perspective on how the guide has evolved in its latest avatar. Some Of the themes I want to explore in this series are::::

  1. Purposefully Incomplete – First time, the authors have put it on the paper that scrum guide is Purposefully incomplete. In my eyes, this drive to make things less prescriptive is behind many of the changes in scrum guide.
  2. Some Ideas Formally Included First Time in The Guide – Some ideas and Principles like Lean , product goal , formal specification of commitments are formally included first time in this guide. Some of these were already practiced by many as a beneficial. Now they are included in the guide formally. This formal inclusion helps to further the Scrum cause of focusing on value
  3. Some Changes That Bring in More clarity – Along with concepts formally included for the first time, we can see some small but significant changes. These changes bring a wonderful clarity. Some items in this list are rewording of scrum master being a servant leader or the team being “self managing” instead of “Self organized”
  4. What Has NOT changed – Perhaps the most important theme, I want to explore. Scrum is delightfully incomplete and its a very satisfying exercise to contemplate what has not changed and more importantly why? These are the aspects of scrum that provide the anchor to our thought process.

Myth about Definition of Done being baselined before project starts

definition of done is often looked at a checklist that is set in stone-something not evolving – let us discuss how Definition of done evolves

Common Misconceptions and negative implications

  • Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
  • By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
  • Lot of time then gets wasted in trying to get the product too precise and the releases get delayed


  • Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
  • There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
  • As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
  • However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
  • For example : One could start with a definition of done as
    • Acceptance criteria for functionality is met
    • User Documentation is completed 
    • Integration testing is done
    • Regression testing is done
  • As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
    • Acceptance criteria for functionality is met
    • User Documentation is completed
    • Integration testing is done
    • Regression testing is done
    • Performance testing is done
  • So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
  • By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
  • It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

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

Context Of Scrum

The Matrix above shows the context of Product vs Teams.

  • When we define a Product – here we define a Independent Value Stream which makes sense from a market perspective.
  • When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
  • Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts.
  • Scaling means there are multiple teams working on a Product (Value Stream). Scaling is out of scope of Scrum.
  • “Many Products – Many Team” context is defined by portfolio management, which is out of scope of Scrum.
  • “One Team – Many Product” quadrant is for Staff Pools who do heterogenous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.


A Framework

Scrum is a Process Framework. The word Framework means “MINIMUM SUPPORTING STRUCTURE”. Scrum does not define any details related to tools, techniques, implementation details or does not give specific recommendations on how to deliver complex work. Scrum defines the following

  • 3 Roles – Scrum Master, Product Owner and Development Team
  • 3 Artifacts – Product Backlog, Sprint Backlog and Increment
  • 5 Events – Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective and the Sprint

Beyond the minimum, Scrum gives flexibility to add things to the framework as the Scrum Team desires to. For example, there could be a mid-Sprint Review, there could be an additional Demo meeting to the PO, User Story could be used as a technique to represent scope, Automation tool such as Selenium could be used to implement regression test automation etc.

What is a Method?

Method is much more than a framework. Method may contain a framework of its own, but may also includes :

  • Tools and Techniques
  • Detailed Processes
  • Detailed Guidance
  • Templates
  • Document Formats
  • Organizational structures
  • etc

Example of a method is Extreme Programming

process methodology framework

A Metaphor of Framework vs Method

A Framework – Essential supporting structure – a Empty Photo Frame with a Glass


A Method – Details, Tools Techniques – An Photoframe along with the Photo which gives all details



There are two types of process control

  • Defined Process Control – Plan driven way of doing things. Where the target (goal) is known, one can create a Plan and execute the plan.
  • Empirical Process Control – Goal driven way of doing things. In this type of problem, the solution or requirements or both are unknown. So, one has to take decisions on something which has already happened. So, the decisions have to be taken on trial and error way. Try something, see if it works, if it doesn’t work then try it another way. Too much of upfront planning is of no use in this type of process control

In Scrum, decisions are made based on Empirical Process control. In Scrum we try observation and experimentation rather than on detailed upfront planning.


 Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture.


 Inspection in Scrum is depicted through:

  • Use of a common Scrumboard and other information radiators
  • Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog , and Conduct Release Planning processes.
  • Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.


 Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.

A Metaphor on Empirical and Defined Process Control


Scrum is an iterative and incremental Agile product development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach”. Scrum enables the creation of self-organizing teams by encouraging collaboration of all team members, and verbal communication among all team members and disciplines in the project. A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum is founded on Empirical Process Control Theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum Employs an iterative, incremental approach to optimize predictability and control Risk.