View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Agenda • Short introduc,on to Agile • Scrum – Overview – How it works 2
Tradi4onal So7ware Project Failures • Nearly 2 / 3 of the projects are signiﬁcantly 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 suﬃcient knowledge; • Priori4es constant.
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.
Sprints • Scrum projects consist of a series of "sprints" • Typically 2-‐4 weeks in length. • A ﬁxed 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.
Product Owner • Is the voice of the customer. • Deﬁnes the features of a product. • Determines the release date. • Responsible for the proﬁtability 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 iden4ﬁed 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.
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?
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 deﬁned 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
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 eﬀort required (by team). • User story format: As <type of user> I want<some goal> so that <some business reason>.
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
Deﬁni4on of Done • Is determined by the team • Completed work must meet this deﬁni4on • Elements to consider include: – Coding style – Code comment – Peer review – Units tests – Document – Manual – ???
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.