SlideShare ist ein Scribd-Unternehmen logo
1 von 45
Agile SW Development
with Scrum
http://tiny.cc/RcgcB
Aniruddha Ray
Presumptions
Audience is (well) aware of traditional SDLC methods
1)Waterfall Model
2)V Model
3)Spiral Model
4)Iterative Development (RUP)
And concepts like:
1)Requirements Traceability
2)Use Cases
3)Unit testing
Introduction
Learning Driven
Continuous Team Communication
Deliver in Short, Business-Focused
Phases, Typically 2 – 3 Months
Develop in End-to-End Functional Slices
Continuously Integrate Code
Throughout (Daily Builds)
Fully-Automated, Continuous Testing at
Both Functional and Unit Level
Low Cost of Change
Plan Driven
Infrequent Team Communication
Deliver Once in “Big Bang” Fashion,
Typically 9 – 12 Months
Develop in Layers: Presentation,
Persistence, Business, etc.
Integration of Different Layers Occurs
at End of Build Phase
Testing as Separate Phase at End of
Project, Emphasizing Functional Level
High Cost of Change
Waterfall Agile
Attempts to Nail Down Requirements
Expects, accommodates Changes
to Requirements
What is Agile ?
Agile proponents believe
Current software development processes are too heavyweight or cumbersome (Too many
things are done that are not directly related to software product being produced)
Current software development is too rigid
Difficulty with incomplete or changing requirements
Short development cycles (Internet applications)
More active customer involvement needed
Agile methods are considered
Lightweight
People-based rather than Plan-based
Several agile methods
No single agile method or definition
XP most popular in Development
Scrum most popular in Project and Delivery Mgmt
Agile Manifesto closest to a definition
Set of principles
Developed by Agile Alliance
The Agile Manifesto
A Statement of Values
We are uncovering better ways of developing software by doing it and helping
others
do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
While there is value in the items on the right, we value the items on the left
more.
Key signatories:
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn
Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith
Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
http://www.agilemanifesto.org
Agile Principles
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness
change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need,
and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts
its behavior accordingly
Agile Methods
Major Methods
Scrum – Ken Schwaber and Jeff Sutherland
Extreme Programming – Ron Jeffries and Kent Beck
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
Lean Software Development – Mary Popendieck
Other Methods
Kanban for SW Development
Feature Driven Development (FDD)
Crystal Framework – Alistair Cockburn
IUP (and RUP done with Agile Principles) – IBM (Rational)
Agile Modeling (Agile Data) – Scott Ambler
Agile In Practice
Focus on business value
Work together closely as one team
Work in short iterations
Inspect and Adapt
Remove waste ruthlessly (wasted effort, wasted time)
Deliver working software early and often
Scrum in 100 words
Scrum is an agile process that allows us to focus on delivering the highest
business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every
two weeks to one month). – INSPECT and ADAPT
The business sets the priorities. Our teams self-manage to determine the
best way to deliver the highest priority features.
At every (pre-decided) frequency (two weeks to a month) anyone can see
real working software and (decide to release it as is or) continue to
enhance for another iteration.
The iterations (Sprints) are Time-Boxed.
A Short History of Scrum
1995:
- Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber
- Enhancement of Scrum by Mike Beedle & combination of Scrum with XP
1996:
- Introduction of Scrum at OOPSLA conference
2001:
- Publication “Agile Software Development with Scrum” by Ken Schwaber & Mike
Beedle
2005:
- Scrum and XP were the most popular Agile frameworks implemented
(a lot of times Hand in hand)
2009:
- Scrum is the single most popular Agile implementation.
With popularity there is criticism or frustration of failure in some cases (Scrum-
But)
The Power of Scrum
More business value delivered sooner
Better return-on-investment for projects
Greater visibility – to team and customers (also –
Management)
Improved productivity – People, Process
Less waste – Lean mindset
Higher quality – Inspect and Adapt Frequently
Stronger teams – focussed, decisive, self managing
Better morale across the whole team - camaraderie
Engineering processes improved significantly
The critical features built at the quickest time at the
minimal cost
The Dangers of Scrum
It’s hard!
It requires significant change
It makes all dysfunction visible
- Scrum doesn’t fix anything: the team has to do it
- You may see things you don’t want to see
It demands honesty and transparency
Bad products will be delivered sooner, and
doomed projects will fail faster
Partial adoption may be worse than none at all
Be forewarned: many Scrum adoptions fail
Scrum in a Page
The Operating Model
“Self-managing or self-organizing” teams – no decision from
anyone else.
Product progresses in a series of month-long “sprints” –
TimeBoxed
Requirements are captured as features/stories in a “product
backlog” – One version of truth
Features are prioritized (by Business value or any other
parameter) by single Owner
At the end of every sprint team should demo a “potentially
shippable product”.
No specific engineering practices prescribed – team selects the
necessary tools and practices (can select from other Agile FW)
One of the many “agile” frameworks – TEAM takes best practices
from others if they want BUT for the RIGHT reasons
Characteristics
“MUST HAVE”
Teams have a dedicated PO and SM
SM is co-located with team
Team have a Scrum/War room.
Time Boxing of Sprints.
Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management)
Sprint Demo at the end of every sprint
No one changed PBL except PO
Team decides the scope of Sprints.
“GOOD TO HAVE”
Teams of sizes 5-7
Co-located teams and “war room”
Tie up with Engineering specific from XP (Test Driven Development, Refactoring)
Minimum Documentation (as per need)
SM not the People Manager or Traditional Manager
No management influence on team. Coaching from SM.
PO co-located with Team
Scrum Framework
Roles :
Product Owner, ScrumMaster, Team
Ceremonies :
Sprint Planning, Sprint Review, Sprint Retrospective, &
Daily Scrum Meeting
Artifacts :
Product Backlog, Sprint Backlog, Burndown Chart, Velocity
Chart
Product Owner
Responsible for maximizing the project’s ROI
Creates high-level vision (MRD or PRD???)
Creates a prioritized list of features (the Product Backlog) –
decides on parameter of prioritization
Final decision-maker on the Product Backlog – one version
of truth!!
Evolves the Product Backlog from Sprint to Sprint
Helps the team be effective, by removing waste (like
impediments and distractions) and supporting the team’s
Scrum practices and efforts to improve.
Can interact with customers, management or others to
refine product vision.
Single point of reference for team on ANY product related
issue.
Scrum Master
Serves the Team
Helps the Team remove obstacles and problems (“blocks”)
Facilitates interactions within the Team, and between the Team and
Product Owner
Protects the Team
Protects the team from outside disruption or threats
Coaches the Team
Helps the Team and Product Owner improve the effectiveness of
their practices
Helps the Team and Product Owner face and resolve difficult or
uncomfortable issues
Guides the skillful use of Scrum
Teaches Scrum to the Team, Product Owner, and company
Ensures that all standard Scrum practices are followed
Avoid having the team’s manager be ScrumMaster
Try having full time ScrumMaster for best results
Scrum Team
Typically 7 (+ or – 2) people
Co-located
100% dedicated to sprint (minor exceptions – Sys-Admin etc)
Cross-functional
QA, Programmers, UI Designers, etc.
Includes all the skills necessary to produce an increment of
potentially shippable product
Team takes on tasks based on skills, not just official “role”
Teams are self-organizing and self managing
What to do if a team self-organizes someone off the team??
Ideally, no titles but rarely a possibility
Team decides how much to commit to in a sprint
Team works together to manage and complete the work to achieve
the goal
Membership can change only between sprints
Ceremonies
Project Kickoff Meeting
Sprint Planning Meeting
Product Backlog Refinement Meeting
Sprint Review Meeting
Daily Scrum
(Scrum of Scrums) – for bigger teams
Sprint Retrospective Meeting
Project Kickoff Meeting
A special form of Sprint Planning Meeting – Optional.
Meeting before the begin of the Project – 1 day of
effort.
Team (or a smaller core) may go through the product
vision and entire backlog at higher level
Helps in understanding the big picture – reviewing
priorities and identifying dependencies/assumptions.
May result in first cut of High Level estimates or minor
refinements/changes in PBL (only PO will do it)
Sprint Planning Meeting
1st Part:
Creating/Refining Product Backlog (Edits, Reprioritization)
Determining the Sprint Goal.
Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog
Discussing, Noting details on each scoped feature
Dependencies/Assumptions (P.O available on call for
discussion)
Note: ScrumMaster facilitates the meeting and protects the team from
pressure
Spring Planning Meeting
Suggested Steps
1) Team calculates how much time it will have
available during the Sprint
2) Team takes first item from Product Backlog and breaks it
into tasks
3) Team estimates how long the tasks will take (take care
of all planned activities, definition of DONE and buffer)
4) If there’s available time remaining, move to the next
item on Product Backlog and repeat 1-3
5) Finalize the features which have clarity and estimates
and decide on how many to be scoped for sprint.
Spring Planning Meeting – Input Output
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Backlog
Sprint Goal
Sprints
Scrum projects make progress in a series of “sprints”
Analogous to XP iterations
Target duration is pre decided. Scrum suggests 2
weeks to one month
a constant duration leads to a better rhythm
Once decided Sprint duration MUST not change
Product is designed, coded, and tested during EACH sprint
EACH sprint should end in a potentially shippable code.
Scope DOESNOT change within a sprint.
Team may decide to push unfinished items to next sprint.
PO can decide to CANCEL a sprint midway and restart (in
special cases)
What is A Sprint
A 2 - 4 week long iteration, during which team
increments the product functionality
NO outside influence can interfere with the Scrum team
during the Sprint
Each Sprint begins with the Kickoff meeting
Daily Scrum Meeting conducted throughout the sprint.
Each Sprint ends with a sprint demo and retrospective.
Sprint duration or scope is immutable (unless critical
business change happens)
Sometimes teams may have intermediate Sprint review
meetings (to discuss/pre-plan items of next sprint if it
helps)
Sequential vs. Overlapping Dev.
Requirements Design Code Test
Scrum Meeting
Goal of the Scrum Meeting
Keep team coordinated and up-to-date with each other
Surface “blocks” or problems daily
Key Parameters
Daily (fixed time)
15-minutes or less (no more)
Stand-up
Not for problem solving
Only SM and Team
Three questions for everyone:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?
“Chickens” and “Pigs” – Only “Pigs” can talk
Help avoid other unnecessary meetings
No discussion until after meeting ends
After meeting SM will help remove the blocks and find solutions to problems.
Scrum Meeting – FAQs
Is NOT a problem solving session
Is NOT a way to collect information about WHO is behind the schedule
Is a meeting in which team members make commitments to each other and to
the Scrum Master
Is a good way for a Scrum Master to know (Track?) the progress of the Team
Is THE meeting for a Scrum Master to know what is blocking the Team.
• Why daily?
– “How does a project get to be a year late?”
• “One day at a time.”
– Fred Brooks, The Mythical Man-Month.
• What if all team members are not present
– WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure?
• Can Scrum meetings be replaced by emailed status reports?
– No
• Entire team sees the whole picture every day
• Create peer pressure to do what you say you’ll do
Sprint Review Meeting
Goal
Get hands on with what’s been built
Inspect the quality
Come up with ideas for improvements
See whether the commitment was completed
Team presents what it accomplished during the
sprint
Typically takes the form of a Demo of new features
No PowerPoint Demo
Informal
2-hour prep time rule
2 hour demo time
Participants – EVERYONE
Informal and Fun
Sprint Retrospective Meeting
Goal
Find ways to improve the team’s way of working in the next
Sprint
Participants: SM and Team only
Product Owner and managers should join for part (but not all) of
the Retrospective
Team needs time to talk by itself
Feedback within team and self correcting decisions – SM to check
that there is no outside imposition.
Three questions (optional 4th)
Start - What are worth trying
Stop – What are waste and should be stopped
Continue – What went well
Escalation/Risk List to Upper Management.
Don’t skip ever (Critical for the first 5-6 sprints!!!)
Product Backlog Refinement –
Optional
Optional Meeting – Worked well in some cases
Goal:
During the Sprint, plan to spend ~5% of your available time
doing Product Backlog Refinement
(also known as Product Backlog Grooming)
Team and Product Owner sit down and look ahead at
Product Backlog Items for upcoming Sprints
Team asks questions and clarifies requirements for
upcoming items
Team suggests items to add to the Product Backlog
Team starts to think about how they’re going to
implement the items (at a high-level)
Product Backlog
A list of all desired work on the project
Usually a combination of
story-based work (“let user search and replace”)
task-based work (“improve exception handling”)
List is prioritized by the Product Owner
Typically a Product Manager, Marketing, Internal Customer, etc.
• Requirements for a system, expressed as a prioritized list of Backlog Items
• Is managed and owned by a Product Owner
• PO Can use MOSCOW tool to prioritize.
• Can be a Spreadsheet (typically) or any other report
• Usually is created during the first Sprint Planning Meeting or Project
Kickoff Meeting
• Should be changed/updated and re-prioritized before each Sprint
Planning Meeting.
• Product Backlog will have all features (including non- functional
requirements)
From Sprint Goal to Sprint Backlog
Scrum team takes the Sprint Goal and decides what
tasks are necessary
Team self-organizes around how they’ll meet the Sprint
Goal
Manager doesn’t assign tasks to individuals
Managers don’t make decisions for the team
Sprint Backlog is created
Estimates are done by the team (best practice:
Wideband Modified Delphi method)
Sprint Backlog
A subset of Product Backlog Items, which define the
work for a Sprint
Is created ONLY by Team members
Each Item has it’s own status
Should be updated every day
No more than 300 tasks in the list
If a task requires more than 16 hours, it should be
broken down
Team can add or subtract items from the list. Product
Owner is not allowed to do it
Sprint Backlog during the Sprint
Changes
Team adds new tasks whenever they need to in order
to meet the Sprint Goal
Team can remove unnecessary tasks
But: Sprint Backlog can only be updated by the team
Estimates are updated whenever there’s new
information
Scalability of Scrum
A typical Scrum team is 6-10 people
Jeff Sutherland - up to over 800 people
"Scrum of Scrums" or what called "Meta-Scrum“
Frequency of meetings is based on the degree of coupling
between packets
Confused about Scrum?
How much Documentation: Scrum does not specify. Team decides (what’s
best for the project)
What are user stories: short, plain-language description of the feature, in
terms of customer value
What are 3 C’s: Card, Confirmation and Conversation. It’s a common model
for requirements/story analysis.
How do we estimate in scrum: Scrum doesn’t specify. Only suggestion is
to have 2 level of estimates – high level at PBL (may be Points) and low level
at Sprint BL (may be Hours). Also, ONLY the team decided on estimates.
Do we really need to release every sprint – 2 common approach -
Release every sprint and multi sprint release. Do what gives maximum
business benefit
How can team scope the sprint – Team is COMMITING to delivery. So they
should scope (Note: They may over or under-commit in initial sprints but with
the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing
trend would continuous under or over-commitment)
Why should we track Velocity: The team needs to find a Self-sustaining
pace and confidence in commitment. Velocity provides the trend to them.
(Note: Velocity IS NOT for management to track)
Scrum EXPOSES Organization Impediments
Process
People arrive late to daily scrum and do not support basic discipline
Scrum meetings take too long – team is bred and considers the tie unproductive
Scrum master dictates design decisions or micromanages
Teams are too large for effective daily scrum and sprint planning
Teams do not report task-remaining time for burn-down analysis
People
Individuals are interrupted and tasked to work outside the sprint
Teams are isolated in cubicles and not in open scrum area
Teams members are not accountable for personal sprint commitments
Individuals are multiplexed across too many projects and teams.
Product
Cross-functional resources for definition, design, implementation, and test are not present on the team
Sprints do not fully implement and test potentially deployable increments of customer-valued features.
Product owner is not easily available or not integral to team
System integration is not forced at each sprint
Product owner won’t split up massive product backlog items to fit within a sprint
Team have ineffective resources for automating builds and integrations
Features are loaded into sprints after sprint begins
Thank You !!!
Burn Down Charts
Sprint Burndown
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Actually is not a straight line
• Can bump UP and DOWN
• Ideally should burn down to zero to the end of the Sprint
Release Burndown
• Will the release be done on right time?
• X-axis: sprints
• Y-axis: amount of hours remaining
• The estimated work remaining can also burn up
Product Burndown
Is a “big picture” view of project’s progress (all the releases)
Agile SW Dev – XP and RUP
Key characteristics of XP include
A team of five to ten programmers, co-located with customer representation on site.
Development with frequent builds and iterations, each of which is releasable and delivers
incremental functionality.
Requirements are specified as stories, each a chunk of new functionality the user requires.
Programmer work in pairs, follow strict coding standards, and do their own unit testing.
Requirements, architecture, and design emerge over the course of the project
Key characteristics of RUP include (Modified to IUP)
RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception,
elaboration, construction, and transition
RUP provides a SW development method and a set of software engineering practices that cover
the majority of SW development disciplines.
RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each
is determined in part by the life cycle phase.
RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software
application evolves in this fashion with the benefit of regular and continuous feedback.
Agile SW Dev – DSDM and Lean
Key characteristics of DSDM include
Active user involvement
The team is empowered to make decisions
The focus is on frequent delivery of products
Fitness for business purpose is the essential criterion for acceptance of deliverables
Iterative and incremental development is necessary to converge on an accurate business solution.
All changes during development are reversible
Requirements are base-lined at a high level.
Testing is integrated throughout the life cycle.
Collaboration and cooperation between all stakeholders is essential
Key characteristics of Lean Software include
Reduced work in process inventory – Reduced investment in elaborated requirements, documented
designs
Reduced Cycle time – Build all software in much smaller lots
Cross-training and cell-based manufacturing – Increase cross-training with pair programming and
shared code assets. Have developers write tests as part of their code
Continuous Process Improvement – Continuous reflection and adaption
Scalability of Scrum
Does This Ring A Bell?

Weitere ähnliche Inhalte

Was ist angesagt?

Agile Scrum Training Process
Agile Scrum Training ProcessAgile Scrum Training Process
Agile Scrum Training ProcessClarion Marketing
 
Agile presentation
Agile presentationAgile presentation
Agile presentationinfolock
 
Agile Methodology in Software Development
Agile Methodology in Software DevelopmentAgile Methodology in Software Development
Agile Methodology in Software DevelopmentRaghav Seth
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumArrielle Mali
 
Agile Scrum Methodology
Agile Scrum MethodologyAgile Scrum Methodology
Agile Scrum MethodologyRajeev Misra
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development processjhericks
 
Agile In 5 Minutes
Agile In 5 MinutesAgile In 5 Minutes
Agile In 5 MinutesHenry Jacob
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overviewsunilkumar_
 
Agile Scrum software methodology
Agile Scrum software methodologyAgile Scrum software methodology
Agile Scrum software methodologyAbdullah Raza
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile MethodologyNiel Deckx
 
Introduction to Agile Software Development
Introduction to Agile Software DevelopmentIntroduction to Agile Software Development
Introduction to Agile Software DevelopmentLife Cycle Engineering
 
Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedPrashaanth T R
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)CollectiveKnowledge
 

Was ist angesagt? (20)

Agile Scrum Training Process
Agile Scrum Training ProcessAgile Scrum Training Process
Agile Scrum Training Process
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Agile Methodology in Software Development
Agile Methodology in Software DevelopmentAgile Methodology in Software Development
Agile Methodology in Software Development
 
Agile (Scrum)
Agile (Scrum)Agile (Scrum)
Agile (Scrum)
 
Scrum
ScrumScrum
Scrum
 
SCRUM – Agile Methodology
SCRUM – Agile MethodologySCRUM – Agile Methodology
SCRUM – Agile Methodology
 
Scrum 101: Introduction to Scrum
Scrum 101: Introduction to ScrumScrum 101: Introduction to Scrum
Scrum 101: Introduction to Scrum
 
Agile Scrum Methodology
Agile Scrum MethodologyAgile Scrum Methodology
Agile Scrum Methodology
 
Scrum and the agile development process
Scrum and the agile development processScrum and the agile development process
Scrum and the agile development process
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
 
Agile sdlc
Agile sdlcAgile sdlc
Agile sdlc
 
Agile In 5 Minutes
Agile In 5 MinutesAgile In 5 Minutes
Agile In 5 Minutes
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
Agile Scrum software methodology
Agile Scrum software methodologyAgile Scrum software methodology
Agile Scrum software methodology
 
Scrum In 15 Minutes
Scrum In 15 MinutesScrum In 15 Minutes
Scrum In 15 Minutes
 
Scrum - Agile Methodology
Scrum - Agile MethodologyScrum - Agile Methodology
Scrum - Agile Methodology
 
AGILE METHODOLOGY
AGILE METHODOLOGYAGILE METHODOLOGY
AGILE METHODOLOGY
 
Introduction to Agile Software Development
Introduction to Agile Software DevelopmentIntroduction to Agile Software Development
Introduction to Agile Software Development
 
Agile Scrum Presentation-Detailed
Agile Scrum Presentation-DetailedAgile Scrum Presentation-Detailed
Agile Scrum Presentation-Detailed
 
Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)Another Scrum Cheat Sheet (great one pager)
Another Scrum Cheat Sheet (great one pager)
 

Andere mochten auch

High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
 
Agile Software Development With SCRUM
Agile Software Development With SCRUMAgile Software Development With SCRUM
Agile Software Development With SCRUMAlexey Krivitsky
 
Case Study on agile scrum methodology on shopping cart
Case Study on agile scrum methodology on shopping cartCase Study on agile scrum methodology on shopping cart
Case Study on agile scrum methodology on shopping cartAbdullah Raza
 
Overview of SDLC - Waterfall, Agile, and more
Overview of SDLC - Waterfall, Agile, and moreOverview of SDLC - Waterfall, Agile, and more
Overview of SDLC - Waterfall, Agile, and moreSteve Gladstone
 
Spiral model presentation
Spiral model presentationSpiral model presentation
Spiral model presentationSayedFarhan110
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanDimitri Ponomareff
 
Cd Networks Introduction V2.2 For Linked In
Cd Networks Introduction V2.2 For Linked InCd Networks Introduction V2.2 For Linked In
Cd Networks Introduction V2.2 For Linked Inscott_i_bishop
 
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the ugly
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the uglyAmit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the ugly
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the uglyAgileSparks
 
Birds Eye View on API Development - v1.0
Birds Eye View on API Development - v1.0Birds Eye View on API Development - v1.0
Birds Eye View on API Development - v1.0API Talent
 
Battelfield REST, API Development from the trenches
Battelfield REST, API Development from the trenchesBattelfield REST, API Development from the trenches
Battelfield REST, API Development from the trenchesDaniel Cerecedo
 
Design API using RAML - basics
Design API using RAML - basicsDesign API using RAML - basics
Design API using RAML - basicskunal vishe
 
API World 2016 - A five-sided prism polarizing Web API development
API World 2016 - A five-sided prism polarizing Web API developmentAPI World 2016 - A five-sided prism polarizing Web API development
API World 2016 - A five-sided prism polarizing Web API developmentRestlet
 
I Love APIs 2015 API Lab Design-first API Development Using Node and Swagger
I Love APIs 2015 API Lab Design-first API Development Using Node and SwaggerI Love APIs 2015 API Lab Design-first API Development Using Node and Swagger
I Love APIs 2015 API Lab Design-first API Development Using Node and SwaggerApigee | Google Cloud
 
Case study for agile software development:
Case study for agile software development: Case study for agile software development:
Case study for agile software development: Joe Crespo
 
Design-first API Development using Swagger and Node
Design-first API Development using Swagger and NodeDesign-first API Development using Swagger and Node
Design-first API Development using Swagger and NodeApigee | Google Cloud
 
Porque o scrum não vai resolver todos seus problemas
Porque o scrum não vai resolver todos seus problemasPorque o scrum não vai resolver todos seus problemas
Porque o scrum não vai resolver todos seus problemasVanessa Me Tonini
 
Introduction to scrum
Introduction to scrumIntroduction to scrum
Introduction to scrumSunny Poswal
 
Scrum Meetings Infographic v12
Scrum Meetings Infographic v12Scrum Meetings Infographic v12
Scrum Meetings Infographic v12Nigel Thurlow
 

Andere mochten auch (20)

High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and Scrum
 
Agile Software Development With SCRUM
Agile Software Development With SCRUMAgile Software Development With SCRUM
Agile Software Development With SCRUM
 
Case Study on agile scrum methodology on shopping cart
Case Study on agile scrum methodology on shopping cartCase Study on agile scrum methodology on shopping cart
Case Study on agile scrum methodology on shopping cart
 
Overview of SDLC - Waterfall, Agile, and more
Overview of SDLC - Waterfall, Agile, and moreOverview of SDLC - Waterfall, Agile, and more
Overview of SDLC - Waterfall, Agile, and more
 
Spiral model presentation
Spiral model presentationSpiral model presentation
Spiral model presentation
 
Introducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and KanbanIntroducing Agile Scrum XP and Kanban
Introducing Agile Scrum XP and Kanban
 
Cd Networks Introduction V2.2 For Linked In
Cd Networks Introduction V2.2 For Linked InCd Networks Introduction V2.2 For Linked In
Cd Networks Introduction V2.2 For Linked In
 
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the ugly
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the uglyAmit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the ugly
Amit Monovitch RSA Case Study - Agile SCRUM - The good, the bad and the ugly
 
Birds Eye View on API Development - v1.0
Birds Eye View on API Development - v1.0Birds Eye View on API Development - v1.0
Birds Eye View on API Development - v1.0
 
Battelfield REST, API Development from the trenches
Battelfield REST, API Development from the trenchesBattelfield REST, API Development from the trenches
Battelfield REST, API Development from the trenches
 
Raml api designer
Raml   api designerRaml   api designer
Raml api designer
 
Managing api development
Managing api developmentManaging api development
Managing api development
 
Design API using RAML - basics
Design API using RAML - basicsDesign API using RAML - basics
Design API using RAML - basics
 
API World 2016 - A five-sided prism polarizing Web API development
API World 2016 - A five-sided prism polarizing Web API developmentAPI World 2016 - A five-sided prism polarizing Web API development
API World 2016 - A five-sided prism polarizing Web API development
 
I Love APIs 2015 API Lab Design-first API Development Using Node and Swagger
I Love APIs 2015 API Lab Design-first API Development Using Node and SwaggerI Love APIs 2015 API Lab Design-first API Development Using Node and Swagger
I Love APIs 2015 API Lab Design-first API Development Using Node and Swagger
 
Case study for agile software development:
Case study for agile software development: Case study for agile software development:
Case study for agile software development:
 
Design-first API Development using Swagger and Node
Design-first API Development using Swagger and NodeDesign-first API Development using Swagger and Node
Design-first API Development using Swagger and Node
 
Porque o scrum não vai resolver todos seus problemas
Porque o scrum não vai resolver todos seus problemasPorque o scrum não vai resolver todos seus problemas
Porque o scrum não vai resolver todos seus problemas
 
Introduction to scrum
Introduction to scrumIntroduction to scrum
Introduction to scrum
 
Scrum Meetings Infographic v12
Scrum Meetings Infographic v12Scrum Meetings Infographic v12
Scrum Meetings Infographic v12
 

Ähnlich wie Scrum and Agile SDLC 101

Let’s Play Agile ! 12-09-15-testers_hub
Let’s  Play  Agile ! 12-09-15-testers_hubLet’s  Play  Agile ! 12-09-15-testers_hub
Let’s Play Agile ! 12-09-15-testers_hubOwner Tester's Hub
 
An Introduction to Scrum
An Introduction to ScrumAn Introduction to Scrum
An Introduction to Scrummbalas2
 
Agile Development with Scrum.pptx
Agile Development with Scrum.pptxAgile Development with Scrum.pptx
Agile Development with Scrum.pptxzuma14
 
Software Development Process Models (SCRUM Methodology)
Software Development Process Models (SCRUM Methodology)Software Development Process Models (SCRUM Methodology)
Software Development Process Models (SCRUM Methodology)Muhammad Ahmed
 
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...varty
 
Intro To Scrum
Intro To ScrumIntro To Scrum
Intro To Scrumscottycn
 
Introduction into Scrum
Introduction into ScrumIntroduction into Scrum
Introduction into Scrummsorin
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development OverviewDUONG Trong Tan
 
Dot+Net+2010+Features
Dot+Net+2010+FeaturesDot+Net+2010+Features
Dot+Net+2010+Featuresgurbaxrawat
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To ScrumErwin Verweij
 
Introduction to Agile & scrum
Introduction to Agile & scrumIntroduction to Agile & scrum
Introduction to Agile & scrumElad Sofer
 
CAI - Agile Scrum Development Presentation
CAI - Agile Scrum Development PresentationCAI - Agile Scrum Development Presentation
CAI - Agile Scrum Development Presentationdeyoepw
 
Introduction to Agile Project Management - Scrum 101
Introduction to Agile Project Management - Scrum 101Introduction to Agile Project Management - Scrum 101
Introduction to Agile Project Management - Scrum 101Marge Tam, PMP, CSM, A-CSM
 
Introduction to Scrum
Introduction to ScrumIntroduction to Scrum
Introduction to Scrumtimmcowan
 

Ähnlich wie Scrum and Agile SDLC 101 (20)

Let’s Play Agile ! 12-09-15-testers_hub
Let’s  Play  Agile ! 12-09-15-testers_hubLet’s  Play  Agile ! 12-09-15-testers_hub
Let’s Play Agile ! 12-09-15-testers_hub
 
An Introduction to Scrum
An Introduction to ScrumAn Introduction to Scrum
An Introduction to Scrum
 
Agile Development with Scrum.pptx
Agile Development with Scrum.pptxAgile Development with Scrum.pptx
Agile Development with Scrum.pptx
 
Software Development Process Models (SCRUM Methodology)
Software Development Process Models (SCRUM Methodology)Software Development Process Models (SCRUM Methodology)
Software Development Process Models (SCRUM Methodology)
 
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
Presentation: "Agile methodologies for Project Management - SCRUM" by Varty K...
 
Intro To Scrum
Intro To ScrumIntro To Scrum
Intro To Scrum
 
Introduction into Scrum
Introduction into ScrumIntroduction into Scrum
Introduction into Scrum
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
Agile
Agile Agile
Agile
 
Agile Scrum Methodology
Agile Scrum MethodologyAgile Scrum Methodology
Agile Scrum Methodology
 
Dot+Net+2010+Features
Dot+Net+2010+FeaturesDot+Net+2010+Features
Dot+Net+2010+Features
 
Agile
AgileAgile
Agile
 
Redistributable Intro To Scrum
Redistributable Intro To ScrumRedistributable Intro To Scrum
Redistributable Intro To Scrum
 
Agile project management
Agile project managementAgile project management
Agile project management
 
Introduction to Agile & scrum
Introduction to Agile & scrumIntroduction to Agile & scrum
Introduction to Agile & scrum
 
CAI - Agile Scrum Development Presentation
CAI - Agile Scrum Development PresentationCAI - Agile Scrum Development Presentation
CAI - Agile Scrum Development Presentation
 
Introduction to Agile Project Management - Scrum 101
Introduction to Agile Project Management - Scrum 101Introduction to Agile Project Management - Scrum 101
Introduction to Agile Project Management - Scrum 101
 
Introduction to Scrum
Introduction to ScrumIntroduction to Scrum
Introduction to Scrum
 
Introduction to agile
Introduction to agileIntroduction to agile
Introduction to agile
 
Seminar On Scrum
Seminar On  ScrumSeminar On  Scrum
Seminar On Scrum
 

Mehr von Aniruddha Ray (Ani)

3D Cameras - Evolution (Films to 3D) and Road Ahead
3D Cameras - Evolution (Films to 3D) and Road Ahead3D Cameras - Evolution (Films to 3D) and Road Ahead
3D Cameras - Evolution (Films to 3D) and Road AheadAniruddha Ray (Ani)
 
IIM A PGPX - 6th Batch - Snapshot
IIM A PGPX - 6th Batch - SnapshotIIM A PGPX - 6th Batch - Snapshot
IIM A PGPX - 6th Batch - SnapshotAniruddha Ray (Ani)
 
PGPX - One Day Theatre - Lessons
PGPX - One Day Theatre -  Lessons PGPX - One Day Theatre -  Lessons
PGPX - One Day Theatre - Lessons Aniruddha Ray (Ani)
 
TVS Suzuki JV Split - Analysis on Corp Governance
TVS Suzuki JV Split - Analysis on Corp GovernanceTVS Suzuki JV Split - Analysis on Corp Governance
TVS Suzuki JV Split - Analysis on Corp GovernanceAniruddha Ray (Ani)
 
Ani's Small World - 35 Revolutions Around The Sun
Ani's Small World  - 35 Revolutions Around The SunAni's Small World  - 35 Revolutions Around The Sun
Ani's Small World - 35 Revolutions Around The SunAniruddha Ray (Ani)
 
Containerization and India - Status
Containerization and India - StatusContainerization and India - Status
Containerization and India - StatusAniruddha Ray (Ani)
 
Capital Account Convertibility and India - Status
Capital Account Convertibility and India - StatusCapital Account Convertibility and India - Status
Capital Account Convertibility and India - StatusAniruddha Ray (Ani)
 
Exploring Consumers Mind and Heart - Apartment-Wallahs
Exploring Consumers Mind and Heart  - Apartment-WallahsExploring Consumers Mind and Heart  - Apartment-Wallahs
Exploring Consumers Mind and Heart - Apartment-WallahsAniruddha Ray (Ani)
 
IIMA PGPX - FT Ranking Communique
IIMA PGPX - FT Ranking CommuniqueIIMA PGPX - FT Ranking Communique
IIMA PGPX - FT Ranking CommuniqueAniruddha Ray (Ani)
 
Leadership Tips from Jack Welch - Summary by Ani
Leadership Tips from Jack Welch  - Summary by AniLeadership Tips from Jack Welch  - Summary by Ani
Leadership Tips from Jack Welch - Summary by AniAniruddha Ray (Ani)
 
The Long Tail - A Summary by Ani
The Long Tail  - A Summary by AniThe Long Tail  - A Summary by Ani
The Long Tail - A Summary by AniAniruddha Ray (Ani)
 

Mehr von Aniruddha Ray (Ani) (19)

Best Bourbons
Best BourbonsBest Bourbons
Best Bourbons
 
10 Best - Single Malt Scotches
10 Best - Single Malt Scotches10 Best - Single Malt Scotches
10 Best - Single Malt Scotches
 
3D Cameras - Evolution (Films to 3D) and Road Ahead
3D Cameras - Evolution (Films to 3D) and Road Ahead3D Cameras - Evolution (Films to 3D) and Road Ahead
3D Cameras - Evolution (Films to 3D) and Road Ahead
 
IIM A PGPX - 6th Batch - Snapshot
IIM A PGPX - 6th Batch - SnapshotIIM A PGPX - 6th Batch - Snapshot
IIM A PGPX - 6th Batch - Snapshot
 
PGPX - One Day Theatre - Lessons
PGPX - One Day Theatre -  Lessons PGPX - One Day Theatre -  Lessons
PGPX - One Day Theatre - Lessons
 
TVS Suzuki JV Split - Analysis on Corp Governance
TVS Suzuki JV Split - Analysis on Corp GovernanceTVS Suzuki JV Split - Analysis on Corp Governance
TVS Suzuki JV Split - Analysis on Corp Governance
 
Ani's Small World - 35 Revolutions Around The Sun
Ani's Small World  - 35 Revolutions Around The SunAni's Small World  - 35 Revolutions Around The Sun
Ani's Small World - 35 Revolutions Around The Sun
 
Saint Joan - Leadership Lessons
Saint Joan - Leadership LessonsSaint Joan - Leadership Lessons
Saint Joan - Leadership Lessons
 
Containerization and India - Status
Containerization and India - StatusContainerization and India - Status
Containerization and India - Status
 
Capital Account Convertibility and India - Status
Capital Account Convertibility and India - StatusCapital Account Convertibility and India - Status
Capital Account Convertibility and India - Status
 
The State of 3PL Industry
The State of 3PL IndustryThe State of 3PL Industry
The State of 3PL Industry
 
Exploring Consumers Mind and Heart - Apartment-Wallahs
Exploring Consumers Mind and Heart  - Apartment-WallahsExploring Consumers Mind and Heart  - Apartment-Wallahs
Exploring Consumers Mind and Heart - Apartment-Wallahs
 
How Will You Measure Your Life
How Will You Measure Your LifeHow Will You Measure Your Life
How Will You Measure Your Life
 
IIMA PGPX - FT Ranking Communique
IIMA PGPX - FT Ranking CommuniqueIIMA PGPX - FT Ranking Communique
IIMA PGPX - FT Ranking Communique
 
IIMA PGPX - Introduction
IIMA PGPX - IntroductionIIMA PGPX - Introduction
IIMA PGPX - Introduction
 
Leadership Tips from Jack Welch - Summary by Ani
Leadership Tips from Jack Welch  - Summary by AniLeadership Tips from Jack Welch  - Summary by Ani
Leadership Tips from Jack Welch - Summary by Ani
 
The Long Tail - A Summary by Ani
The Long Tail  - A Summary by AniThe Long Tail  - A Summary by Ani
The Long Tail - A Summary by Ani
 
India-aah
India-aahIndia-aah
India-aah
 
EJB 3.0 and J2EE
EJB 3.0 and J2EEEJB 3.0 and J2EE
EJB 3.0 and J2EE
 

Kürzlich hochgeladen

Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Commit University
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXTarek Kalaji
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URLRuncy Oommen
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Brian Pichman
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024SkyPlanner
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDELiveplex
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 

Kürzlich hochgeladen (20)

Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)Crea il tuo assistente AI con lo Stregatto (open source python framework)
Crea il tuo assistente AI con lo Stregatto (open source python framework)
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
VoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBXVoIP Service and Marketing using Odoo and Asterisk PBX
VoIP Service and Marketing using Odoo and Asterisk PBX
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Designing A Time bound resource download URL
Designing A Time bound resource download URLDesigning A Time bound resource download URL
Designing A Time bound resource download URL
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )Building Your Own AI Instance (TBLC AI )
Building Your Own AI Instance (TBLC AI )
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024Salesforce Miami User Group Event - 1st Quarter 2024
Salesforce Miami User Group Event - 1st Quarter 2024
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDEADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
ADOPTING WEB 3 FOR YOUR BUSINESS: A STEP-BY-STEP GUIDE
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 

Scrum and Agile SDLC 101

  • 1. Agile SW Development with Scrum http://tiny.cc/RcgcB Aniruddha Ray
  • 2. Presumptions Audience is (well) aware of traditional SDLC methods 1)Waterfall Model 2)V Model 3)Spiral Model 4)Iterative Development (RUP) And concepts like: 1)Requirements Traceability 2)Use Cases 3)Unit testing
  • 3. Introduction Learning Driven Continuous Team Communication Deliver in Short, Business-Focused Phases, Typically 2 – 3 Months Develop in End-to-End Functional Slices Continuously Integrate Code Throughout (Daily Builds) Fully-Automated, Continuous Testing at Both Functional and Unit Level Low Cost of Change Plan Driven Infrequent Team Communication Deliver Once in “Big Bang” Fashion, Typically 9 – 12 Months Develop in Layers: Presentation, Persistence, Business, etc. Integration of Different Layers Occurs at End of Build Phase Testing as Separate Phase at End of Project, Emphasizing Functional Level High Cost of Change Waterfall Agile Attempts to Nail Down Requirements Expects, accommodates Changes to Requirements
  • 4. What is Agile ? Agile proponents believe Current software development processes are too heavyweight or cumbersome (Too many things are done that are not directly related to software product being produced) Current software development is too rigid Difficulty with incomplete or changing requirements Short development cycles (Internet applications) More active customer involvement needed Agile methods are considered Lightweight People-based rather than Plan-based Several agile methods No single agile method or definition XP most popular in Development Scrum most popular in Project and Delivery Mgmt Agile Manifesto closest to a definition Set of principles Developed by Agile Alliance
  • 5. The Agile Manifesto A Statement of Values We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan While there is value in the items on the right, we value the items on the left more. Key signatories: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas http://www.agilemanifesto.org
  • 6. Agile Principles We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
  • 7. Agile Methods Major Methods Scrum – Ken Schwaber and Jeff Sutherland Extreme Programming – Ron Jeffries and Kent Beck Adaptive Software Development (ASD) Dynamic System Development Method (DSDM) Lean Software Development – Mary Popendieck Other Methods Kanban for SW Development Feature Driven Development (FDD) Crystal Framework – Alistair Cockburn IUP (and RUP done with Agile Principles) – IBM (Rational) Agile Modeling (Agile Data) – Scott Ambler
  • 8. Agile In Practice Focus on business value Work together closely as one team Work in short iterations Inspect and Adapt Remove waste ruthlessly (wasted effort, wasted time) Deliver working software early and often
  • 9. Scrum in 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month). – INSPECT and ADAPT The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features. At every (pre-decided) frequency (two weeks to a month) anyone can see real working software and (decide to release it as is or) continue to enhance for another iteration. The iterations (Sprints) are Time-Boxed.
  • 10. A Short History of Scrum 1995: - Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber - Enhancement of Scrum by Mike Beedle & combination of Scrum with XP 1996: - Introduction of Scrum at OOPSLA conference 2001: - Publication “Agile Software Development with Scrum” by Ken Schwaber & Mike Beedle 2005: - Scrum and XP were the most popular Agile frameworks implemented (a lot of times Hand in hand) 2009: - Scrum is the single most popular Agile implementation. With popularity there is criticism or frustration of failure in some cases (Scrum- But)
  • 11. The Power of Scrum More business value delivered sooner Better return-on-investment for projects Greater visibility – to team and customers (also – Management) Improved productivity – People, Process Less waste – Lean mindset Higher quality – Inspect and Adapt Frequently Stronger teams – focussed, decisive, self managing Better morale across the whole team - camaraderie Engineering processes improved significantly The critical features built at the quickest time at the minimal cost
  • 12. The Dangers of Scrum It’s hard! It requires significant change It makes all dysfunction visible - Scrum doesn’t fix anything: the team has to do it - You may see things you don’t want to see It demands honesty and transparency Bad products will be delivered sooner, and doomed projects will fail faster Partial adoption may be worse than none at all Be forewarned: many Scrum adoptions fail
  • 13. Scrum in a Page
  • 14. The Operating Model “Self-managing or self-organizing” teams – no decision from anyone else. Product progresses in a series of month-long “sprints” – TimeBoxed Requirements are captured as features/stories in a “product backlog” – One version of truth Features are prioritized (by Business value or any other parameter) by single Owner At the end of every sprint team should demo a “potentially shippable product”. No specific engineering practices prescribed – team selects the necessary tools and practices (can select from other Agile FW) One of the many “agile” frameworks – TEAM takes best practices from others if they want BUT for the RIGHT reasons
  • 15. Characteristics “MUST HAVE” Teams have a dedicated PO and SM SM is co-located with team Team have a Scrum/War room. Time Boxing of Sprints. Scope of Sprint Backlog can be changed ONLY by Team (not SM or PO or Management) Sprint Demo at the end of every sprint No one changed PBL except PO Team decides the scope of Sprints. “GOOD TO HAVE” Teams of sizes 5-7 Co-located teams and “war room” Tie up with Engineering specific from XP (Test Driven Development, Refactoring) Minimum Documentation (as per need) SM not the People Manager or Traditional Manager No management influence on team. Coaching from SM. PO co-located with Team
  • 16. Scrum Framework Roles : Product Owner, ScrumMaster, Team Ceremonies : Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting Artifacts : Product Backlog, Sprint Backlog, Burndown Chart, Velocity Chart
  • 17. Product Owner Responsible for maximizing the project’s ROI Creates high-level vision (MRD or PRD???) Creates a prioritized list of features (the Product Backlog) – decides on parameter of prioritization Final decision-maker on the Product Backlog – one version of truth!! Evolves the Product Backlog from Sprint to Sprint Helps the team be effective, by removing waste (like impediments and distractions) and supporting the team’s Scrum practices and efforts to improve. Can interact with customers, management or others to refine product vision. Single point of reference for team on ANY product related issue.
  • 18. Scrum Master Serves the Team Helps the Team remove obstacles and problems (“blocks”) Facilitates interactions within the Team, and between the Team and Product Owner Protects the Team Protects the team from outside disruption or threats Coaches the Team Helps the Team and Product Owner improve the effectiveness of their practices Helps the Team and Product Owner face and resolve difficult or uncomfortable issues Guides the skillful use of Scrum Teaches Scrum to the Team, Product Owner, and company Ensures that all standard Scrum practices are followed Avoid having the team’s manager be ScrumMaster Try having full time ScrumMaster for best results
  • 19. Scrum Team Typically 7 (+ or – 2) people Co-located 100% dedicated to sprint (minor exceptions – Sys-Admin etc) Cross-functional QA, Programmers, UI Designers, etc. Includes all the skills necessary to produce an increment of potentially shippable product Team takes on tasks based on skills, not just official “role” Teams are self-organizing and self managing What to do if a team self-organizes someone off the team?? Ideally, no titles but rarely a possibility Team decides how much to commit to in a sprint Team works together to manage and complete the work to achieve the goal Membership can change only between sprints
  • 20. Ceremonies Project Kickoff Meeting Sprint Planning Meeting Product Backlog Refinement Meeting Sprint Review Meeting Daily Scrum (Scrum of Scrums) – for bigger teams Sprint Retrospective Meeting
  • 21. Project Kickoff Meeting A special form of Sprint Planning Meeting – Optional. Meeting before the begin of the Project – 1 day of effort. Team (or a smaller core) may go through the product vision and entire backlog at higher level Helps in understanding the big picture – reviewing priorities and identifying dependencies/assumptions. May result in first cut of High Level estimates or minor refinements/changes in PBL (only PO will do it)
  • 22. Sprint Planning Meeting 1st Part: Creating/Refining Product Backlog (Edits, Reprioritization) Determining the Sprint Goal. Participants: Product Owner, Scrum Master, Scrum Team 2nd Part: Participants: Scrum Master, Scrum Team Creating Sprint Backlog Discussing, Noting details on each scoped feature Dependencies/Assumptions (P.O available on call for discussion) Note: ScrumMaster facilitates the meeting and protects the team from pressure
  • 23. Spring Planning Meeting Suggested Steps 1) Team calculates how much time it will have available during the Sprint 2) Team takes first item from Product Backlog and breaks it into tasks 3) Team estimates how long the tasks will take (take care of all planned activities, definition of DONE and buffer) 4) If there’s available time remaining, move to the next item on Product Backlog and repeat 1-3 5) Finalize the features which have clarity and estimates and decide on how many to be scoped for sprint.
  • 24. Spring Planning Meeting – Input Output Sprint Planning Meeting Product Backlog Team Capabilities Business Conditions Technology Current Product Sprint Backlog Sprint Goal
  • 25. Sprints Scrum projects make progress in a series of “sprints” Analogous to XP iterations Target duration is pre decided. Scrum suggests 2 weeks to one month a constant duration leads to a better rhythm Once decided Sprint duration MUST not change Product is designed, coded, and tested during EACH sprint EACH sprint should end in a potentially shippable code. Scope DOESNOT change within a sprint. Team may decide to push unfinished items to next sprint. PO can decide to CANCEL a sprint midway and restart (in special cases)
  • 26. What is A Sprint A 2 - 4 week long iteration, during which team increments the product functionality NO outside influence can interfere with the Scrum team during the Sprint Each Sprint begins with the Kickoff meeting Daily Scrum Meeting conducted throughout the sprint. Each Sprint ends with a sprint demo and retrospective. Sprint duration or scope is immutable (unless critical business change happens) Sometimes teams may have intermediate Sprint review meetings (to discuss/pre-plan items of next sprint if it helps)
  • 27. Sequential vs. Overlapping Dev. Requirements Design Code Test
  • 28. Scrum Meeting Goal of the Scrum Meeting Keep team coordinated and up-to-date with each other Surface “blocks” or problems daily Key Parameters Daily (fixed time) 15-minutes or less (no more) Stand-up Not for problem solving Only SM and Team Three questions for everyone: 1. What did you do yesterday 2. What will you do today? 3. What obstacles are in your way? “Chickens” and “Pigs” – Only “Pigs” can talk Help avoid other unnecessary meetings No discussion until after meeting ends After meeting SM will help remove the blocks and find solutions to problems.
  • 29. Scrum Meeting – FAQs Is NOT a problem solving session Is NOT a way to collect information about WHO is behind the schedule Is a meeting in which team members make commitments to each other and to the Scrum Master Is a good way for a Scrum Master to know (Track?) the progress of the Team Is THE meeting for a Scrum Master to know what is blocking the Team. • Why daily? – “How does a project get to be a year late?” • “One day at a time.” – Fred Brooks, The Mythical Man-Month. • What if all team members are not present – WHY are they not present (root cause?) – Burn Out, Low Team Morale or Over Pressure? • Can Scrum meetings be replaced by emailed status reports? – No • Entire team sees the whole picture every day • Create peer pressure to do what you say you’ll do
  • 30. Sprint Review Meeting Goal Get hands on with what’s been built Inspect the quality Come up with ideas for improvements See whether the commitment was completed Team presents what it accomplished during the sprint Typically takes the form of a Demo of new features No PowerPoint Demo Informal 2-hour prep time rule 2 hour demo time Participants – EVERYONE Informal and Fun
  • 31. Sprint Retrospective Meeting Goal Find ways to improve the team’s way of working in the next Sprint Participants: SM and Team only Product Owner and managers should join for part (but not all) of the Retrospective Team needs time to talk by itself Feedback within team and self correcting decisions – SM to check that there is no outside imposition. Three questions (optional 4th) Start - What are worth trying Stop – What are waste and should be stopped Continue – What went well Escalation/Risk List to Upper Management. Don’t skip ever (Critical for the first 5-6 sprints!!!)
  • 32. Product Backlog Refinement – Optional Optional Meeting – Worked well in some cases Goal: During the Sprint, plan to spend ~5% of your available time doing Product Backlog Refinement (also known as Product Backlog Grooming) Team and Product Owner sit down and look ahead at Product Backlog Items for upcoming Sprints Team asks questions and clarifies requirements for upcoming items Team suggests items to add to the Product Backlog Team starts to think about how they’re going to implement the items (at a high-level)
  • 33. Product Backlog A list of all desired work on the project Usually a combination of story-based work (“let user search and replace”) task-based work (“improve exception handling”) List is prioritized by the Product Owner Typically a Product Manager, Marketing, Internal Customer, etc. • Requirements for a system, expressed as a prioritized list of Backlog Items • Is managed and owned by a Product Owner • PO Can use MOSCOW tool to prioritize. • Can be a Spreadsheet (typically) or any other report • Usually is created during the first Sprint Planning Meeting or Project Kickoff Meeting • Should be changed/updated and re-prioritized before each Sprint Planning Meeting. • Product Backlog will have all features (including non- functional requirements)
  • 34. From Sprint Goal to Sprint Backlog Scrum team takes the Sprint Goal and decides what tasks are necessary Team self-organizes around how they’ll meet the Sprint Goal Manager doesn’t assign tasks to individuals Managers don’t make decisions for the team Sprint Backlog is created Estimates are done by the team (best practice: Wideband Modified Delphi method)
  • 35. Sprint Backlog A subset of Product Backlog Items, which define the work for a Sprint Is created ONLY by Team members Each Item has it’s own status Should be updated every day No more than 300 tasks in the list If a task requires more than 16 hours, it should be broken down Team can add or subtract items from the list. Product Owner is not allowed to do it
  • 36. Sprint Backlog during the Sprint Changes Team adds new tasks whenever they need to in order to meet the Sprint Goal Team can remove unnecessary tasks But: Sprint Backlog can only be updated by the team Estimates are updated whenever there’s new information
  • 37. Scalability of Scrum A typical Scrum team is 6-10 people Jeff Sutherland - up to over 800 people "Scrum of Scrums" or what called "Meta-Scrum“ Frequency of meetings is based on the degree of coupling between packets
  • 38. Confused about Scrum? How much Documentation: Scrum does not specify. Team decides (what’s best for the project) What are user stories: short, plain-language description of the feature, in terms of customer value What are 3 C’s: Card, Confirmation and Conversation. It’s a common model for requirements/story analysis. How do we estimate in scrum: Scrum doesn’t specify. Only suggestion is to have 2 level of estimates – high level at PBL (may be Points) and low level at Sprint BL (may be Hours). Also, ONLY the team decided on estimates. Do we really need to release every sprint – 2 common approach - Release every sprint and multi sprint release. Do what gives maximum business benefit How can team scope the sprint – Team is COMMITING to delivery. So they should scope (Note: They may over or under-commit in initial sprints but with the right spirit and coaching they should stabilize in 5/8 sprints. A disturbing trend would continuous under or over-commitment) Why should we track Velocity: The team needs to find a Self-sustaining pace and confidence in commitment. Velocity provides the trend to them. (Note: Velocity IS NOT for management to track)
  • 39. Scrum EXPOSES Organization Impediments Process People arrive late to daily scrum and do not support basic discipline Scrum meetings take too long – team is bred and considers the tie unproductive Scrum master dictates design decisions or micromanages Teams are too large for effective daily scrum and sprint planning Teams do not report task-remaining time for burn-down analysis People Individuals are interrupted and tasked to work outside the sprint Teams are isolated in cubicles and not in open scrum area Teams members are not accountable for personal sprint commitments Individuals are multiplexed across too many projects and teams. Product Cross-functional resources for definition, design, implementation, and test are not present on the team Sprints do not fully implement and test potentially deployable increments of customer-valued features. Product owner is not easily available or not integral to team System integration is not forced at each sprint Product owner won’t split up massive product backlog items to fit within a sprint Team have ineffective resources for automating builds and integrations Features are loaded into sprints after sprint begins
  • 41. Burn Down Charts Sprint Burndown • Depicts the total Sprint Backlog hours remaining per day • Shows the estimated amount of time to release • Actually is not a straight line • Can bump UP and DOWN • Ideally should burn down to zero to the end of the Sprint Release Burndown • Will the release be done on right time? • X-axis: sprints • Y-axis: amount of hours remaining • The estimated work remaining can also burn up Product Burndown Is a “big picture” view of project’s progress (all the releases)
  • 42. Agile SW Dev – XP and RUP Key characteristics of XP include A team of five to ten programmers, co-located with customer representation on site. Development with frequent builds and iterations, each of which is releasable and delivers incremental functionality. Requirements are specified as stories, each a chunk of new functionality the user requires. Programmer work in pairs, follow strict coding standards, and do their own unit testing. Requirements, architecture, and design emerge over the course of the project Key characteristics of RUP include (Modified to IUP) RUP provides a full lifecycle approach covering a series of product lifecycle phases called inception, elaboration, construction, and transition RUP provides a SW development method and a set of software engineering practices that cover the majority of SW development disciplines. RUP is iterative. Within each phase, the product undergoes multiple iterations; the nature of each is determined in part by the life cycle phase. RUP is incremental: Each iteration builds on the functionality of the prior iteration; the software application evolves in this fashion with the benefit of regular and continuous feedback.
  • 43. Agile SW Dev – DSDM and Lean Key characteristics of DSDM include Active user involvement The team is empowered to make decisions The focus is on frequent delivery of products Fitness for business purpose is the essential criterion for acceptance of deliverables Iterative and incremental development is necessary to converge on an accurate business solution. All changes during development are reversible Requirements are base-lined at a high level. Testing is integrated throughout the life cycle. Collaboration and cooperation between all stakeholders is essential Key characteristics of Lean Software include Reduced work in process inventory – Reduced investment in elaborated requirements, documented designs Reduced Cycle time – Build all software in much smaller lots Cross-training and cell-based manufacturing – Increase cross-training with pair programming and shared code assets. Have developers write tests as part of their code Continuous Process Improvement – Continuous reflection and adaption
  • 45. Does This Ring A Bell?