agile-scrum methodology-an introduction
DESCRIPTION
This presentation introduces scrum, a very common agile methodology.TRANSCRIPT
Introduction to Agile with Scrum
Agenda
• Short introduc,on to Agile • Scrum
– Overview – How it works
2
Tradi4onal So7ware Project Failures
• Nearly 2 / 3 of the projects are significantly over budget
• 64% of the features in a product are rarely used
• An average project exceeds its schedule by 100%
3
Main Causes
• Planning for comple4on of ac4vi4es rather than features.
• Progress not transparent to customers, and focus on ac4vi4es leading to missing-‐forgoRen features.
• Specializa4on leading to island culture and reduced involvement.
• Do not work on the basis of client priority, but o7en technical. Team starts late with important business needs
• Ignore uncertainty (changing insights / requests?)
Limita4ons of Waterfall "Waterfall" project approach is only possible if
• Problem is clear; • Solu4on is known; • Technique familiar; • Problem has not changed; • A sufficient knowledge; • Priori4es constant.
Agile Manifesto
Suppor4ng Agile “Sentences” 1. Our highest priority is to sa4sfy the customer through early
and frequent delivery of valuable so7ware. 2. Deliver working so7ware frequently, from a couple of
weeks to a couple of months, with a preference for the shorter 4me scale.
3. Working so7ware/product is the primary measure of progress.
4. Welcome changing requirements, even late in development 5. Business people and developers work together daily
throughout the project. 6. Build projects around mo4vated individuals. Give them the
environment and support they need, and trust them to get the job done.
Agile Methodologies
• Extreme Programming (XP) • Scrum • Feature-‐Driven Development (FDD) • Adap4ve So7ware Process • Crystal Light Methodologies • Dynamic Systems Development Method (DSDM)
• Lean Development
Scrum
A scrum is a term from rugby.
Scrum is a way of re-start after minor violation, where a group of players tries to push the ball obtain control.
Scrum Flow
Sprints
• Scrum projects consist of a series of "sprints" • Typically 2-‐4 weeks in length. • A fixed constant length gives a beRer work rate. • Features are designed, built and tested during a sprint.
• Customer can not change job during a sprint. • Have a sprint goal. A brief statement about the focus of the work of the upcoming sprint.
Scrum Framework
Product Owner
• Is the voice of the customer. • Defines the features of a product. • Determines the release date. • Responsible for the profitability of a product. • Its mandate is to make decisions. • Priori4zes the product features based on market value
• Change features and priority every itera4on, if desired.
• Accepts or approves work results.
Team
• Complete (all skills) • Self and self-‐learning • No permanent jobs • 5 to 9 people • Work together, not individually. • Involved • Produc4ve and fun • Preferably, cross-‐func4onal.
Scrum Master • Is not a project manager! Facilitates the team. • Responsible for the importa4on and compliance with Scrum
values ��and prac4ces. • Solves problems for the progress of projects iden4fied by the
team, so that the goal of Sprint and the deliverables are met. • Ensures that the team is fully focused, opera4onal and
produc4ve. • Ensures that all roles and func4ons work together. • Shields the team from external disturbances during the sprint.
Scrum Framework
Sprint Planning
Sprint Planning
Daily Scrum • Daily, 15 minutes, standing. • Not meant to solve problems. • Anyone outside the team may be present, only team
members are ac4ve part (speaking).
• Helps to avoid unnecessary mee4ngs (e g weekly progress mee4ng)
• Are not intended to state the progress or management. – What did you do yesterday? – What you are going do today? – Are there any restric4ons that the comple4on of the sprint at risk?
Daily Scrum
Sprint Review(Demo)
• The team presents the results of the last sprint through a demonstra4on of the func4onality built.
• Informal, no slides, max 2 hours. • The whole team takes part in the demonstra4on.
• Stakeholders and managers are welcome to aRend.
Sprint Retrospec4ve • Is held a7er each sprint • Consider what works and what does not work. • Priori4za4on of the improvement. • Ac4on items are defined to ensure that real improvements takes place in the next sprint (s).
• The whole team takes part (Scrum Master, Product Owner, Team).
• Dura4on vary depending on the retrospec4ve approach, team size, length sprint.
• Usually 30-‐60 minutes
Scrum Framework
Product Backlog • The requirements • To Do list of all the work required in the project. • Expressed from the user / client. • Not how but why. • By priority (by product owner.) • Itera4ve (changes ok, for each sprint). • Visible. • Items es4mated effort required (by team). • User story format: As <type of user> I want<some goal> so
that <some business reason>.
Product Backlog
Sprint Backlog
• List of work done in the next sprint. • Breakdown of features into tasks (1-‐16 hours). • Tasks are not assigned to team members. (More variety and crea4vity. No knowledge islands)
• Tasks are es4mated by the team with Planning Poker.
• Tasks are picked based on the right priori4es and the skills of team member.
• Is usually visualized by a Scrum board
Planning Poker
Scrum Board
Scrum Board
Itera4on Burn-‐down Chart
Release Burn-‐down Chart
Defini4on of Done
• Is determined by the team • Completed work must meet this defini4on • Elements to consider include:
– Coding style – Code comment – Peer review – Units tests – Document – Manual – ???
Scrum Flow Summary
Summary • Scrum is (almost) 'Magic':
– Timely feedback. – Focus on working product. – Priori4ze on added value. – Not plan ahead in detail. – Self-‐management and responsibility. – Clear roles and responsibili4es.
To be con4nued…