SCRUM MASTER FUNDAMENTALS-FOUNDATIONS (Coach: JEREMY JARRELL)

1. Scrum Master Fundamentals

• Foundation of Scrum
• Sprint as as building blocks
• Core values of Scrum

Agile	Scrum
Agile is philisopy. It is best approach shipping software, but gives no specific recommendation about on how to do so.	It is specific framework for managing software projects.

1.1 The agile manifesto (Agile Beginning)

• Individuals and interaction over processe and tools
  • There must be simply communication between teams and client
• Working software over comprehensive documentation
  • Documentation does not add value if there is no corresponding working software. Documentation is not the goal, working software is.
• Customer collaboration over contract negotiation
  • keep align the team and customer to deliver the project that provides most value to the customer at the time of the delivery, not at the time when the contract was written.
• Responding to change over following a plan
  • Focuses on change that might/ or happens during the course of project development. Changes can be anything (changes of requirement, funding, teams etc). Simply adapt the way of working to meet it.

1.2 The Roots of Scrum

• Empiricism
  • U will know something because of your past experience

1.3 Three legs of empericism

Scurm is a framework not a process

Process	Framework
Step by step guidance	Definition of key tasks and routine
Repeatable from projects to projects i,e process would be repeatable	Non perscriptive i,e 2 weeks define gareko huncha, the things that u do depends on yr plan, The way how yr team builds software is left entirely upto you

SCRUM FRAMEWORK + YOUR ENVIRONMENT =  YOUR PROCESS

HENCE YOUR SCRUM IS NOT MY SCRUM

Three legs of empiricism

• INSPECT
  • U need to inspect both the project and process
  • U need to look for variances
  • Strike the right balance
• ADAPT
  • Reduce what isnt working, increase what is
  • Introduce changes at the right time
  • Adapt the process to serve the project
• TRANSPARENCY
  • Make your pace and progress visual
  • Encourage openness across the team
  • Share clear status across team boundaries (what is done todo board)

SCRUM DOES NOT SOLVE YOUR PROBLEMS

SCRUM ENABLES YOU TO SOLVE YOUR PROBLEMS

1.4 What about engineering?

• Scrum does not address any enginnerring practises
• Focus is entirely on project management principles
• Most high performing teams adopt XP along side of scrum

1.5 Moving on (References)

• Agile manifesto
  • www.agilemanifesto.org
• Scrum Guide
  • www.scrumfuides.org
• Xp
  • Explained Embrace Change (Kent back and Cynthia Andres)

2. Getting the most from your sprint

2.1 Incremental vs iterative delivery

Incremental	Iterative
Small increments of the project are delivered piece by piece until the entire project is completed	Deliver small functional increments, but take it a step further to elicit clear and constructive stakeholder feedback afer each increment and adjust course accordingly
After each increment is delivered, stakeholder have opportunity to provide feedback on the newest increments as well as the product as the whole

• Breaks a larger project into smaller deliveries
• Can reduce the overall effort.
• Reduce the impact of costly mistakes before the project is handovered.
• Incorporates feedback along the way
• For scrum to be successfull, both of these traits are equally important.

2.2 Timeboxing

• Scrum helps team to timebox their work effectively through SPRINTS
• SPRINT is the fixed timebox in which SCRUM team attempts to deliver a batch of work that they have selected at the beginning of the timebox. Often defined in 1-4 weeks.
• At the end of the time-box, the team reiews their progress with their stakegholders and makes any neccessary adjustment in the next sprints

Feature increaments vs sprint increments

Feature Increments	Sprint Increments
Features not sized consistenty	Feedback occurs more regularly
Features comes uneven	Encourages stakeholders to give more frequent feedback
May not receive feedback on all features	Easier to coordinate

How long should be SPRINT be?

• As short as 1 week duration (least duration)
• 2 weeks in duration (most common sprint duration)
• As long as 30 days in duration (this is the upper limit)

Shorter sprints vs longer sprints

• Shorter sprints

  • Easier but more frequent planning.
  • Better ability to reduce risk
  • more frequent reviews, planning sessions and opportunities to adapt in general

• Longer sprints

  • More difficult but infrequent planning will incure more risk

While travelling u either take small steps and review with the map, or take huge steps that can lead to deadend. But if the path is clear, its better to review at greater steps. Hence, it all depends on the nature of the project.

2.3 Definition of Done

• Make sure that the team and stakeholders are on the same page.
• How many items a team is doing in each sprint?
• It is better to implement one set of peer review

2.4 Potential shippable product increments

• Product Increment
  • Team has produced something of value that can be added to the product.
  • It can be entirely new feature of enhancement to the existing feature

2.5 Moving on

• Creating Effective User Stories (By Jeremy Jarrell)
• Continuous Delivery: Reliable Software Releaeses through Build, Test and Deployment Automation (By Jez Humble and David Fareley)

3. Where Scrum Fits

3.1 Five values of Scrum

• Focus
  • As team begins to multi task, the quality of the work starts to drop and the time it takes to complete that works takes longer. Scrum encourages us to focus to only a few things at a time so that we can give each item the attention it deserves, thus producing higher quality of work.
  • Limit the number of items in progress
  • Break a large project into smaller projects
• Courage
  • Result of Scrum's collaborative nature
  • Team should be supporting each other
  • Cross functional team works closely together, increasing their overall capability
  • This allows team to have better courage to take challenges
• Openness
  • Regular review of work with stakeholders
  • Regular planning exercises with their peer
  • Transparent commnunication with their peers
  • Sharing of project plans and metrics with the wider organisation
• Commitments
  • Producing the highest quality work possible
  • Always being transparent about the true status of each item with stakeholders
  • Commiting to a specific amount of work at the beginning of each sprint
• Respect
  • Team showing respect to each other in daily interaction
  • Full transparency both within and across team boundaries

3.2 Which env is Scrum Best Suited For?

3.3 Wrapping up

Well suited	Not well suited
high amount of complexity	priorities changes daily
aggressive deadlines	team composition changes regularly
high level of risk	transparency is not encouraged

If your organisation doesnt like truth and honesty, it probably won't like AGILE