Intro On SDLC Models Agile Values Agile Principles Intro To Kanban, XP

Download as odp, pdf, or txt
Download as odp, pdf, or txt
You are on page 1of 27

About yesterday ?

● Intro on SDLC models


● Agile Values
● Agile principles
● Intro to Kanban, XP
Scrum Framework
● Scrum is a lightweight framework that helps people, teams and organization
generate value through adaptive solutions for complex problems.
● A key principle of Scrum is its recognition that during a project the customers can
change their minds about what they want and need, and that unpredictable
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 observed. Scrum Employs an iterative, incremental approach to
optimize predictability and control Risk.
● Scrum is based on lean thinking – which means creating more value for customers
with fewer resources.
Scrum Lifecycle
Scrum as Incremental & Iterative approach
● Traditional approach → Fully formed idea delivered big-bang.
● Incremental approach – Break the idea into pieces and deliver in pieces if
possible.
● Incremental & iterative approach – Start with what you know. Refine product
as you go by taking feedback from customers.
Incremental & Iterative
Pillars of Empirical Process Control
Transparency
● 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. In Scrum, transparency is depicted through:
● Artifacts
1. Project Vision Statement
2. Prioritized Product Backlog
3. Release Planning Schedule
● Meetings
1. Sprint Review Meetings
2. Daily Standup Meetings
● Information Radiators
1. Burndown Chart
2. Scrumboard

Inspection
Inspection in Scrum is depicted through:
● Use of a common Scrum board 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
● 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.

Adaptation in Scrum is depicted through:


1. Stand-up Meetings
2. Constant Risk Identification
3. Change Requests
4. Retrospect Sprint Meeting
Scrum Values
Fail Fast, Fail Often, Fail Safe
● Scrum is based on fail-fast model
Encourages failures – not discourage them.
● If you do not fail how will you learn ?

● If you make mistake then it is a great opportunity to learn from


mistakes(INSPECT) and Adapt quickly.
● In empirical process control, you can take decisions based on
what you observe.
Scrum Artifacts
● Product Backlog
An ordered list of everything that is known(this moment) to be needed
in product

● Sprint Backlog
Set of product backlog items (PBI) selected for the Sprint, plus a plan
for delivering the product increment.

● Increment
Sum of all PBI completed during a Sprint and the value of the
increments of all previous Sprints.
Scrum Team
● Product Owner
Responsible for maximizing the value of the product resulting from
work of the developers

● Developers
Consist of professionals who do the work of delivering a potentially
releasable Increment of “Done” product at the end of each Sprint.

● Scrum Master
Servant leader who is responsible for promoting and supporting Scrum
as defined in the scrum guide. The coach, facilitator and Change agent
for the scrum team and organization.
Scrum Events
Each event in Scrum is a formal opportunity to inspect and
adapt something. These events are specifically designed to
enable critical TIA.
● Sprint
Time-box of one month or less during which a ‘Done’, usable product
increment is created.
Sprint is container for the other 4 events.
● Sprint Planning
The work to be performed in the sprint is planned at the sprint planning.
● Daily Scrum
Developers uses the daily scrum to inspect progress towards the sprint goal
and inspect how progress is trending toward completing the work in Sprint
backlog
Scrum Events...
● Sprint Review
is held at the end of the sprint to inspect the increment and adapt the PB if
needed. The scrum team and stakeholders collaborate about what was done
in the sprint
● Sprint Retrospective
An opportunity for scrum team to inspect itself and create a plan for
improvements to be enacted during the next Sprint.
Scrum Team
● Scrum team is a fundamental unit of Scrum.

● Consists of a Product owner, a Scrum master and set of Developers.

● Cohesive unit of professionals focused towards ONE product goal at


a time.

● Responsible for stakeholder collaboration, verification, maintenance,


operations, experimentation, R&D etc.

● Scrum team should maintain sustainable pace to ensure focus and


cosistency.
Scrum Team Size
● Less than 10 people.

● Small enough to remain nimble and Large enough to complete


significant work.

● Very small team decreases interactions.

● Larger scrum teams should consider re-organizing into smaller


teams sharing a product goal, product backlog and Product
owner.
Scrum team characteristics

● Self-Managed - They decide how to turn Product Backlog Items into


working solutions.
● Cross-functional - As a whole, they've got all the skills necessary to
create the product Increment.
● Empowered - Committed to achieving the Sprint Goal and delivering
a high-quality increment

● No titles. Everyone is a Developer, no one has a special title.


● No sub-teams in the Development team.
Self Managed

● Team is aligned by the Goals.


● Autonomy in execution
● No people managers
● Autonomy of work selection
● Autonomy in tracking its own work.
● Self managed team should act like self governing autonomous
body toward common goal.
Product Owner
● Single person, and may represent desires of committee or
stakeholders.
● Product owner has a authority over product backlog, as he is single
point of accountability of the product.
● A product owner may delegate the responsibility to anyone else, but
the product owner remains accountable.
● If scrum team becomes too large, they should consider reorganizing
into multiple cohesive Scrum Teams, each focused on the same
product. Thereby, they should share same Product Goal, Product
Backlog, Product Owner.
Product Owner Collaboration with developers
● Explains the functionality
● Being available
● Ongoing review and feedback.
● Agree a clear & concise DoD with Developers.
● Keep Product Backlog in healthy state.
● Cannot over-ride team’s sizing & commitments.
● Avoid frequent sprint tweaks, which puts pressure on developers.
This may decrease morale, reduce quality and DoD may not be met.
Product Owner Collaboration with Stakeholders
● Highest ROI for the product.
● Get commitment from sponsor on budgets.
● Discuss programm level dependencies.
● Get feedback.
● Adapt product backlog.
Developers
Create ‘Usable’ product increment every sprint.
● Creating a plan for the sprint, the sprint backlog.
● Adapting their plan each day towards Sprint goal.
● Sizing the work.
● Holding each other accountable as professionals.
● Instilling quality by Adhering to DoR & DoD.
Scrum Master
● Ensure Scrum is understood and enacted.
● Ensuring scrum team is effective, and scrum practices are
implemented.
● Removal of impediments.
● Ensure scrum events take place.
● Ensure that the scrum events completes on time.
● He is a servant leader, should also focus on Growth and well being of
people.
Quiz - Accountabilities
1. Maximizing the value of the product ?

2. Sizing the day to day work ?

3. Ordering the items in the Product Backlog ?

4. Recruitment and people on-boarding ?


Quiz - Accountabilities
5. Creating a valuable, useful increment every
sprint ?

6. Managing budgets ?

7. Creating plan for sprint and sprint backlog?


Thank you

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy