Agile Overview NZPolice

8/6/2019 Agile Overview NZPolice

1/51

Introduction to Agile

MethodsNed Horvath

Massey University

Prepared for New Zealand Police

20 Jul 07


2/51


3/51

You can never step in thesame river twice

- Buddhist proverb


4/51


5/51


6/51

Cultural Requirements

Continuous communicationbetween

Suppliers and Users

Sponsorswho reward business value and

value the product Delegationto front-line teams

Negotiationpermitted


7/51

Agile Manifesto

Customer satisfaction by rapid, continuous delivery

of product

Working product is delivered frequently (weeksrather than months)

Working product is the principal measure ofprogress.

Even late changes in requirements are welcomed.

Close, daily, cooperation between customers andsuppliers


8/51

Agile Manifesto ctd

Face-to-face conversation is the best form of

communication.

Projects are built around motivated individuals, whoshould be trusted

Continuous attention to technical excellence andgood design.

Simplicity

Self-organizing teams Regular adaptation to changing circumstances


9/51


10/51

Good, Bad, and ?

(Customer perspective)

+ Receive value early and often

+ Change orders are OK

+ Can respond rapidly to changing conditions

+ Transparent development process+ Stop when needs met

No set end of project, so no set price

? You set and change development priorities

? Continuously engaged with supplier team


11/51

Good, Bad, and ?

(Supplier perspective)

+ Customer resolves ambiguous requirements

Customer can change & reprioritise requirements+ Deliver value early and often

+ No schedule slips

+ No death marches? You own the estimates

? Transparent development process

No job security (except by delivering value)? Customer owns the priorities

? Stay engaged with customers


12/51

Good, Bad, and ?

(Management perspective)

+Customers andSuppliers are accountable for

success!


13/51

Agile Software Methodologies

[Rapid Application Development (RAD)]

Dynamic Systems Development Model (DSDM)

Extreme Programming

Scrum

Crystal

Agile Unified Process (AUP)

Lean


14/51

Scrum


15/51

Scrum Roles

Small (6-15) Team

ScrumMaster(guide, provide cover, dealwith non-technical obstacles. Nota manager)

Product Owner(Customer or Marketing)

Other Stakeholders: Sponsor, Press,

Meta Team - larger teams comprise smallscrum teams for components (up to 800contributors claimed by Schwaber)


16/51

Scrum Activities

Project Planning

Sprint (Iteration) Definition & Completion

Daily Sprint Status Meeting


17/51

Scrum Project Planning

Define Scope

Identify Stakeholders

Secure Sponsorand Customerbuy-in

Identify Product Owner, Team &ScrumMaster

DraftRequirements

Define Project Backlog

DraftRelease Schedule


18/51

Sprint Definition & Completion

Sprint Planning Meeting

Product Owner, ScrumMaster, Team; other Stakeholders welcome

Establish/Agree Sprint Goal: deliver some explicit functionality One sentence; Product owner defines, team accepts Product owner will not expand/reprioritize during the sprint

Create sprint backlog: prioritized list of estimated, assigned tasks Items from previous sprint backlog (e.g. bugs, incomplete features) New features from Product Backlog to be delivered(implemented and tested) New features for nextsprint that need research (definition, spikes) Delivery Preparation actvities [Budget 75% of available time net of planned unavailability]

Artefacts: Blocks list, burndown chart

Sprint Review Meeting Review and demo accomplishments Update Release [and Product] Burndown Chart


19/51

Scrum - Daily Sprint Status

15 minutes (ideally: standing up)

Team speaks, ScrumMaster facilitates, others listenonly

What have you done?

What will you do? What obstacles are in your way?

Identify and assign - dont handle!

ScrumMaster records obstacles, updates blocks listand sprint burndown chart see spreadsheet example


20/51

Sprint Retrospective

Team & ScrumMaster

Every 2-4 iterations

Identify chronic obstacles

Identify process improvements [Define process improvement plan]


21/51

Spikes

A Spikeis a bit of exploratory work, the aim of

which is to understand enough to estimate atask, pick a technology, or assess a tool forfitness for a purpose.

Typically timeboxed to 8 hours or less

The outcome is a recommendation or estimate

Any code resulting from a spike is usually thrownaway

Fail early and often - avoid analysis paralysis


22/51

Use Cases (Cockburn)

Product Planning: Scope Exhaustively Identify Actors, Events, and Goals

Actor: verbObject Speaking as , I want to

Ask Why? Capture the outermost summaryuse

cases to see who really cares. Revise, repeat. Product Planning: Releases

Group summary use cases into prioritized usable

collections Verify draft release structure with stakeholders

(expect to revisit this frequently!)


23/51

Use Cases ctd

Flesh out sea level use cases breadth-first

Capture stakeholders and interests, preconditions andguarantees Write the main success scenario (MSS) 6-9 steps, each:

Show a goal succeeding

Highlight the actor's intention, not the user interfacedetails. Have an actor pass information, validate a condition,

or update state. Exhaustively list the extension conditions (exceptions)

Write the extension-handling steps minimum guarantee

Review with customers


24/51

Use Cases + Scrum

YAGNI: Use Cases get fleshed out only as the

Product Owner identifies them as candidates for anear-term Sprint

Customer-Developer Communications: Customerscan read and criticize (and even write) use cases

Use cases UML Sequence DiagramsDefine (system) public interfaces

Invent/revise internal components/classes, define public

interfacesUpdated UML class diagram - identify refactorings

Design directly traceable to requirements


25/51

Use Cases + Scrum ctd

Use cases UI design

Use cases System test design (black box)

Use cases Acceptance test design

Use cases Documentation & Training

Use case driven supports YAGNI

Use cases identify functionalrequirements

only


26/51

Case Study 1: Airline Ops

Customer: Southwest Airlines, 2001

Developer: CALEB Technologies Problem: Recover Crew after disruption

Talented but inexperienced developers led byexperienced leader (but no previous Scrumexperience)

Inexperienced QA team led by experienced leader

Optimization experts (OR Ph.D.s) with no formalsoftware engineering training


27/51

Airline Ops ctd

Initial use cases created by customer (1 yr)

Clear where understood, vague elsewhere

Extremely vague around recovery strategies

Use cases supplemented with explicit

problem scenarios (Acceptance TestFramework)

> 20 stove pipe legacy systems, customerbeginning to integrate with J2EE.


28/51

Airline Ops - Results

Managed to 80% of budget target (time and money)

Close collaboration to define/refine Use Cases 3 week sprints Use cases drove UML design, system testing, UI

design, user documentation Close collaboration with QA shortened ALL phases. First delivery to customers at 4 months

Acceptance testing commenced immediately

Customer deliveries at 6 week intervals Delivered product was operational at 13 months

(original budget 15 months)


29/51

Opt Lessons Learned

Customer-developed Use Cases provided a

framework, hard questions required closeinteraction of subject matter experts

Scrum spike procedure very effective at failing

early and often Scrum daily meetings & short timeboxes were

particularly valuable with inexperienced personnel

Integrated Development/QA team kept cycles tight Scrum Master communication skills are decisive


30/51

Case Study 2: Password Sync

Customer/Developer: Sun Microsystems,

2002 Problem: single sign on across LDAP

servers

Talented, experienced developers, noprevious Scrum experience except leader

Intimate experience with one LDAPimplementation


31/51

Sync ctd

Tight timeframe and budget (4 developers, 1

QA, one lead, 4 months)

No formal scope, requirements

Geographically distributed team, multipledemands on personnel

Lots of pre-existing (but poorly understood)

development process Already late


32/51

Sync - Issues

Scope ill-defined

Target LDAP implementations? Target substrate (JMS, DBMS)?

Boil the ocean - initial deliverables included loggingframework and other cool subprojects

Lead had little project management experience

Management wants it yesterday

Culture rewards innovative individuals


33/51

Sync Restart after 3 months!

Pulled customer (marketing), test, development,

management into one room, defined scope Feasibility study (2 weeks) Use Case list, defined

initial substrate

Created road map buy-in (?) Instituted Scrum process (elevated Scrum-

experienced lead)

Instituted regular conversations with marketing


34/51

Sync - Results

First customer delivery 4 months after restart

Scope insufficient! Developed 2 interested outside customers

Second delivery 9 weeks after first

Subsequent deliveries at 6 week intervals Operational at targeted customers at third release (8

months after restart, 11 months after initial start)

Resources redirected after 5th release (11 monthsafter restart)


35/51

Sync Lessons Learned

Scope is decisive

Budget (even if you have to make one up) Beware customer surrogates Use Cases successfully defined the functional

boundaries Non-functional requirements (list of supported

systems and substrates) was the real challenge;resolved with spikes

Scrum allowed a track record of failure to be

transformed into a series of milestones that could behit

Morale improved once Scrum instituted


36/51

Agile at BT Exact (IT) May 2004: 8k employees, 6k contractors, 24 timezones

The Mandate: every project delivers value every 90 days Training a challenge

The Agile Road Show - half-day events to promote awareness,held at BT Exact's principal UK offices.

Agile Program Days - one-day "deep dive" events to providemore in-depth education on Agile delivery and to collaborativelyexplore how these approaches could be applied to the projectand program in question.

Agile Learning Projects - a series of project-level engagements

were created to provide learning opportunities and successstories.

Ref: http://tinyurl.com/25zxvg


37/51

BT Exact ctd

Problem: Too Few Coaches

Pair Coaching Apprentice Coaching

Agile Boot Camps

Results ISO 9001 certification Jan 2006. Assessor: This

was a fundamental change within the business.

We were impressed by the scale of thetransformation and how fast the organisationimplemented the changes.


38/51

Agile for Business Processes

Agile is becoming a buzzword (and a trademark:

BT Agile is CRM outsourcing) BTs rollout followed Agile principles:

People to people communication

Training driven by problems from attendees One size does NOT fit all (Cockburn: Crystal)

Consistent with current management theory

(Drucker, Peters) and Quality process [Ask Stephen about Telecom]


39/51

References

Cockburn, Alistair, Writing Effective Use Cases,

Addison-Wesley 2000, ISBN 0-201-70225-8 Schwaber, Ken, Agile Software Development with

Scrum, Prentice-Hall 2001, ISBN 0-130-67634-9

Boehm, B. & R. Turner, Balancing Agility andDiscipline: A Guide for the Perplexed, Addison-Wesley 2004. ISBN 0-321-18612-5.

Ambler, Scott, Making the Unified Process Work in

Practice, http://www.ambysoft.com/unifiedprocess/ Linda Rising and Norman S. Janoff, The Scrum

Software Development Process for Small Teams,IEEE SOFTWARE July/August 2000


40/51

References ctd.

Cohn, Mike, Agile Estimating and Planning,

Prentice-Hall 2005, ISBN 0-131-47941-5 M. Poppendieck and T. Poppendieck, Lean

Software Development, Addison-Wesley, 2003,ISBN 0-321-15078-3

http://www.ControlChaos.com/ http://www.ScrumAlliance.org/ http://AgileAlliance.org http://AgileManifesto.org Other books by Cockburn, Schwaber


41/51

Q & A


42/51

Scrum


43/51

Scrum on One Page


44/51

Alistair Cockburn Humans and Technology, Inc., 1998-9 Slide 11

Number of people involved

Criticality

(defectscauselossof...

)

Comfort(C)

Essentialmoney

(E)

Life(L)

+20%

. . .Prioritized for Legal Liability

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D500 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Prioritized for Productivity & Tolerance

Choose a Methodology according to(project size, system criticality, team priorities)

Discretionary

money(D)

Crystalis a family of methodologies.

Technologieschangetechniques.

Cultureschange

norms.

Distanceschangecommunication.

Not even conceivable to have a single, common methodology.

Every project is slightly different and needs its own.

- Alistair Cockburn

B fi f I l i A il


45/51

Benefits from Implementing Agile

1. Deliver benefits early (First Iteration is demonstrable)

2. Avoid significant rework by only doing just-in-time detailed design

3. Avoid dead-end design decisions by managing with LPMdecisions and trade-off matrix

4. Raise quality by moving testing forward in the process

5. Become responsive by supporting scope adjustments every

iteration

6. Become reliable by instituting regular heartbeats to the team

7. Increase estimating accuracy by working in small chunks

8. Decrease risk by always having working software

9. Increase throughput via real-time visibility

10. Increase team moral by dropping the death marches.

- Ryan Martens, Rally SDC

Four Paths to Great Software


46/51

(Consistently Responsive)

Hierarchical

Agility &Innovation

Culture of Discipline

High

High

Low

Low

Bureaucratic Start-up

Agile

Development

AgileOrganization

Path 4 Scaling & ExtendingAgile

Path 2 Discipline

Path 1 Agility

Waterfall

GreatOrganization

Chaos Solo Virtuosos

Path 3 Agility &Discipline

(Adapted from Collins Good-to-Great Matrix of Creative Discipline, 2002)

Evolution of Agile inside a


47/51

Evolution of Agile inside a

team1. Rollover

Implement daily stand-up meetings, create an automated build processto always be close to shippable code

2. Apply Agile Project Management (APM) practicesCreate and track a Backlog of stories, a Release, and its Iterationsthrough to AcceptanceCreate short iterations and release small batches

3. Extend APM upstream into requirements elaborationCapture use cases, scenarios for richer requirements statements, and

build parent-child relationships to pull testing forwardBuild tight link to the customer for feedback

4. Extend APM into test to increase quality measuresTrack test case results to story cards, manage defects from iteration toiterationImplement an automated acceptance testing framework


48/51

Technical Team Disciplines

1. Develop coding and naming standards

2. Track remaining effort on tasks3. Automate the build process and share results

4. Implement a Testing Framework that includes unit

test, application tests and GUI tests5. Develop a continuous integration process and

server

6. Move toward collective code ownership7. Cross-train through pair programming to increase

flexibility, domain knowledge and reduce risk


49/51

Suggested Process

Internal champion

Suggested reading

Brown bag discussions

Guest lectures

Local Agile/XP user groups

Agile Conferences

Agile Development XP / Agile Universe

Software Development

Where to start on the web

www.agilealliance.org

Articles, events & user groups

Great resource for gettingstarted with Agile

Suggested Reading

Home of SCRUM

www.controlchaos.com/ Agile & Iterative

Development

www.craiglarman.com

Lean Software Developmentwww.poppendieck.com/

Agile Project Management

www.jimhighsmith.com/

Rally Whitepaper

Tactical Management ofIterative Development:Achieving Competitive

Advantage,www.rallydev.com

Resources to Self-teach Agile


50/51

Training Opportunities

Lean Manager &Practitioners Classes www.poppendieck.com/co

urses.htm

SCRUM Master Class

www.controlchaos.com/certifiedscrum/

eXtreme Programming www.xprogramming.com/

xpmag/services.htm

Rallys 1-day AgileWorkshop

Mentoring Programs

Individual consulting: Ken Schwaber

Mary & Tom Poppendieck

Jim Highsmith

Mike Cohn

Or see www.agilealliance.org

Rally Agile Pilot Program 1-day team workshop

Developing the Agile

Management Team Delivering the first Agile

iterations

Professional Help


51/51

11 Ways for Agile Adoption to Fail

1. Ineffective use of the retrospective

2. Inability to get everyone in the planning meetings3. Failure to pay attention to the infrastructure required4. Bad ScrumMasters

5. Product Owner is Consistently Unavailable, or There are TooMany Owners Who Disagree

6. Reverting to Form7. Obtaining Only "Checkbook Commitments" from Executive

Management

8. Teams Lacking Authority and Decision-Making Ability9. Not Having an Onsite Evangelist for Remote Locations

10. A Culture that Does Not Support Learning

11. Denial is Embraced Instead of the Brutal Truth

- Jean Tabaka, http://tinyurl.com/2og2f7

Documents

Agile Overview NZPolice