Agile Development Product Delivery For Successful Organizations
-
Upload
marc-crudgington -
Category
Documents
-
view
1.204 -
download
1
description
Transcript of Agile Development Product Delivery For Successful Organizations
Product Delivery for Successful OrganizationsAgile Development:
© Copyright Pacific Technology Consulting Group, LLC
Marc Crudgington
Interactive Agenda:Pick a Topic
Tools
Scrum
Build Delivery
Framework vs. Process
Agile Success
Adopting Agile
Agile Types
Agile Principles
Impediments
Resources Iterative or Predictive
Estimating/Planning
Evolution
Buzzwords
2
3
• Career– US Air Force, 3Com, ONI/Ciena, Mortgage/Countrywide, KPMG,
Jefferson Wells, Autobytel, ASM
• Entrepreneurship– Adventure Travel, Consulting, Mortgage, Consulting
• Education– MBA, BBA, ACS, AEE
• Certifications– PMP, CSM, TOGAF, ITIL, ISS, CISM, CISA
• Personal– Married to Maricris 01/2004, Two boys: Jake 5 / Luke 2
Bio / Info
4
Framework vs. Process
Framework Process
• Set of principles with no parent-child relationship which within activities are performed.
• Not all components required to be used
• Not always used in the same order
• Less structured• Agile
• Prescriptive and linear series of steps taken to repeatedly generate the same output.
• All components used• It is a sequence / same order• Structured• PMBOK (Project Management
Body of Knowledge), Waterfall
5
• Characteristics– Plan driven, heavy load upfront, structured– Sequential, bureaucratic, change resistant– Design: intensive, 10%; Construction manual, 90%– End result pre-determined
• Steps– Idea, Requirement, Design, Construct, Integrate, Test,
Implement, Maintain
Iterative or PredictivePredictive
6
• Use when– Project familiar– Inexperienced developers– Project team is large and project is complex– Thoroughly documented, demands order– Predictability versus change, requirements stable
• IMO– Civil engineering, Construction– Maybe government, government contractors, pharma?
Iterative or PredictivePredictive
7
• Characteristics– Ambiguity okay, code oriented, adaptable– Welcome change, feedback, people vs. process– Design: creative, 80%; Construction automate, 20%– End result evolving
• Steps– Brainstorm/plan, Development, Deliver, Feedback
Iterative or PredictiveIterative
8
• Use when– Project evolves or a little unknown– Accept change– Team small; strategies for large/split– Rapid change can occur
• IMO– Information Technology
Iterative or PredictiveIterative
9
Iterative or PredictiveComparison
Agile Waterfall
Informal/Incremental Documented/Steps
Teamwork/Collaboration Individual
Continuous Integration End or Milestones
Light process Heavy process
Open door Limited
Cross trained Segmented
Active developers Developers sit and wait
No surprises at end Validate requirements
QA helps produce QA certifies
Empowerment Controlling
Best app for customer Satisfy requirements, contracts
10
Agile PrinciplesManifesto for Agile Software Development
We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items onthe right, we value the items on the left more.
11
Agile PrinciplesPrinciples behind the Agile Manifesto
We follow these principles: 1. Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software. 2. Welcome changing requirements, even late in development.
Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
12
Agile PrinciplesPrinciples behind the Agile Manifesto (cont.)
7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The
sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
13
Agile Principles
Authors of the Agile Manifesto
Kent BeckMike BeedleArie van BennekumAlistair CockburnWard CunninghamMartin Fowler James GrenningJim HighsmithAndrew Hunt
Ron JeffriesJon KernBrian Marick Robert C. MartinSteve MellorKen SchwaberJeff SutherlandDave Thomas
14
Adopting Agile
15
Adopting Agile Success Factors
• Business problem to solve− Goal to achieve; visible
• Freedom to change− No micromanaging; right people in, wrong people moved
• Engergized team− Familiar with; team spirit; about product/goal
• Customer communication− Dedicated; gets ’it’; respected in organization
• Collaboration− must work together; fight the ”PC glare”
• Quality focused− up front; clean; embodied in the product; automate
• Incrementalism− JIT features; small chunks; task-by-task
16
Adopting Agile Adoption Patterns
• Start Small− Pilot team; >$ for mistakes, success optimized, experts− False hope, takes longer, sign of non-commitment, two types
• All In− All teams; management commitment, quicker, one type− Risk, cost, reorg (?), stress
• Technical Practices First− Concentrate on how to develop; quicker transition− More difficult, costly, less user-centric thinking
• Iterative First− Concentrate on the repetitive cycles; less resistence, easier− May not adopt necessary engineering processes
17
Adopting Agile Adoption Patterns (cont.)
• Stealth Mode− Kept to the Agile team; focus on success, less distractions− No org support, skeptics
• Times Square Approach− Communicated; success incentive, support, out skeptics− Announce then fail, skeptic disruption, ’vendor wolves’
Organizational Effects
• Developers; micromanage/freedom/talent | no forethought
• Management; new features, progress, impact, project end
• HR; receive complaints, corrective action,
• Marketing; feature announcement, release date, left out
18
Adopting Agile
Top-Down Bottom-Up
Organization sponsored Department/Project sponsored
Visibility Fewer Monday Morning QB’s
Executive strength Focused pressure
Central change team Freedom to define change
Execution consistency Time to learn, refine process
More measurable Still measurable
Business problem solution Appropriate business problem
• Communication • Best practice / learn from Agile Coach• Tools to assist• Raise the bar• Plan for management and governance
19
Impediments
TeamOrganization
• Agile knowledge
• Work in silos
• Individual resistance
• Proper tools
• Documentation requirements
• Management support
• Management control
• Department resistance
• Trust in team/process
• Investment required
• Unrealistic expectations
• Customer commitments
20
Agile TypesAgile Survey 2006
21
Agile TypesAgile Survey 2009
22
Agile TypesAm I Agile?
Adaptive, empowered, self-organizing
Absence of phases
Use of minimal planning
Scalable
Continuous process refinement
Iterative and incremental
Working software measured in progress
Artifacts are minimized
Customer involvement throughout
Adaptive, empirical customer relationship
Emergent requirements
Frequent inspection
Individuals and Interactions
Working software
Customer Collaboration
Responding to Change
23
Agile TypesFDD (Feature-Driven Development)
• Characteristics− UML modeling focused, iterative, testing absent, small teams
• Processes− Develop an overall model − Build a Features List− Plan by Feature− Design by Feature− Build by Feature
• Best Practices− Domain Object Modeling, Feature Teams, Visible Progress,
Developing By Feature, Inspections, Individual Class Ownership, Regular Builds, Configuration Management
− Requires all 8 to be FDD
Done Sequentially
Done Iteratively
24
Agile TypesFDD (Feature-Driven Development)
• Features− Primary unit of coding− Similar to XP User Stories or Scrum Product Backlog− Completed within two weeks
• Feature Set− Collection of features− Assigned to a Chief Programmer and team
• Major Feature Set− A domain area, one or more feature sets
25
Agile TypesAm I Agile?
Adaptive, empowered, self-organizing Not so much
Absence of phases No
Use of minimal planning No
Scalable Yes
Continuous process refinement Not so much
Iterative and incremental Somewhat
Working software measured in progress No
Artifacts are minimized Somewhat
Customer involvement throughout Yes
Adaptive, empirical customer relationship Yes
Emergent requirements No
Frequent inspection Yes
Individuals and Interactions
Working software
Customer Collaboration
Responding to Change
26
Agile TypesAgile Modeling
• Characteristics− Collection of values, principles, and practices− Meant to be tailored into other methodologies
• Values− Communication, Simplicity, Feedback, Courage, Humility
• Principles− Assuming simplicity (modeling), embracing change (working),
incremental change (agility), rapid feedback (reflects needs), model with a purpose (know)
− multiple models (for intellect), travel light (discard), content (many ways), communication (open/honest), quality (focus)
27
Agile TypesAgile Modeling
Best Practices
28
Agile TypesAm I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Use of minimal planning Yes
Scalable Yes
Continuous process refinement Somewhat
Iterative and incremental Somewhat
Working software measured in progress Yes
Artifacts are minimized Yes
Customer involvement throughout Yes
Adaptive, empirical customer relationship Yes
Emergent requirements Yes
Frequent inspection Yes
Individuals and Interactions
Working software
Customer Collaboration
Responding to Change
29
Agile TypesXP (Extreme Programming)
• Characteristics− Collection of values and practices− 1 – 4 week iterations, all dials set to “10”− Stories (functionality), on-site customers− UNIT TESTING, simplest thing − YAGNI (You Aren’t Gonna Need It)
• Values− Simplicity: what is needed and asked for, no more− Communication: face to face, daily; work together on everything− Feedback: every iteration seriously delivering working software;
listen change as needed; adapt process to project − Respect: everyone contributes; developers respect customers vice
versa; management respects authority over work− Courage: truth about project/estimates; no fear no one works
alone; adapt to changes
30
Agile TypesXP (Extreme Programming)
Workflow
31
Agile TypesAm I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Use of minimal planning Yes
Scalable Yes
Continuous process refinement Mostly
Iterative and incremental Yes
Working software measured in progress Yes
Artifacts are minimized Yes
Customer involvement throughout Yes
Adaptive, empirical customer relationship Yes
Emergent requirements Yes
Frequent inspection Yes
Individuals and Interactions
Working software
Customer Collaboration
Responding to Change
32
Agile TypesScrum
• Characteristics− Framework or Method NOT a Process or Technique− Self organizing teams− Progress in month-long or less “Sprints” (iterations)− Requirements are “Product Backlog”− Engineering “Free for Team”− Rules to maintain / be Agile on project
• Scrum Team− 7 to 11 members optimal (PO, SM, Team)− Full-time i.e. devoted to Scrum Team; exc. Sys Admin− Change only between Sprints
• Etc.− Sprint/Stabilization Sprint: Design, code, test− NO CHANGES during Sprints…take your scope creep and…− Few artifacts, Burndown charts
33
Agile TypesAm I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Use of minimal planning Yes
Scalable Yes
Continuous process refinement Yes
Iterative and incremental Yes
Working software measured in progress Yes
Artifacts are minimized Yes
Customer involvement throughout Yes
Adaptive, empirical customer relationship Yes
Emergent requirements Yes
Frequent inspection Yes
Individuals and Interactions
Working software
Customer Collaboration
Responding to Change
34
Scrum Overview
• Scrum History– Presented 1995, Jeff Sutherland/Ken Schwaber– Not a process or technique, framework (within you can
employ processes/techniques
• Scrum Theory– Empirical process control: continuous cycle of inspection
for correct operation, adapt as needed– Three pillars for implementation
• Transparency: affect the outcome is visible to those managing; what is being seen must be known
• Inspection: to detect unacceptable variances; skill/diligence• Adaption: adjustment of unacceptable variances; quickly; Daily
Scrum, Sprint Review & Planning meetings; Sprint Retrospective
35
Scrum Overview
• Scrum Content– Scrum Team
• ScrumMaster, Product Owner, the Team
– Time-Boxes• Release Planning Meeting, Sprint Planning Meeting, Sprint,
Daily Scrum, Sprint Review, Sprint Retrospective
– Artifacts• Product Backlog, Sprint Backlog, Release Burndown, Sprint
Burndown
– Rules• Connect/unite each: Scrum time-boxes, roles, and artifacts• Rule: Daily Scrums last only 15 minutes• Rule: Only the Team talks during Daily Scrums
36
Scrum Overview
• Scrum Team– Product Owner
• One person only• Manages Product Backlog, ensures value of work
• Tip: product manager or business function manager – ScrumMaster
• Coaches Scrum Team / organization, removes impediments• Upholds Scrum values, practices, rules• Tip: works to identify and instantiate Product Owner
– Team• Developers• Tip: 7 optimal, + or – 2 is okay
37
Scrum Overview
• Scrum Time-Boxes– Release Planning Meeting
• Establishes: plan and goals, high priority Product Backlog, major risks, features/functionality
• Sets probable delivery date and budget
– Sprint• A time-boxed iteration, max is 1 month• Consist of Sprint Planning Meeting, development work, Sprint
Review, Sprint Retrospective• One after other, no time in between Sprints
– Sprint Planning Meeting• Iteration is planned, 8 hours for 1 month Sprint• What/How: top priority Product Backlog/Team decides work• Sprint Goal: objective through Product Backlog implementation
38
Scrum Overview
• Scrum Time-Boxes (cont)– Sprint Review
• 4 hours per 1 month Sprint, Scrum Team/stakeholders• What was done, what remains; what went well, problems,
resolution; demo of work, Q&A• Input for next Sprint Planning Meeting
– Sprint Retrospective• 3 hours per 1 month Sprint, Scrum Team• Inspect Sprint (people, relationships, process, tools)• Actionable improvements to implement in next Sprint
– Daily Scrum• 15 minutes, inspect/adapt, same place and time• What: Accomplished, Going to do, Obstacles• Improve communication/knowledge, remove impediments
39
Scrum Overview
• Scrum Artifacts– Product Backlog & Release Burndown
• Requirements for product, evolves and changes• List of all features, functions, technologies, enhancements, bug
fixes• Product Owner: contents, availability, prioritization• Graph for sum of Product Backlog effort in time
– Sprint Backlog & Sprint Burndown• Product Backlog tasks Team turns into “done” increment• Tasks decomposed/developed during Sprint Planning Meeting• One day or less per task (Sprint Backlog item)• Sprint Backlog only change by the Team• Burndown is a graph of daily estimates of remain sprint work
40
Scrum Overview
Sprint Burndown Chart
41
Scrum Overview
Scrum Sprint
42
The Planning Onion
Planning/EstimatingGeneral George S. Patton - "A good plan, violently executed now, is better than a perfect plan next week.”
43
• Organizations culture
• IT infrastructure investment
• Sponsor / Management commitment
• Project selection
• Agile team selection
• Training needed
• Expert access
• Project only assignment
• Mandatory documentation
Pre-planning points
Planning/Estimating
44
• All stakeholders
• Release goal
• Risks
• Conditions of Satisfaction (Features / Functionality, Delivery,
Budget)
• Priority of Feature Set (confirm project idea first)
• Estimating the Product Backlog or Feature Set
• Change Management strategy
• Define ’Done’
Release Planning
Planning/Estimating
45
• Daily Stand-up (Time/Place)
• Technical process
• Tools discussion (code migration, QA, project management,
Backlog)
• Iteration timebox
• Capacity of team
• Backlog priority (client: ”more of this, less of that”)
• Tasks to complete Product Backlog item
• Size of Product Backlog item
• Velocity (previous iterations/sprints)
Iteration Planning
Planning/Estimating
46
• Inspect and Adapt meeting
• Accomplishments
• Going to accomplish
• Impediments in the way
• Coordinate individual activities
• Wrap-up
Daily Planning
Planning/Estimating
47
• Product Backlog, Iteration Backlog, Tasks
• Size not Time
• Estimation types− Story points: Size and complexity, numerically relevant (10 = 5*2),
relative estimating, focus on size vs. duration, units added together− Planning poker: Iterative approach
1) Estimators get deck of cards with valid estimates2) Product owner reads story, briefly discussed3) Estimators selects card as estimate4) All estimators turn cards over5) Discuss differences (outliers)6) Re-estimate until they come together Good results: do the work estimate the work, justify estimates, group discussion, relative vs. absolute, involves all
− Fibonacci number: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ...
Estimating
Planning/Estimating
48
• Pair Programming– Typing, Reading, Both Thinking; discuss often, instant review, helps
inexperienced developers, accountability, collaboration
• No Code Ownership– Anyone can review and fix code; inexperienced limitations
• Code/Test– Automate tests; ‘smoke tests’, integration testing; raise visibility
• Test First Design– Writing code against test for requirements; think through design
• Refactoring– Improve readability and maintainability; reduce complexity
Build DeliveryCoding Practices
49
• Automate the Build– Repeatable, build anytime
• Build is Self-Testing– Build includes automated testing, covers large part of code base
• Daily Commits– Quicker failure, bugs/defects founds sooner
• Commits create Builds– Integration is tested daily
• Keep Builds Fast– Developers have status quickly; queue of builds, email status
Build DeliveryIntegrate Often
50
Tools • Consulting firm
– Agile transformation– All parts of organization
• Agile Coaches– Understanding of Agile processes; ease transition for team– Directory at: Agile Alliance and Scrum Alliance
• Project Management– Built for Agile (hosted/on-premise; high cost/low cost)– Agile templates, dashboards
• Build/Test– Integration, comparison; code evaluation, modeling, bug isolation
• Vendors/Products– Rally Software, CollabNet, IBM, Microsoft, JUnit/XUnit,
ScrumWorks, Electric Cloud, OpenMake Software
51
Tools
52
• Organization− For holistic success devote attention downstream− Manifesto implies organization (customer, business people,
feedback)− Greater role in decision making, product outcome− Better collaboration with other departments
• Organization Tips− Pick one problem to solve− Don’t forget governance and regulatory requirements− Incentives and Rewards− Customer interaction with departments
Agile SuccessImpact
53
• Agile Team− Development ownership in process (estimate, quality, delivery)− New techniques for meeting deliverables− Retrospectives/Feedback to immediate improvement− Defects caught early− PM’s/ScrumMaster becomes the snowplow− PM’s/ScrumMaster provide vs. need, coach vs. enforcer
• Agile Team Tips− Adopt the right mix (maybe more than one)− Initial focus on team principles and build practices− Team consistency/accountable to one another− Empowerment is not a noun, it is a verb− Do not under estimate the challenge of transforming− Utilize tools to fullest extent
Agile SuccessImpact
54
• Needs− Assessment plan− Support plan (training, coaches, management)− Balance business needs with technical − Realize change effects all moving parts− Smaller teams, self managed, reduced silos− New skills, automate the routine
• Results− More transparent organization− Realistic product horizons− Better moral− Reduced time to market− Quality improvement− Less surprises− Higher customer satisfaction
Agile SuccessFull Potential
55
• Done– Shippable increment of product containing all Product Backlog for
the increment– Must be additive to all prior increments– Defined by Team, Product Owner informed
• Continuous Integration– Integrating of code by team members at a frequent pace (daily)– Can produce numerous builds daily (10 team members = 10 builds)
• Kanban– A Lean Manufacturing “Pull” process developed by Toyota– Software development used the same process with a physical task
board (To Do, In Progress, Done, etc.)
Buzzwords
56
Resources
• People− Kent Beck, Jeff Sutherland, Tobias Mayer, Mike Beedle,
Ken Schwaber, Peter Hundermark, Jim Highsmith • Books
− Succeeding with Agile, Agile Estimating Planning, Scrum and XP from the Trenches, Continuous Delivery, Agile Software Development with Scrum, Agile Coaching
• Organizations− Agile Alliance, Scrum Alliance, Scrum.org, PMI
• Websites− (See Organizations), Google, Amazon, Forrester,
AgileJournal, MountainGoatSoftware, AgileManifesto.org, ExtremeProgramming.org, LinkedIn(groups), tech related
57
Sources
• Certified ScrumMaster Training, Conscires Agile Practices
• http://agilemanifesto.org/
• Scrum, Jeff Sutherland/Ken Schwaber, http://www.scrum.org, Feb.
2010
• Do Better Scrum, Peter Hundermark, ScrumSense, Nov. 2009
• The Truth About Agile Process, Carey Schwaber, Forrester, Aug. 2007
• The Forrester Wave: Agile Development Management Tools Q2 2010,
Dave West/Jeffrey Hammond, Forrester, May 2010
• From Agile Development To Agile Engagement, Tom Grant, Forrester,
May 2009
• Agile Development: Mainstream Adoption Has Changed Agility, Dave
West/Tom Grant, Forrester, Jan. 2010
58
Sources
• Agile Estimating and Planning, Mike Cohn, Prentice Hall, Nov. 2005
• Planning and Tracking Agile Projects, Mike Cohn, Mountain Goat
Software, March 2007
• Agile Project Management: Estimating the Unknown, Rick Freedman,
TechRepublic, June 2009
• Agile Success Factors, Jeff Langr/Tim Ottinger,
agileinaflash.blogspot.com, July 2010
• New Patterns of Agile Adoption, Mike Cohn, Agile Journal, Jan. 2008
• Introduction an Agile Process to an Organization, Mike Cohn/Doris
Ford, IEEE, June 2003
• Scaling Up: An Approach to Organizational Agile Adoption, Ross Pettit,
Agile Journal, Nov. 2006
59
Sources
• Key Success Factors in Top-Down Agile Adoption, Ross Pettit, Agile
Journal, March 2007
• The Agile Heartbeat, John Graham-Cumming, Electric Cloud, 2009
• Best Practices for Implementing Agile Methods: A Guide for
Department of Defense Software Developers, Ann Fruhling/Alvin Tarrell,
University of Nebraska at Omaha, 2008
• Selecting an Agile Process: Choosing Among the Leading Alternatives,
Mike Cohn, Mountain Goat Software, Sept. 2004
• An Introduction to Agile Modeling, Scott Ambler, Ambysoft, 2006
• Feature-Driven Development, Peter Coad/Eric Lefebvre/Jeff De Luca,
Java Modeling in Color with UML, Prentice Hall, June 1999
• http://www.microtool.de/instep/en/prod_scrum_edition.asp
60
THANK YOU!