You are on page 1of 37

What is Scrum? Why do it? (2.

0)

Michael Baldwin
Network Services Engineering
1
1

Contents
What is Agile? & Agile Principles Why do Agile? Scrum Framework

Sun Confidential: Internal Only

What is Agile?
A group of software development frameworks that promote: > development in short iterations, > open collaboration, and > adaptability There are many flavors - Scrum, XP, EssUP, Lean Development, etc. Agile is result of deep thinking about why software projects fail Applicability goes well beyond software projects!

Sun Confidential: Internal Only

Agile Principles
Software projects work best when we...
> Customer satisfaction by rapid, continuous delivery of useful software > Working software is delivered frequently (weeks rather than months) > Working software deliverables are the principal measure of progress > Even late changes in requirements are welcomed > > > > > > >

Close, daily cooperation between business people and team Face-to-face conversation is the best form of communication Projects are built around motivated individuals who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances
Sun Confidential: Internal Only
4

Why do Agile?

Potential Revenue/Cost Savings and improved Speed-to-Market Quality is integrated into the lifecycle (not backloaded!) Incremental deliveries encourage active user involvement and make progress easy-to-see Failure of Upfront Thinking (a.k.a. Why doesn't Big Requirements Up Front work) Simplifies and facilitates risk management Flexibility / Agility change is OK! Cost control scope and features are variable Customer Satisfaction Right product is built More enjoyable!
Sun Confidential: Internal Only

Failure of Upfront Thinking


Reality = change happens:
> People arent good at identifying what they need > People change their minds > The business environment changes

People ask for everything they could possibly want Developers dont read and/or understand the requirements Change management quickly focuses on change prevention Research evidence:
> Big requirements up front (BRUF) + traditional change management was found by

82% of failed projects to be the leading cause of failure > Study size was 1,027 projects, 87.3% considered failures > Source: British Computer Society, 2001 Review

Sun Confidential: Internal Only

Impact of Big Requirements Up Front

Sun Confidential: Internal Only

Emergent Requirements
How does it work best?
> Users discover requirements along the way as a

consequence of seeing incremental deliveries.

Upfront thinking cannot identify emergent requirementsand every project has some. Traditional project mgmt resists change; Agile embraces it

Sun Confidential: Internal Only

What is Scrum?

Sun Confidential: Internal Only

Sun Confidential: Internal Only

10

Sun Confidential: Internal Only

11

Sun Confidential: Internal Only

12

Sun Confidential: Internal Only

13

Sun Confidential: Internal Only

14

Sun Confidential: Internal Only

15

Sun Confidential: Internal Only

16

Sun Confidential: Internal Only

17

Sun Confidential: Internal Only

18

Sun Confidential: Internal Only

19

Sun Confidential: Internal Only

20

Sun Confidential: Internal Only

21

Sun Confidential: Internal Only

22

Sun Confidential: Internal Only

23

Sun Confidential: Internal Only

24

Untruths about Agile


Agile means you don't write requirements (or agile means you do a crappy job of requirements) Agile means you don't manage scope Agile means you don't plan further out than next iteration Agile means you cannot predict when we will be done Agile means you don't have strong process & controls
Sun Confidential: Internal Only
25

Our Experience
1 year, 40 Systems, 250 Engineers, 14 Project Managers Our learning? Our progress? Couple of thoughts
> Forcing milestones and demonstrations every 3 weeks

makes problems very transparent > Our progress charts are cool, useful & getting better
One: https://csa-wiki.east.sun.com/x/2gCaAQ

Sun Confidential: Internal Only

26

What is Scrum? Why do it?


Michael Baldwin, Kasey Bradshaw, Kim Dang, Ramachandran Raghavan, Roshan VC

27
27

What is Scrum? Why do it?


Michael Baldwin, Kasey Bradshaw, Kim Dang, Ramachandran Raghavan, Roshan VC

28
28

Appendix
Agile and PLC Credits some materials for this presentation were derived from presentations given by the following individuals:
> Mike Cohn Agile 2008 Conference, Toronto > Scott Ambler Project World 2008, Toronto > Pete Deemer (Good Agile)

Sun Confidential: Internal Only

29

Simple Recipe for Scrums


> > > >

Focus tightly on three questions for 15-20 minutes:


Defer any longer questions/dialogue to after Scrum Release as many people as possible after three questions Holding entire team for one hour regularly is not right! If the team only has two hours/day to solve problems collaboratively, you might need to spend that hour

Hold it daily;do not schedule meetings on top of it Update XPlanner daily Team should take a moment to look at charts Leverage ScrumMaster to remove blocks. Product Owner should be there.
Sun Confidential: Internal Only
30

Simple Recipe for Demos


Demo. Not slide deck. Try to keep it to an hour. Leave some time for feedback (~15 min) Bad smell: Nothing to show?
> Team probably didn't spend enough time on things that have

real business value > Work is divided into horizontal instead of vertical slices

Create an environment where people can try the product after the demo Make it clear how to provide feedback after the demo
Sun Confidential: Internal Only
31

Simple Recipe for Retrospectives

Hold a retrospective after every sprint The goal: to acknowledge things working well & to identify improvement opportunities Three different questions: What went well? What didn't go well? What should change?
> Consider using onestop survey to help surface feedback > Consider doing something like this to help team digest feedback

https://csa-wiki.east/x/qiyQAQ

There is more value in fixing a single item than reading a list of feedback and doing nothing with it Do not try to fix everything at once
Sun Confidential: Internal Only
32

Agile and PLC

Sun Confidential: Internal Only

33

Agile with PLC


Scrum and PLC can co-exist happily because they operate at different levels. > PLC is business framework for managing the total product life cycle from concept development to product retirement. > Scrum is a project management framework for building software that is mostly concerned with Phase 3 of PLC. PLC tells us very little about how to do the things that Scrum prescribes. Requirements analysis only seems to be an area of conflict

Sun Confidential: Internal Only

34

PLC Overview

Sun Confidential: Internal Only

35

Scrum and PLC


No difference. A PRD and PCD can be done as per PLC norm. The difference, if any, is that we do feature descriptions to scope the system but we do not take them to 100% build-ready state in the PRD. P1 Concept When PLC is done right, the PRD is not expected to be the *final* word in requirements anyway so this is just an apparent difference. The feature list in the PRD would become the basis for building the scrum backlog. No difference. IPP and FSD + Marketing, Operations and Support Plan the other plans are all fine . A description of the agile project framework would go into the IPP in the Development Engineering section. P2 Plan The difference if any is one of perspective we would view the FSD as a document as one that is a valid initial statement of how we intend to build the system and which we would refine if needed as we went along. Practically, this is how it works anyway even if you don't do agile... This is where Agile tells us a great deal about how to do the work. PLC says very little. PLC prescribes little beyond a Test Plan template. PLC tells us nothing about how to do the work of building a product. P3 PLC tells us mostly about milestones and decision points. Agile gives us the project management framework that we leverage to give us the how part that PLC does not speak to.

P3 Develop, Integrate, Test

Sun Confidential: Internal Only

36

Scrum and PLC (2)


PLC Phase What is it like if we do agile?
The difference here is one place where Scrum makes PLC better. PLC documentation suggests that this phase is where a large portion of the development effort and funding is expended. Scrum would say NO!. Testing is addressed for each iteration. Requirements are verified for each iteration. Scrum empowers the business to call for a release at whatever point enough features exist to justify GA. When that call comes, the software is ready to go because testing is integated to the iteration lifecycle. No conflict. PLC prescribes activities and deliverables tied to ensuring readiness. Scrum does not address this. Scrum is concerned with quality of deliverables and customer engagement throughout the duration of the project and incremental deliverables + feedback. Arguably, Scrum supports this PLC phase by driving project deliverables to acceptablility on a continuous basis. No conflict. PLC advises us to announce, ramp to volume, sell and support. Scrum tells us how to do the development work on projects needed to enhance the product. Agile project is over; no conflict. Agile practices are employed to handle new proejcts that are a consequence of refresh and revise decisions.

P4 System Test

P5 Customer Acceptance

P6 Deploy P7 Sustain

Sun Confidential: Internal Only

37