agile at work

8/21/2019 Agile at Work

1/104

AGILE AND SCRUM FRAMEWORKMODERN GAME CHANGERS

Agenda 'Agile' Why Agile Emerged ? Agile Principles

ScrumThe Leader of Agile

Scrum Framework All in a Scrum's Release

Scrum Framework How to SCRUM 'n' STUMP

Scrum Pilot Project / Surprise Scrum and Agile - Conclusions


2/104


Agenda 'Agile' Why Agile Emerged ? Agile Principles Scrum The Leader of Agile Scrum Framework

All in a Scrum's Release




3/104

Project:

Is a temporary endeavor with a beginning and an end.

Creates a unique product, service or a result

Software development methodology:Software development methodology is the set of activities andprocesses (what) that will eventually result in a software

product.

It also describes tools and techniques (how) and important role

(who) in the development process.

Why Agile Emerged ? - FOR IT PROJECTS


4/104


5/104

Definition of Success Has Changed

Functionality

85% respondents consider it more important to meet stakeholder needs,

even if they changed

Quality:

82% consider it more important to deliver high quality than delivering ontime and within

Money

70% consider best ROI more important than under budget

Source: Software Development Projects Success, IBM, Scott Ambler, 2008

Why Agile Emerged ?

Economy: Do more with less

Competitors: Respond quickly to the marketplace

Social Media: Listen to us or else

Technology: Provide new features frequently or fall behind in the

times

Customers: Give us something that works and wont break

Investors/Shareholders: Make money or well go somewhere else


6/104

Traditional Practices:

Traditional software development models are based upon a

defined methodology which attempts to

Define all requirements up front

Logically break down the work

Estimate the effort / durations Plan out all the work

And only then begin the developmentwhile trying to

limit/control any change that will threaten the plan.

Defined Process Control

Document System ConceptSystem Requirements

Architectural DesignDetailed DesignCode, Debug, Unit Test

System Test

Deploy & Operate

Waterfall Development Methodology


7/104

Ask Customers what they want

(When they really dont know)

Reward them for thinking of everything

(Call the initial list Scope)

Penalize them for adding things later

(Control Scope aggressively)

The result is Overproduction of Features

Why Agile Emerged ?Pitfalls OfWaterfall


8/104

Manages'Change is the only Constant'

The best way to manage scope

Less Code More Value !

Develop the 20% of the features that deliver 80% of the

value

Develop & deploy highest priority firstStop when you run out of time or money

Being Agile is Iterative, Adaptive and ...Much MuchMore...

Why Agile Emerged ?Agile The Saviour !!!!!!!!!!!!!


9/104


Agenda 'Agile' Why Agile Emerged ? Agile Principles Scrum The Leader of Agile Scrum Framework

All in a Scrum's Release




10/104

Agile framework Key Principle

MAN

SCRUMBAN

SCRUM/XP HYBRID

AGILE UNIFIED PROCESS

Main DifferenceChanging

requirements

Scope creep

Its an umbrella Embraces Change andEmpirical in Nature


11/104

The Agile Manifesto*

* www.agilemanifesto.org
http://www.agilemanifesto.org/http://www.agilemanifesto.org/http://www.agilemanifesto.org/


12/104

Principles Behind Agile Manifesto*

2007 SolutionsIQ - v15

Early and continuous delivery of software, Continuous

IntegrationDeliver working software frequently Iteratively and

Incrementally

Working software is the primary measure of progress

Continuous attention to technical excellenceThe art of maximizing the amount of work not done

Welcome changing requirements

Business and developers work together

Face-to-face conversation is most efficientBuild projects around motivated individuals

Self-organizing teams deliver the best solutions

Sustainable development, Test Driven Development

The team reflects at regular intervals


13/104


14/104


15/104


16/104


17/104


Agenda 'Agile' Why Agile Emerged ? Agile Principles Scrum

The Leader of Agile





18/104

SCRUM FRAMEWORK THE NAME

Definition from rugby football:

Scrum way to restart the game after an

interruption, where the forwards of each sidecome together in a tight formation and struggle togain possession of the ball when it is tossed inamong them.


19/104

SCRUM FRAMEWORK HISTORY

1995: analysis of common software development processes not

suitable for empirical, unpredictable and non-repeatableprocesses

Design of a new method: Scrum by Jeff Sutherland & KenSchwaber

Enhancement of Scrum by Mike Beedle & combination ofScrum with Extreme Programming

1996: introduction of Scrum at OOPSLA conference

2001: publicationAgile Software Development with Scrum by Ken

Schwaber & Mike Beedle

Successful appliance of Scrum in over 50 companies

Founders are members in the Agile Alliance


20/104

SCRUM FRAMEWORK


21/104

SCRUM FRAMEWORK


22/104


Agenda 'Agile' Why Agile Emerged ? Agile Principles Scrum

The Leader of Agile





23/104

SCRUM - Project Mgmt Framework

Iterative, Incremental and Empirical


24/104

SCRUM FRAMEWORKSOMENEW VOCABULARY,SOME NEW

CONCEPTS

Sprint

ScrumMaster

Daily Scrum

ProductBacklog

BurnDownCharts

TeamRoom Tasks

SprintPlanning

SprintReview

SprintRetrospective

ScrumBag

Impediment

Velocity

DONE

BacklogRefining

Sidebar

EpicUserStory

Scrum Dev Team

ProductOwner

TimeBox


25/104

Scrum Principles

Scrum is guided by a few key principles:

1.The belief that effective software development is best

implemented via an empir icalrather than planned

process

2.The belief that, once organizational impedimentsare

removed, a self organizing and self managing team

will naturally deliver better software than would otherwise

be the case

3.The premise that you can deliver the most valuablesoftware within a prescribed time and budget, and yet

you cannotdefinitively predict the exact functionality of

what a team will deliver


26/104

SCRUM FRAMEWORK

Row 1 Row 2 Row 3 Row 4

0

2

4

6

8

10

12

Column 1

Column 2

Column 3


27/104

SCRUM FRAMEWORK


28/104

SCRUM FRAMEWORK


29/104

SCRUM FRAMEWORK

Role Responsibilities ClosestWaterfall

Role(s)

Product

Owner

Represent stakeholders interest / needs

Funding, Vision, Return on Investment (ROI), Product/Project Road

map

Capture and prioritize requirements

Decides where the team should go

Not how they get there

Not their speed

Inspect/ test working software at the end of each Sprint / iteration

Accountability for product success

Does not estimate stories

Customer,

Functional BA,

Project

Manager


30/104

SCRUM FRAMEWORK


31/104

SCRUM FRAMEWORK


32/104

SCRUM FRAMEWORK

Role Responsibilities Closest WaterfallRole(s)

Scrum

Master

Protect the team from outside interference

Help the team resolve impediments ASAP

Facilitator - Teach/guide the team and Product Owner to

effectively adopt Scrum Processes

Monitor the project: is the Team self managing, on target to meet

commitments of each sprint, productive and creative? Coaching rather than command & control,team on target to meet

commitments of each sprint, productive

Has no management authority

Does not have a Project Manager Role

Project Leader,

Mentor, Coach


33/104

SCRUM FRAMEWORK


34/104

SCRUM FRAMEWORK


35/104

SCRUM FRAMEWORK

Role Responsibilities ClosestWaterfall Role(s)

The

Team

Analysis, Estimation, Design, Development, Testing (Manual,

Performance, Automation) and Deployment

Self-manage and self-organize to achieve committed

deliverables.

Accountability for the success of each iteration

Attempts to build a potentially shippable product increment

every Sprint

Developer,

Designer, DBA,

Architect, Tester,

QA, BA


36/104

SCRUM FRAMEWORK - ROLES

SUMMARY


37/104

SCRUM FRAMEWORK


38/104

SCRUM FRAMEWORK - PBL


39/104

SCRUM FRAMEWORK - PBL


40/104

SCRUM FRAMEWORK- PBL

Product Backlog is a FORECAST ( not Exact)

Establishes teams velocity (how muchEffort a Team can handle in one Sprint)

Determining units of complexity. Size-category (T-Shirt size) Story points

Work days/work hours


41/104

SCRUM FRAMEWORK


42/104

SCRUM FRAMEWORK


43/104

SCRUM FRAMEWORK


44/104


45/104


46/104


47/104


48/104

SCRUM FRAMEWORK


49/104

SCRUM FRAMEWORK SPRINT PLANNING


50/104

SCRUM FRAMEWORK SPRINT PLANNING


51/104

SCRUM FRAMEWORK DAILY SCRUM


52/104

SCRUM FRAMEWORK -SPRINT REVIEW


53/104

SCRUM FRAMEWORK -SPRINT REVIEW


54/104

SCRUM FRAMEWORK -RETROSPECTIVE MEETING


55/104

SCRUM FRAMEWORK -RETROSPECTIVE MEETING


56/104

SCRUM FRAMEWORK -BACKLOG REFINING


57/104

SCRUM FRAMEWORK BACKLOG REFINING


58/104



59/104



60/104








61/104

SCRUM FRAMEWORK


62/104

How to Scrum

Product Backlogand Backlog Refinement


63/104

SCRUM FRAMEWORK -PBL & BR


64/104



65/104



66/104



67/104

SCRUM FRAMEWORK -PL & BR


68/104



69/104

How to Scrum Sprint Planning

SCRUM FRAMEWORK-


70/104

SCRUM FRAMEWORK-PREREQUISITES FOR SPRINT

PLANNING

Product Backlog is in ready state All important items have been assigned priority and a rough estimate Product Owner understand each User Story

SCRUM FRAMEWORK-


71/104

SCRUM FRAMEWORK-PREREQUISITES FOR SPRINT

PLANNING


72/104

SCRUM FRAMEWORK- OUTPUTFROM SPRINT PLANNING


73/104



74/104



75/104



76/104


Agreement of Sprint Goals Selection of Items from Product Backlog and their commitment to Sprint

BacklogPart I Prepare a initial list of Tasks which are necessary to undertake committed

PBIsPart II List of Team Members and their commitment for the Tasks Defined Sprint Demo Date Time and Place for Daily Scrum Length of Sprint Decide Estimated Velocity Calculate how many stories can be added without exceeding

estimated velocity

Estimated velocity = (Available man days) * (Focus factor)


77/104

How to Scrum Daily Scrum


78/104

SCRUM FRAMEWORK- DAILYSCRUM

SCRUM FRAMEWORK DAI Y


79/104

SCRUM FRAMEWORK- DAILYSCRUM

SCRUM FRAMEWORK OUTPUT


80/104

SCRUM FRAMEWORK- OUTPUTFROM DAILY SCRUM

Discuss Unplanned Tasks which are being encountered Discuss Updation of Time Estimates to Tasks Undertaken Update Task board with new time estimates


81/104

How to Scrum Sprint Review

SCRUM FRAMEWORK SPRINT


82/104

SCRUM FRAMEWORK- SPRINTREVIEW



83/104




84/104




85/104

SCRUM FRAMEWORK- SPRINTRETROSPECTIVE



86/104




87/104


The Scrum master shows the sprint backlog and, with help from theteam, summarizes the sprint. Important events and decisions, etc.

The rounds are done.

Estimated vs. actual velocityis evaluated. If there is a bigdifference it should be analyzed

When time is almost up the Scrum master tries to summarizeconcrete suggestionsabout what can be better next sprint.

SCRUM FRAMEWORKSOME


88/104

NEW VOCABULARY,SOME NEW

CONCEPTS

Sprint

ScrumMaster

Daily Scrum

ProductBacklog

BurnDownCharts

TeamRoom Tasks

SprintPlanning

SprintReview

SprintRetrospective

ScrumBag

Impedimen

tVelocity

DONE

BacklogRefining

Sidebar

EpicUserStory

Scrum Dev Team

ProductOwner

TimeBox


89/104

SCRUM FRAMEWORKBAD SIGNS

Product Owner is not available to clarifyrequirements

Product owner micro-manages the team

New stories get added in the middle of Sprint

Scrum Master assigns work to team members

Not everybody in Team available for Scrum meetings

Team insists on detailed requirements for estimation

Done is not really done! A project team has highly specialized job roles such

as Architect, Designer, DBA, or Tester.

Sprints are not always the same length

Why Scrum Is Powerful


90/104

y

Focus is on team's work, and team's work only

Daily communication of status occurs

Enables low-overhead empirical management

Makes impediments visible

Someone is willing to make decisions andremove impediments real-time


91/104

SCRUM FRAMEWORK

AGILE AND SCRUM FRAMEWORK


92/104








93/104

How to Scrum Pilot Project


94/104

SCRUM FRAMEWORKPILOT

Project: Develop a poster to create awarenessabout Agile in your office

Methodology: Scrum

Time Available: 45 mins

Sprint Planning : 5 mins

Sprint Length : 10 mins

Daily Scrum : 2 mins

Sprint Review : 5 mins

Sprint Retrospective : 5 mins

AGILE AND SCRUM FRAMEWORK


95/104








96/104


97/104


98/104

Reality : We are still planning work, but agile projects plan aroundrequirements, provide schedules through iterations, analyze the progress(iteratively and daily), and report on the progress to stakeholders throughdemonstrations and tangible progress.

You Know Youre Not Doing Agile

f


99/104

If 1. Team is co-located, but not sitting within the length of a

school bus to each other.2. Team is distributed, but there is an absence of microphones

and webcams and 1-2 meetings a day.

3. Team has not delivered anything to real users in the last 3

months.

4. If no user has seen real running software inside the lastmonth.

5. They don't have the output of last month's retrospective on

the wall.

6. They don't have fully automated unit tests, and a large

number of acceptance tests aren't automated.

7. They're not having a build integration at least once a day.

8. They write big requirements documents, and they don't know

how to split those up into smaller pieces.

9.

They have itty-bitty requirements on the order of "here's what" ' -

Agile Is NOT A Silver Bullet


100/104

Courage!!!

Constant business involvement

Need for more discipline

Greater emphasis on testing (and automation)

Whole organization involvementKeep an open mind

Become a learning organization

Naresh Jain: http://www.slideshare.net/nashjain/agile-is-the-new-waterfall

New Skills Are Needed!


101/104

IT:

Handling Abstraction. Effective Facilitation and Agile

Requirements Gathering with Just Enough Documentation

Leadership, Teamwork and Collaboration.

Ability to breakdown stories into small manageable tasks.

Ability to focus on getting stories completed with low/nobugs by incorporating Test Driven Development.

Ability to work and collaborate within the IT department

(cross functional).

Communication, synchronization between multiple teams.

Focus more on business value (ROI) than technicalimplementation.

Do not lose sight of the Big Picture. Comfortable with

iterative and incremental development.

Technical Best Practices For Teams


102/104

Test-driven development

Automated builds andcontinuous integration

Collective code

ownership

Continuous refactoringFrequent design and

code reviews

Highly collaborative

team processesHigh customer contact

and max transparency

Automated acceptance

and regression tests

References


103/104

Test-driven development

Automated builds and continuous integration

Collective code ownership

Continuous refactoringFrequent design and code reviews

Highly collaborative team processes

High customer contact and max transparency

Automated acceptance and regression tests

References


104/104

agile at work

Documents