Agile Overview NZPolice
Transcript of 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
-
8/6/2019 Agile Overview NZPolice
2/51
-
8/6/2019 Agile Overview NZPolice
3/51
You can never step in thesame river twice
- Buddhist proverb
-
8/6/2019 Agile Overview NZPolice
4/51
-
8/6/2019 Agile Overview NZPolice
5/51
-
8/6/2019 Agile Overview NZPolice
6/51
Cultural Requirements
Continuous communicationbetween
Suppliers and Users
Sponsorswho reward business value and
value the product Delegationto front-line teams
Negotiationpermitted
-
8/6/2019 Agile Overview NZPolice
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/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
9/51
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
12/51
Good, Bad, and ?
(Management perspective)
+Customers andSuppliers are accountable for
success!
-
8/6/2019 Agile Overview NZPolice
13/51
Agile Software Methodologies
[Rapid Application Development (RAD)]
Dynamic Systems Development Model (DSDM)
Extreme Programming
Scrum
Crystal
Agile Unified Process (AUP)
Lean
-
8/6/2019 Agile Overview NZPolice
14/51
Scrum
-
8/6/2019 Agile Overview NZPolice
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)
-
8/6/2019 Agile Overview NZPolice
16/51
Scrum Activities
Project Planning
Sprint (Iteration) Definition & Completion
Daily Sprint Status Meeting
-
8/6/2019 Agile Overview NZPolice
17/51
Scrum Project Planning
Define Scope
Identify Stakeholders
Secure Sponsorand Customerbuy-in
Identify Product Owner, Team &ScrumMaster
DraftRequirements
Define Project Backlog
DraftRelease Schedule
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
20/51
Sprint Retrospective
Team & ScrumMaster
Every 2-4 iterations
Identify chronic obstacles
Identify process improvements [Define process improvement plan]
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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!)
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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.
-
8/6/2019 Agile Overview NZPolice
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)
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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)
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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.
-
8/6/2019 Agile Overview NZPolice
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]
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
41/51
Q & A
-
8/6/2019 Agile Overview NZPolice
42/51
Scrum
-
8/6/2019 Agile Overview NZPolice
43/51
Scrum on One Page
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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
-
8/6/2019 Agile Overview NZPolice
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