Agile presentation given to IEEE

1. Agile Development:
Product Delivery for Successful Organizations
Marc Crudgington
© Copyright Pacific Technology Consulting Group, LLC

2. Interactive Agenda:
Pick a Topic
Framework vs. Process Agile Types Scrum
Estimating/Planning
Buzzwords
Resources Agile Iterative or
Principles Predictive
Adopting Agile Build Delivery
Impediments
Agile Success
Evolution
Tools
2

3. 3

4. Bio / Info
• 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
4

5. Framework vs. Process
Framework Process
• Set of principles with no parent-
• Prescriptive and linear series of
child relationship which within steps taken to repeatedly
activities are performed. generate the same output.
• Not all components required to • All components used
be used • It is a sequence / same order
• Not always used in the same • Structured
order • PMBOK (Project Management
• Less structured Body of Knowledge), Waterfall
• Agile
5

6. Iterative or Predictive
Predictive
• 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
6

7. Iterative or Predictive
Predictive
• 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?
7

8. Iterative or Predictive
Iterative
• 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
8

9. Iterative or Predictive
Iterative
• Use when
– Project evolves or a little unknown
– Accept change
– Team small; strategies for large/split
– Rapid change can occur
• IMO
– Information Technology
9

10. Iterative or Predictive
Comparison
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

11. Agile Principles
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
11

12. Agile Principles
Principles 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

13. Agile Principles
Principles 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

14. Agile Principles
Authors of the Agile Manifesto
Kent Beck Ron Jeffries
Mike Beedle Jon Kern
Arie van Bennekum Brian Marick
Alistair Cockburn Robert C. Martin
Ward Cunningham Steve Mellor
Martin Fowler Ken Schwaber
James Grenning Jeff Sutherland
Jim Highsmith Dave Thomas
Andrew Hunt
14

15. Adopting Agile
15

16. 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

17. 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

18. 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

19. 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

20. Impediments
Organization Team
• Management control • Agile knowledge
• Department resistance • Work in silos
• Trust in team/process • Individual resistance
• Investment required • Proper tools
• Unrealistic expectations • Documentation requirements
• Customer commitments • Management support
20

21. Agile Types
Agile Survey 2006
21

22. Agile Types
Agile Survey 2009
22

23. Agile Types
Am I Agile?
Adaptive, empowered, self-organizing
Absence of phases
Individuals and
Interactions Use of minimal planning
Scalable
Continuous process refinement
Iterative and incremental
Working
Working software measured in progress
software
Artifacts are minimized
Customer Customer involvement throughout
Collaboration Adaptive, empirical customer relationship
Responding to Emergent requirements
Change Frequent inspection
23

24. Agile Types
FDD (Feature-Driven Development)
• Characteristics
− UML modeling focused, iterative, testing absent, small teams
• Processes
− Develop an overall model
− Build a Features List Done Sequentially
− Plan by Feature
− Design by Feature
Done Iteratively
− 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
24

25. Agile Types
FDD (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

26. Agile Types
Am I Agile?
Adaptive, empowered, self-organizing Not so much
Absence of phases No
Individuals and
Interactions Use of minimal planning No
Scalable Yes
Continuous process refinement Not so much
Iterative and incremental Somewhat
Working
Working software measured in progress No
software
Artifacts are minimized Somewhat
Customer Customer involvement throughout Yes
Collaboration Adaptive, empirical customer relationship Yes
Responding to Emergent requirements No
Change Frequent inspection Yes
26

27. Agile Types
Agile 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

28. Agile Types
Agile Modeling
Best Practices
28

29. Agile Types
Am I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Individuals and
Interactions Use of minimal planning Yes
Scalable Yes
Continuous process refinement Somewhat
Iterative and incremental Somewhat
Working
Working software measured in progress Yes
software
Artifacts are minimized Yes
Customer Customer involvement throughout Yes
Collaboration Adaptive, empirical customer relationship Yes
Responding to Emergent requirements Yes
Change Frequent inspection Yes
29

30. Agile Types
XP (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

31. Agile Types
XP (Extreme Programming)
Workflow
31

32. Agile Types
Am I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Individuals and
Interactions Use of minimal planning Yes
Scalable Yes
Continuous process refinement Mostly
Iterative and incremental Yes
Working
Working software measured in progress Yes
software
Artifacts are minimized Yes
Customer Customer involvement throughout Yes
Collaboration Adaptive, empirical customer relationship Yes
Responding to Emergent requirements Yes
Change Frequent inspection Yes
32

33. Agile Types
Scrum
• 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

34. Agile Types
Am I Agile?
Adaptive, empowered, self-organizing Somewhat
Absence of phases Yes
Individuals and
Interactions Use of minimal planning Yes
Scalable Yes
Continuous process refinement Yes
Iterative and incremental Yes
Working
Working software measured in progress Yes
software
Artifacts are minimized Yes
Customer Customer involvement throughout Yes
Collaboration Adaptive, empirical customer relationship Yes
Responding to Emergent requirements Yes
Change Frequent inspection Yes
34

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. Scrum Overview
Sprint Burndown Chart
41

42. Scrum Overview
Scrum Sprint
42

43. Planning/Estimating
General George S. Patton - "A good plan, violently executed now, is
better than a perfect plan next week.”
The Planning Onion
43

44. Planning/Estimating
Pre-planning points
• Organizations culture
• IT infrastructure investment
• Sponsor / Management commitment
• Project selection
• Agile team selection
• Training needed
• Expert access
• Project only assignment
• Mandatory documentation
44

45. Planning/Estimating
Release Planning
• 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‟
45

46. Planning/Estimating
Iteration Planning
• 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)
46

47. Planning/Estimating
Daily Planning
• Inspect and Adapt meeting
• Accomplishments
• Going to accomplish
• Impediments in the way
• Coordinate individual activities
• Wrap-up
47

48. Planning/Estimating
Estimating
• 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 estimates
2) Product owner reads story, briefly discussed
3) Estimators selects card as estimate
4) All estimators turn cards over
5) 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, ...
48

49. Build Delivery
Coding Practices
• 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
49

50. Build Delivery
Integrate Often
• 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
50

51. 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

52. Tools
52

53. Agile Success
Impact
• 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
53

54. Agile Success
Impact
• 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
54

55. Agile Success
Full Potential
• 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
55

56. Buzzwords
• 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.)
56

57. 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

58. 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

59. 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

60. 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

61. THANK YOU!