Agile & SCRUM

Why, What & How.

Created by ejlp12@gmail.com, 6 Nov 2009

Presented to project team members. Pictures are copied from Internet and not my copyright. Some slides are also taken from Internet.

AGILE METHODOLOGY

Why Agile Software Development…?

What is Agile?

The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation

– Ken Schwaber

Agile, basic

• Adaptive and responsive to change

• Increase productivity and identifying and prioritizing high value features

• Positive emergent culture that allows for continuous improvement

• Avoid the pitfalls of waterfall

More on characteristics

• Empirical (relies on observation and experience)• Lightweight• Adaptive• Fast – but never hurried• Exposes wastefulness• Customer-centric• Pushes decision making to lower levels• Fosters trust, honesty and courage• Encourages self-organization

Agile manifesto

Individuals & Interactions over Process & ToolsWorking Software over Comprehensive

DocumentsCustomer Collaboration over Contract

NegotiationResponding to Change over Following a

Plan

Things on the right are important.

Things on the left are more important!!

Agile methodologies

• Feature Driven Development (FDD)• Extreme programming (XP)• Crystal• Lean Development• SCRUM• Rational Unified Process (RUP)• Adaptive Software Development (ASD)• Dynamic System Development Method (DSDM)

Agile SW development practices

• Essential Practices– Regular refactoring (many times daily)

• This produces well-componentized designs, clear APIs and clean code without duplications

– Frequent check-ins (many times daily)

– Unit Testing • Leading to Test Driven Development (TDD)

– Continuous Build and Integration• Running automated tests on each build

– Just-in-time code reviews (e.g. pair programming)

• Example methodologies: XP, Agile Modeling

Agile SW Testing

• Early involvement– An Agile project begins when testers convert high-level requirements

into testable specifications.

• Work as part of the development team– The testers work with the developers to pick unit test and acceptance

test frameworks, and to test the software in parallel with development. This requires a shift in thinking.

• Automate everything– (wherever possible)

• Test early, test often– Never leave the testing until the end

The Agile Customer• “Customer’ is a role, not a person

– Also known as Product Manager, Product Owner– Proxy for the entire customer group

• Responsible for the Release Plan• Responsible for managing the Product Backlog• Determines business value & priority on a regular basis• Provides information to development team for estimation

purposes• Works with testers to produce clear, testable user stories

for each iteration• Inspects software regularly (e.g. runs acceptance tests)

and provides feedback to the development team

SCRUM

SCRUM is…

• Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices

• Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation

• It is adaptive, quick, self-organizing and have few rests

..process framework, not methodology

Why SCRUM

It is HOT!

• It’s work and simple.• More practical (practical process model). • A rule of thumb or best practices for process inspection

and continue adaptation.

SCRUM Characteristics

• Self-organizing teams

• Product progresses in a series of month-long “sprints”

• Requirements are captured in a list of “product backlog”

• No specific engineering practices prescribed

SCRUM doesn’t tell how to develop Software.

Find XP, TDD, etc

Roles and Responsibilities

• Product OwnerDefines the features of the product, decides on release date and contentIs responsible for the profitability of the product (ROI)Prioritizes features according to market valueCan change features and priority every 30 daysAccepts or rejects work results

• Scrum MasterEnsures that the team is fully functional and productiveEnables close cooperation across all roles and functions and removes

barriersShields the team from external interferencesEnsures that the process is followed. Invites to daily scrum, iteration

review and planning meetings

• Team Cross-functional, seven plus/minus two members Selects the iteration goal and specifies work results Has the right to do everything within the boundaries of the project

guidelines to reach the iteration goal Organizes itself and its work Demos work results to the Product Owner

Key Artifacts

• Product backlog List of requirements & issues Owned by Product Owner Anybody can add to it Only Product Owner prioritizes

• Sprint Goal A short “theme” for the sprint, typically one line summary:

For example, “Make the application run on Oracle in addition to SQL Server”

Declared by Product Owner Accepted by team

• From Sprint Goal to Sprint Backlog …Scrum team takes the Sprint Goal and decides what tasks are necessaryTeam self organizes around how they’ll meet the Sprint GoalManager doesn’t assign tasks to individualsManagers don’t make decisions for the teamSprint Backlog is created

• Sprint backlogList of tasksOwned by teamOnly team modifies it

• Blocks listList of blocks & unmade decisionsOwned by Scrum MasterUpdated daily

Product Backlog

Sprint Backlog

Sprint Backlog (after 5th days)

Key Meetings

• Sprint Planning Meeting Hosted by Scrum Master; ½-1 day In: Product Backlog, existing product, business & technology conditions

Select highest priority items in Product Backlog; declare Sprint Goal Team turns selected items into Sprint Backlog

Output Sprint Goal, Sprint Backlog

Sprint Planning Meeting

Sprint PlanningMeeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Produ

ct O

wner

Scrum

Tea

m

Man

agem

ent

Custo

mer

sSprint Goal

Key Meetings (Cont’d)

• Daily Scrum Hosted by Scrum Master 15 – 30 minutes stand-up meeting Attended by all: pigs (scrum team) and chickens (others), but only pigs can talk Same time every day; three questions:

What did you do yesterday? What will you do today? What obstacles are in your way?

Team updates Sprint Backlog; Scrum Master updates Blocks List

The team should reflect on how to make them most effective.

Sit or stand, up to you!

SCRUM Process

30 days

24 hours

Product BacklogAs prioritized by Product Owner

Sprint Backlog Backlog tasksexpandedby team

Potentially ShippableProduct Increment

Daily ScrumMeeting

Sprint

Burndown Chart

Key Meetings (cont’d)

• Sprint Review Meeting– Hosted by Scrum Master, attended by

• Customers• Management• Product Owner• Team

– Team presents what it accomplished during the sprint– Team demos Increment– 2-hour– Hold retrospective– Announce next Sprint Planning Meeting

Tools: Burn-down chart

• For monitoring progress during a sprint. • Remaining work is plotted on the Y axis, • Time proceeds along the X axis. • As tasks are completed, the line slopes down.

Burndown Chart…the velocity of turning requirements into potentially shippable increments of functionality.

Burndown chart

Progress

752 762

664619

304264

180104

200

100

200

300

400

500

600

700

800

900

Date

Rem

ain

ing

Eff

ort

in

Ho

urs

Scrum of Scrum

Summary

• Roles : – Product Owner, ScrumMaster, Team

• Artifacts : – Product Backlog, Sprint Backlog, Block List and

Burndown Chart • Ceremonies :

– Sprint Planning, Sprint Review, Sprint Retrospective, & Daily Scrum Meeting

Concept & Process (PM & SM)

• Project Managers say– Schedule– Scope– Work Breakdown Structure– Productivity– Estimate to Complete

• Scrum Masters say– Sprint– Sprint Backlog– Task Breakdown– Velocity– Burndown Chart

• Project Managers say– Plan– Execute– Monitor & Control– Close

• Scrum Masters say– Define Backlog, Plan Sprint– Develop and Test– Move Stickies, have Daily Scrums– Demo, Release, have Retrospective

Risks & Challenges

• Educating the team – Dev, QA, Business• Estimations to get work ‘done’ – not just engineering• Changing the mindset of all stakeholders – PM, team,

management, client and users• Reduced importance to signoffs and approvals, increased

value to collaboration and transparency• Either budget or scope should be flexible

SCRUM IN MY PROJECT

Case study: Our project

• We haven’t done a SCRUM yet• We planning it

• We need to adapt not adopt• No “big bang” adoption

Start by a simple but working, NOT complete but not working

The Goal is Success

• Success factor as seen by customer– On time – No bugs, right features, good performance– Successful deployment/release

• Success factor as seen by my employer– On time to get money– Maximum revenue– The client is happy

The Challenges are…

• It’s kind like SCM rather than PM • Developer tends to

– Hard to estimate working effort (time)– Don’t want to commit to timeline– Complaining

• Our work culture:– I only doing as you requested– I don’t care about documentation– As long as it is run (passed the test), it’s done– Working time is not effective

• The CR is not iterative as seen by customer

How?

• We will commit to any task that we can do• We will use tools that works for us• We will share each other• Document first & document as simple as possible• We start development early• It seems “scrum of scrum” will work rather than scrum• Minimize testing iteration whenever possible• Characterize each CR then reduce work if possible• We will not do scrum for small (effort) CR (team less than 3)

Detail plan will be discussed after this presentation!

SCRUM TEAM MEMBER?What you should keep in mind

…

• SCRUM team, keep asking these questions:– What is the simplest thing that can move the project forward?– Does what I am doing right now move the project forward at all?– Are there any impediments that are preventing progress?

• Escalate impediment even thought they don’t really care about it.• Sprint is belong to the team and is a team’s goal

“Don’t procrastinate, do something, no matter how small…” – Ken Schwaber, Vienna, April 2004

END