This slide deck contains topics covered in the CSM courses that I teach.

1. Certified Scrum
Master
Juan Banda, CST
juan.banda@percella.com

2. Agenda
1. Scrum Theory
2. Scrum Roles
3. Scrum Events and
Artifacts Transparency
4. Sprint and Increment
5. Sprint Planning
6. Daily Scrum
7. Sprint Review
8. Sprint Retrospective
9. Product Backlog
10.Sprint Backlog
11.Definition of Done
12.SM Core Competencies
13.Service to the
Development Team
14.Service to the PO
15.Service to the
Organization
2

3. Scrum is a lightweight
framework in which a
cross-functional team
develop products in an
iterative, incremental
manner

4. Like in the
chess game,
Scrum rules
are simple to
understand
but then
Scrum itself
is difficult to
master Photo by G CACAKIAN

5. Scrum can also be seen as a
team-centric approach for
building products. Because
of this it is highly depending
on context and people which
make it not a good candidate
for direct extrapolation

6. Core Elements of Scrum
•Deliver a working product
every sprint
•Inspect and adapt every day
•Trust the team

7. Scrum Values
•Focus, Courage, Commitment,
Openness and Respect
•Abstract and difficult to cultivate
but without them Scrum won’t
work and the team won’t be a real
team but just a collection of
individuals instead

8. Scrum Values
•For Scrum to work the Scrum
Values got to be lived up by
people in the three roles, and
got to be present in the events
and artifacts

9. Scrum Values
•For instance, in the Sprint the
Team needs to stay focused on
the work, had the courage to
innovate, commit to the Sprint
Goal, be open to learn new
things and be respectful to
each other

10. Scrum
Values
are also
the
enablers
that make
a Scrum
Team to
stay
unitedPhoto by Ice birdy

11. Empirical Process Control
• Scrum implements an empirical process
control based on observations of reality
instead of ficticios plans
• Therefore empiricism means working in
a experience-based, fact-based,
evidence-based fashion and not
relaying just in up front created plans

12. Empirical Process Control
• Empiricism is support by three pillars:
Inspection, Adaptation and
Transparency
• Even though we have empiricism certain
things −like Sprint duration, Team
composition, and technology stack− are
defined and should’t be changed once
we start the Sprint

13. Empirical Process Control
• Applying inspection and transparency we
might decide to make some adaptations
for the next Sprint or the next day
• All in all in Scrum we try to keep the
balance between empirical and defined
and constantly bettering the defined side
of things based on experimentation and
empirical learning

14. Warning: if we take
empiricism to an extreme then
the system could become
chaotic, and if we do the
opposite and try to completely
define the system it’ll be
waterfall development again

15. Scrum is a Framework
• By being defined as a framework Scrum
can be extended, meaning that in reality
is a meta-framework that incorporates
empirical controls
• And by being barely sufficiently defined
it is suitable for product development
where the scope, market and other
variables will constantly change

16. Scrum is Agile
Photo by eventuo

17. Framework vs Methodology
• A methodology is a well defined set of
steps and processes that follow a
prescriptive order and if correctly
applied guaranteed the outcome
• A framework in the other hand is barely
sufficiently defined and invites creativity
and complementation with tools, ideas,
and practices from other disciplines

18. In simple terms, a framework
invites creativity and requires
effective team work, a
methodology invites
compliance and requires
effective control and
supervision

19. Another key distinction is that
in a methodology hard metrics
are a fundamental piece
whereas in a framework
collaboration, team work,
innovation and communication
take precedence

20. Scrum Requires Dedicated
Practice
• Because Scrum is a lightweight framework
easy to understand people and
organizations tend to think that by making
cosmetic changes and changing job titles
they’ll get Scrum right
• Quiet the opposite, Scrum requires study of
not just Scrum but other ally disciplines and
more importantly dedicate daily practice

21. Photo by Maxim Kushpel
Is just not
possible to get
the benefits of
Scrum without
embracing it
entirely and
practicing it
every day

22. Scrum Roles
• The Scrum Team consist of a number (7 ± 2) of
individuals on just these three roles:
• Product Owner -> Only one (still one and still
called Product Owner in LeSS)
• Scrum Master -> Only one (still called Scrum
Master in LeSS)
• Development Team -> Several (just called
Team in LeSS)

23. Product Owner Rights
• Have the final saying on the Product Backlog
order
• Come to the Development Team frequently with
a collaborative spirit and to see working
software that is well crafted and runs on an
integrated environment
• Cancel the Sprint if she identifies that the
Product Increment doesn’t make sense
anymore

24. Product Owner
Responsibilities
• Maximizing ROI by identifying product features and translate
them into a prioritized list also called Product Backlog
• Making sure that the Product Backlog is visible, adaptive
and clear for everybody
• Connect directly Development Team questions with the
customers that originated the requirements
• Hold the space for the Product Vision
• Keep the Product Backlog ordered and aligned with the
business objectives

25. Scrum Master Rights
•Call out the Scrum Team when she
observes that they’re doing something
different and calling it Scrum
•Have support from executives and upper
management to really change the system
in which the Scrum Team operates
•Try to extend the Scrum beyond and
above the current team

26. Scrum Master
Responsibilities
• Foster a learning environment in which the Development Team
members feel confortable experimenting, failing and learning
• Changing Scrum Team and organization dynamics
• Helping the Product Owner to effectively communicate
internally and externally with the customer and the
organization at large
• Helping the Development Team to clear obstacles
• Helping the Development Team to stay focused, close to the
gemba, remove waste and avoid distractions

27. Development Team Rights
• Feel contable saying “I don’t know but I
want to learn”
• Be capable of self organize and decide on
its own how the work is going to be done
• Invest time, effort, and energy to created a
well crafted software product that make
developers feel proud about their
craftsmanship

28. Development Team
Responsibilities
• Learn a second, a third and if possible a fourth speciality so
each team member can be more knowledgable and valuable
for the team
• Learn the customer domain specific language to
communicate more effectively
• Build software using modern engineering practices
• Avoid wasteful work and processes that delay feedback and
effective interaction with the customer
• Voice their opinion when they feel overcommitted or feel that
the product is going in the wrong direction

29. Development Team
Characteristics
•Long-lived -> same team members together over the years
(not officially required in Scrum but highly recommended)
•Co-located -> seated in the same table (not officially
required in Scrum but highly recommended)
•No formal managers -> who decides how the team works
or what they work on
•Self-organized -> they decide by themselves how to do the
work
•Empowered to make technical decision -> without the
intervention of external actor like architects

30. Development Team Too
Small or Too Big
• Less than 3 team members won’t provide
enough diversity of thought
• With less than 3 team members product
development might take too long because there
are just too few developers
• Beyond 9 team members coordination can
become problematic and risk of duplication work
and having idleness increases

31. PO is a Single Person
• A single person instead of a committee
shortens the decision making process
and helps to keep product integrity
• Similarly to what happens in Toyota
with its Chief Engineer concept,
centralizing product strategic decisions
in the PO speeds up product
development

32. A great PO
needs to be
really
immersed on
the market
and anticipate
its trends
Photo by traqair57

33. PO Has Final Saying on the
Product
• Even though customers, clients,
executives and users provide input on
the product, it is the POs prerogative
to decide on what goes in the Product
Backlog and in what order
• An empowered PO is entitle to make
product decisions on her own

34. The Product Owner Has
Final Saying on the Product
•The PO has total responsibility of the value
of the work carried by the team; in order to
guarantee that the product is actually
providing value short feedback loops are
recommended
•The PO collects feedback from different
sources like the customer, the Development
Team, the market, etc. and she analyzes
and decides the direction for the product

35. Feedback is
necessary for
validating
product
hypothesis.
The sooner
feedback is
received the
betterPhoto by Alan Levine

36. Only the Product Owner Says What
the Development Team Will Work on
• The Development Team is composed of full
timers that work on a single product at the
time and the PO decides which goes in each
Sprint; violating this rule will cause:
• Team loosing focus and increasing switching
cost
• Too many distractions because work is coming
from multiple sources causing delays, internal
fighting, rework, and confusion of priorities

37. Scrum Events and Artifacts
Transparency
• In the Daily Scrum the Scrum Team will have the opportunity
to sync-up for the day
• Furthermore, they’ll have the chance to learn about what
others are doing, hearing about the work and connect with
themselves for starting the day
• By being present in the moment in this event team
members will effectively inspect the work, the team,
impediments and make the necessary adaptations; of
course for these to work team members need to fell
comfortable saying things aloud in a very transparent
manner

38. Scrum Events and Artifacts
Transparency
• In the Sprint Planning event team members have
to be transparent about them not understanding
the work that is supposed to be done and make
clarifying questions to customers that where not
made during Refinement
• Also in this event inspecting that the Sprint
Backlog has just enough detail and is highly
visible will make it more achievable; adapting the
plan instead of defending the plan will foster
agility

39. Scrum Events and Artifacts
Transparency
• In the Sprint Review the customers need to have the
opportunity to really inspect the Product Increment, the
best way to do so is to allow customers to actually play
with the product that is running in a live environment
• Customers will provide more educate feedback after
playing with the product and that will trigger better
adaptations
• Of course for these to work transparency from all
participants is needed

40. Scrum Events and Artifacts
Transparency
• In the Sprint Retrospective the Scrum Team will
voice their opinions about how the Sprint went for
everybody; holding back opinions, critics or
resentments won’t foster transparency and will be
a more like a symptom of a dysfunctional team
• Based on true transparency, the team can better
inspect and propose the necessary
adaptations in their practices, behaviors, internal
process, etc. for the next Sprint

41. The Sprint is a
fixed period of
time
−timeboxed to
maximum 4
weeks− during
which the team
produces the
Product
Increment
Photo by Anita Ritenour

42. Sprint Goal
•Having a changing Sprint Goal might create the
impression in the Development Team that they’re
trying to create several disconnected features of a
product
•On the contrary, having an overarching goal that
remains the same for the Sprint contributes to team
alignment and product consistency
•Also by not changing the Sprint Goal we contribute
to customer’s understanding about what to expect
at the end of the Sprint

43. Sprint and Increment
• The output of each Sprint is a piece of well crafted
software that meets the Definition of Done and is in
usable condition; furthermore, it can be installed and run
in a production environment
• It is important because:
• It allows to provide true feedback from customers
• It makes evident the team’s real capacity and skillset
• It takes the team one step closer to the product vision

44. Sprint and Increment
• Releasing each Product Increment is a
business decision that has many implications in
other areas like legal, marketing, infrastructure,
etc. and for this reason the PO might or might
not decide to release at the end of each Sprint
• Notwithstanding, the Development Team needs
to keep adhering to the evolving Definition of
Done to keep improving their development
practices and discipline

45. Sprint Planning
• In Sprint Planning One/Topic One the
focus is understanding what we can to
achieve and based on that
understanding formulate the Sprint Goal
•Tip: write down the Sprint Goal on a flip
chart and keep it visible for the whole
Sprint

46. Sprint Planning
• Having a written and visible Sprint Goal
can contribute to:
• Helping visiting managers or customers to
quickly answering to the question to what
is the team’s current goal for the Sprint
• Helping team members to stay aligned
and working towards a goal that is greater
than just the work at hand

47. Sprint Planning
• In Sprint Planning Two/Topic Two, which is a
design activity, the focus shifts to discuss
how the Development Team is actually going
to do the work, self-organizing about who is
going to do what and estimating the work if
the team feels that providing estimates will
contribute some value
•Tip 1: decompose the work into smaller
pieces that can flow in a day or so

48. Daily Scrum
• The Daily Scrum is different from a traditional
status meeting because:
• Is not intended to inspect progress based on oral
status reports
• Is not for talking about an initial fixed plan and if
we’re still on schedule
• Occurs on a circle with no laptops, very distant from
the gemba and consequently reporting status will be
totally subjective

49. Daily Scrum
• This event has several constrains to support the
Development Team:
• Developers making the commitment to really focus and
be present in the moment
• Timeboxed for short duration
• No blame and judgement
• No bosses, everybody is in a peer relationship

50. Daily Scrum
• There are several structures that can help
the team to run this event within the 15
min time-box:
• Talking around yesterday’s achievements,
today’s goals and impediments if they exist
• Co-located team meeting face-to-face
• Parking lot discussions or questions for later

51. Sprint Review
•There are certain activities in preparation and during this
event such as:
•Setting up the room and logistics to allow the customers to
interact with the Product Increment
•The Scrum Team closely observing how the customer
interacts with the Product Increment
•The PO addressing questions and comments about the
connection between the business and the Product Increment
•The Scrum Master facilitating the conversations and event
flow

52. Sprint Review
•The Sprint Review produce outcomes such us:
• Validation that the product is going in the right direction
so the team just need to persevere for the next Sprints
• Indication that the product is not meeting customer
needs or not effectively solving their problem so the
team will need to pivot the product starting by adjusting
the backlog
• Realization of the real technical capabilities of the
Development Team that allows it to deliver software that
meets the Definition of Done

53. The true value
of
implemented
items will be
discovered
when real
customers can
actually use
them
Photo by Chris

54. Sprint Retrospective
• Some of the responsibilities for the Scrum Master in this
event are:
• Help the team to remain focused on the theme for this event
which is inspecting the process and the environment
• Keep the discussions balance between the positives and areas
for improvement
• Help the team concentrate the discussions around problems and
not putting blame on particular team members
• Keep the retrospectives alive using effective facilitation
techniques and constantly innovating them

55. Product Backlog
• For the Product Backlog the Product Owner is
responsible for:
• Leading its initial discovery with the participation of
customers and key stakeholders
• Keeping it alive and updated to reflect her current
understanding of the product
• Having it ordered so it contributes to putting the
Development Team’s effort and capabilities in the
right place

56. Product Backlog
• For the Product Backlog the Scrum Master is
responsible for:
• Coaching the other roles in using it as a tool for
communicating and executing valuable work
• Coaching the PO so she together with the
developer can keep it small and with just enough
level of detail avoiding overinvesting time detailing
and estimating every single item on it

57. Product Backlog
• For the Product Backlog the Development Team
is responsible for:
• Providing estimates and reestimate to bring in
reality
• Refining it on the Product Backlog Refining event
• Clarify its items by talking with whoever that came
up with the requirement

58. Product Backlog
• The Product Backlog has some essential characteristics:
• It is dynamic and constantly changes based on learning
from the team and discovery from the customers
• It is ordered so the team better focus its energy on the
most important items first
• It is finite so is a attainable in a reasonable amount of
time
• It is public so everybody can see it and contribute to it

59. A useful
metaphor is to
see the Product
Backlog as a
grocery list as
both share some
essential
characteristics

60. Product Backlog
• Any Product Backlog Items has these attributes:
• It is customer-oriented
• It will contribute value to the product once implemented
• It is not detailed in length using written documents,
instead it will be ongoing conversations between
developers and customers
• It will be later decomposed into smaller pieces of work
to incentivize flow within each Sprint

61. Photo by Paul Downey
The Product
Backlog
contains
items that
are just
placeholders
for
conversations
that will
need to
occur

62. Sprint Backlog
• The Sprint Backlog has these essential
characteristics:
• Its created by the Development Team and is actively
used during the Sprint
• It contains just primary information to not
overcrowded it with too much detail
• It can have estimates but those are just indicatives
and not hard commitments

63. Sprint Backlog
• The Sprint Backlog will more likely change as
developers start to work on it
• Developers are totally entitle to change task
estimates, introduce new tasks, decompose
further down or change tasks priorities
• However, the PO needs to be consulted if
developers feel the need to reduce the breadth
or depth of the agreed scope

64. Definition of Done
• Having a common Definition of Done across two teams is
necessary because:
• It’ll provide clarity for everybody about doneness and
that will prevent misunderstandings
• It’ll help teams to better communicate in code when
everybody call done to the same thing
• Even thought teams start from commonality each team
can decide to make it Definition of Done even more strict

65. Definition of Done
• The Scrum Team might decide to adapt its DoD when:
• A team found more value making its own DoD more strict
and wants to cross-pollinate the other team(s)
• In the Retrospective is been observed by the team that the
DoD is not strict enough or the opposite
• In the Sprint Review the DoD is allowing items to be
presented with technical or functional debt
• In LeSS the DoD is considered a measurement of current
team capability so it adapts as capability changes over time

66. Photo by Tor Hakon
Half-baked
items will hide
all sorts of
problems like
quality and
integration
undone work

67. Definition of Done
• The DoD is an essential component of Scrum because
without it the Scrum Team might just be building
incomplete items
• A weaker DoD will trigger risks such us:
• Qualifying half-baked items to the Sprint Review, items
that customers will critique and disapprove
• Creating the impression on developers that is fine to
come short with implementation and cut corners

68. Definition of Done
• One way to start creating a DoD is ask the
team about what would be the quintessential
elements that every item needs to have to be
considered truly done
• Summarizing those elements in a list on a flip
chart that the team can see during the Sprint
is a good way to remind everybody about the
DoD

69. Scrum Master Core
Competencies - Facilitation
• The SM can facilitate for the Scrum Team in
several ways that includes:
• Help them communicate more effectively by discovering/
rediscovering the more effective communication tool:
talking
• Help them to recognize when is better to remain silent and
hear and learn from who is talking
• Help them recognize that for a true Scrum adoption the
Scrum Team will need to change the system in which it
lives

70. Scrum Master Core
Competencies - Facilitation
• Part of the facilitation includes group decision making
and for these the SM can use techniques like:
• Fist of Five
• Voting using thumbs up/thumbs down
• Dot voting on a flip chart
• Taking an stand on the room (constellations)
• Decider protocol

71. Scrum Master Core
Competencies - Coaching
• Facilitating means helping the team to reach conclusions
and communicate more effectively
• Teaching is showing others an skill with the expectation
that they can also pick it
• Mentoring is about taking on a mentee and informally
pass experience and knowledge
• Coaching is different from the others because it is
connected to help others discover their own answers
without telling them what to do

72. Scrum Master Core
Competencies - Coaching
• Self-organizing teams (LeSS prefers to call these
self-managing teams) often times find challenges
like:
• Being so used to work in a command & control environment
that they’re simply not prepare to self-organize
• A system previously design with job titles, career paths,
promotions, etc. that foster internal competition and jealousy
• Team members that were former managers that are used to
give orders and track progress but lack the skills to do
technical work

73. Scrum Master Core
Competencies - Coaching
• A simple technique that can help self-organizing teams to overcome
challenges consists in drawing a big X like this:
• And then asking team members to individually write post-its for each
dimension, then collectively review and discuss the pos-its
Stop doing Start doing
Let go
Start believing in

74. Service to the Development
Team
• Servant-leadership basically inverts the
tradicional hierarchical pyramid in which
workers serve the manager; instead the
aim for the servant-leader is to serve the
workers so they can develop their true
potential and enrich their lives
• The SM is more align with this servant-
leadership style

75. Service to the Development
Team
• The SM acts as a servant-leader for the Development
Team when she:
• Is a good listener and always be there for whoever that
wants to talk
• Helps people to remove their impediments
• With intellectual humility acknowledges that she
doesn’t know something but wants to learn
• Asking dumb questions that everybody is afraid to ask

76. Scrum Masters
are not ego-
driven
individuals
that try to
give orders to
others
Photo by fede 1845

77. 77
Warning: being a servant
leader doesn’t mean
updating everybody’s
cards on a taskboard or
always speaking for the
team in meetings

78. Service to the Development
Team
•The SM as a servant-leader can improve the
volunteering aspect of the team, a typical scenario (in
Scrum but not in LeSS) is when during the Sprint
Planning Two no one volunteers to take on a task and
the SM put his name forward even though she
doesn’t have the particular knowledge but is willing to
learn
•By showing this as a repetitive behavior other team
members will eventually imitate it and find that is
rewarding to volunteer, learn and have the
appreciation of the rest of the team

79. Service to the Development
Team
• There are situations in which the PO or an
stakeholder wants to put pressure on the
team to speed up implementation
• One way to deal with the situation is to invite
the PO or stakeholder to analyze the impact
in other variables (like quality, motivation,
and collaboration) if the Development Team
focuses in only going faster

80. Service to the Development
Team
• Quick and dirty implementations introduce what is call
technical debt that is like an analogy connected to the
financial world
• Technical debt accumulated by the team eventually will
need to be repaid and the more that the teams takes in
repaying it the more interest it will accumulate
• Code that works but is not well crafted is a common form
of technical debt, not refactoring that code will eventually
stop it from running and fixing it months or years down
the road will be too costly

81. Service to the Development
Team
• Not knowing how to craft code that doesn’t introduce
technical debt can be seeing as a form of knowledge
debt
• Organizations that are OK with just having code that just
runs without caring if the code will cause trouble later or if
the developers didn’t learn anything new by writing it,
present a form of organization debt
• Part of the job of the SM is to create awareness about
these forms of debt and how to start repaying them

82. Service to the Development
Team
•eXtreme Programming development practices were proposed
more than 20 years ago and they can (if used with discipline)
help the team to reduce technical debt and craft a high-quality
product increment
•Some of the more relevant XP practices are:
• Test Driven Development
• Continuous Integration
• Refactoring
• On-site Customer
• Small Releases

83. Service to the Development
Team
• Development practices may impact the ability of the
Development Team to deliver a potentially releasable
increment each Sprint in the following ways:
• By building automated test that can execute in minutes
multiple times a day guaranteeing that we have a tested
integrated product
• By incorporating the latest technical skills and
knowledge of the developers in the code via refactoring
• By incorporating shorter and shorter feedback loops via
small releases that on-site customers can evaluate

84. Service to the Product
Owner
• The PO can use several collaboration techniques to work
with the the Development Team or stakeholders,
techniques such us:
• Help the team to see the big picture about the product that
they’re building by creating together a Product Roadmap
• Discover what will go into the product with the
stakeholders using User Story Mapping
• Also with the stakeholders collaborate on strategic
planning using Impact Mapping

85. Service to the Product
Owner
• The SM could support the PO by:
• Advising senior management to implement necessary
changes like conferring full product authority to the PO
• Encouraging the Develpment Team to work frequently
and consistently with the PO in the Product Backlog
• Helping her to select the simplest but effective tools for
her work

86. Service to the Organization
• The SM can help the team responding to impediments
by:
• Constantly asking personally and in the Daily Scrum if
there are any impediments
• Keeping impediments somewhere visible for the team,
like in a flip chart or somewhere on the wall
• Helping team members talk about impediments and
possible mitigations

87. Service to the Organization
• There are however some organizational impediments outside
the team that can affect its effectiveness, impediments like:
• Too much bureaucracy
• A command & control mentality that demands too many reports from
the team
• Imposed deadlines that were defined by someone external to the
team
• Pressure to meet deadlines sacrificing quality and affecting personal
lives
• Tendency to work by specialties siloing the knowledge

88. Service to the Organization
• Eventually Scrum will require an organization redesign
that will imply radical changes like:
• No more PMO and Project Managers
• No more QA Department
• No more pool of resources
• No more short term thinking and projects
• No more outsourcing that creates teams split in several
physical locations and time zones

89. Service to the Organization
• In Scrum the Product Owner tracks and reports on teams
work but only within the current Sprint boundaries
• In general we completely deviate from Taylorism and its
postulate that one creates the plan and the others just
execute it
• Some of the practices from project management can still
be done but they got to be done by the Scrum Team and
not by one single individual
• Remember: Scrum is team-centric

90. The SM is an
optimistic
individual that
believes that
things can be
changed for
better

91. Service to the Organization
• There are some stakeholder behaviors, that the Scrum
Master can help to develop, and that can support the
Scrum Team’s success, behaviors like:
• Being available, involve and closely collaborate with the
Scrum Team
• Understand that quality doesn’t come for free
• Don’t ask for every single feature in a product
• Acknowledge adaptiveness in the product development
cycle

92. Service to the Organization
• Conversely there are other stakeholder behaviors that don’t
support the Scrum Team’s success, behaviors such as:
• Fire a requirement and forget about it until months after
• Create proxy roles that introduce layers of separation from the
Development Team
• Insist on a fixed initial scope
• Ask for precise estimates
• Demand velocity

93. Service to the Organization
• If the organization adopts Scrum only partially then
it will be loosing benefits like:
• The redesign of the organization to incorporate modern
management
• Repaying technical, knowledge, and organization debt
• Developing people to their true potential
• Competitive advantage to other smaller but more agile
organizations

94. Books on Scrum

95. Books on eXtreme
Programming

96. Books on Toyota

97. Books on Lean

98. Books on Technical
Excellence

99. Books on Technical
Excellence

100. Books on DevOps

101. Books on Management

102. BIG Idea
102
LeSS is and
organizational design
framework and
systems thinking is one
of its pillars

103. Why LeSS?
1. Create a learning organization
2. De-scale the organization
3. Simplify with a barely sufficient
framework
4. Stick to the plot of:
>Increasing adaptability
>Increasing customer value
103

104. LeSS Framework
104

105. 105

106. @juanbandajara
slideshare.net/juanbanda2
www.percella.com
juanbandaonscrum.blogspot.com/