Scrum Foundations – Empiricism, Self Organization, Prioritisation, Rhythm and Collaboration

Scrum Foundations

Scrum Foundations is based on 5 principles of Scrum namely Empiricism, Self Organization Prioritisation, Rhythm and Collaboration.


Empiricism is the foundation of all scientific inquiry and is used by Agile teams to identify emergent requirements and incrementally develop software through a process of inspect and adapt. Detailed  upfront planning and defined processes is replaced by just in time inspect and adapt cycles.  In empiricism, experience is seen as the primary -if not the only source of knowledge

According to Wikipedia,   “the empirical model of process control provides and exercises control through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs”.

According to Ken Schwaber, empiricism “is the act of making decisions as to what is. Scrum is an empirical process, sometimes described as “the art of the possible.” By this, I mean that we do the best we can with what we have.

In Agile, empiricism comes to denote transparency, inspection and adaptation of the work to be done.

  • Transparency comes through the Task boards, Burn down charts, Daily Standups, Sprint Reviews and Retrospectives – through which one can clearly know the flow of work in the team.
  • Inspection is done through interactions of the team, moving of work on the Task boards and goes on till the retrospectives where “What went well” and “What needs to be improved” are openly discussed.
  • Adaptation happens in the Sprint Review and Retrospective where the team gets the feedback of the work done in the current Sprint and also identifies what needs to change / what needs to be continued going forward.

Self Organization

Self Organization is at the heart of Scrum and is the key to creative problem solving. Small teams manage their own workloads and organize themselves around clear goals and constraints. Self-organization requires (and implies) that teams actively experiment with approaches, learn from failures and continuously adjust.

A Self Organized team is a group of motivated individuals, who work together toward a goal, have the ability and authority to take decisions and readily adapt to changing demands.  Self-organization within teams requires that members are cross-functional. This means that individual members are cross-skilled to the extent that work can be distributed dynamically at any moment in the sprint.

Ingredients of Self Organized teams

  • They pull work for themselves and don’t wait for their leader to assign work. This ensures a greater sense of ownership and commitment.
  • They manage their work (allocation, reallocation, estimation, re-estimation, delivery, and rework) as a group.
  • They still require mentoring and coaching, but they don’t require “command and control.”
  • They communicate more with each other, and their commitments are more often to project teams than to the Scrum Master.
  • They understand requirements and aren’t afraid to ask questions to get their doubts clarified.
  • They continuously enhance their own skills and recommend innovative ideas and improvements.

Five essentials of self-organizing teams

  • Competency: Individuals need to be competent for the job at hand. This will result in confidence in their work and will eliminate the need for direction from above.
  • Collaboration: They should work as a team rather than as a group of individuals. Teamwork is encouraged.
  • Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
  • Trust and respect: Team members trust and respect each other. They believe in collective code ownership and are ready to go the extra mile to help each other resolve issues.
  • Continuity: The team should be together for a reasonable duration; changing its composition every now and then doesn’t help. Continuity is essential for the team.

Truly self organized teams end up in having a more efficient process, facilitate learning,  improve motivation among the team, and take ownership of the work to be done.


Prioritization directs the team’s work by focusing the team on the most important items.  In simple terms, prioritization is work on the most important thing – and not to waste time focussing on work that does not add immediate value.  It’s the product owner’s responsibility to ensure that the product backlog is prioritized

Factors involved in Prioritization in Agile:

The product owner needs to prioritize things realizing certain factors which are posed below:

  • Financial Value:While prioritizing features the finance value the feature could express should be realized. Features adding new revenue and incremental revenue or cost reduction should be prioritized.
  • Value and Cost:Prioritization should also depend on the value and cost comparison of the feature, whether the value of feature worth the cost of developing it. Value and cost together indicate the ROI for the features.
  • Knowledge gained:Prioritization should be based on the possibility of significance and amount of the knowledge to be gained by the agile team while working on the features.
  • Risk involved:The product owner should realize the risk factors involved and to be incurred by introducing the features.

Prioritization techniques

Following are some of the techniques used for Prioritization.

  • Classification – High Medium Low, MosCOW, 1, 2,3 .. Now, next later
  • Value mapping – priority quadrants, systemic model, pirate metrics  AA R RR
  • Market place simulation – Buy a feature
  • Context Evaluation – Story maps, Prune the product tree


According to Tom and Mary Poppendieck “A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity.  An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity.”

A healthy agile project has several typical rhythms such as releases, iterations, stand up meetings, automatic builds etc – and these have typical ranges (that a standup cannot last more than 15 minutes) or characterstics (standups cannot be used for design discussions).  When these ranges or characterstics are not observed, then it indicates something is wrong with the process.

Timeboxing  creates the rhythm that drives development.  When setting up a new agile team it is important to immediately get that team into a rhythm.     It is important to schedule Daily  Scrum meetings at the same time and same place everyday.  This will help form the team’s basis of rhythm.  Once this rhythm basis is set,  it can be extended to  other project related meetings – so that a healthy rhythm is maintained.



Collaboration is “the cooperative behaviour of a team empowered to solve a clear and meaningful problem, such that the capabilities of the team are leveraged in addition to the collection of individual talents. This is accomplished through rigorous dialogical practices among team members”.

Becoming collaborative is a two-pronged task. The organization has to support it and reward it, and the individuals need to develop the habits and behaviours that realize collaboration. The organization need to make the team responsible, to give the team authority as a whole, rather than having a single “boss” make all the important decisons. Poor collaboration is a result of poor relationships and rivalrous practices. You get poor collaboration in highly politicized or blame-based environments

Characteristics of collaborative teams

  1. They are self-organizing versus role or title-based in organization.
  2. Teams are empowered to make decisions versus being dictated to by an outside authority.
  3. Members truly believe that, as a team, they can solve any problem.
  4. Members are committed to success as a team versus success at any cost.
  5. Trust versus fear or anger motivates the team.
  6. They aggressively engage in participatory decision making versus bending to authoritarian decision making or succumbing to bullying for decisions.
  7. Decisions are consensus-driven versus leader-driven.
  8. Teams maintain an environment of constructive disagreement versus falling into damaging conflict or no conflict at all.