A 3-Day Introduction for Sr. Engineers and Tech. Support Staff

A 3-Day Introduction
for Sr. Engineers and
Tech. Support Staff
Dr. David F. Rico, PMP, ACP, CSM
Twitter: @dr_david_f_rico
Website: http://www.davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfrico
Facebook: http://www.facebook.com/profile.php?id=1540017424

Author Background
 DoD contractor with 28+ years of IT experience
 B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys.
 Large gov’t projects in U.S., Far/Mid-East, & Europe

 Published six books & numerous journal articles
 Adjunct at George Washington, UMUC, & Argosy
 Agile Program Management & Lean Development
 Specializes in metrics, models, & cost engineering
 Six Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000
 Cloud Computing, SOA, Web Services, FOSS, etc.
2

Agenda
 Agile Background Agile Teamwork
Agile Introduction Agile Scalability
Agile Business Case Agile Lean/Kanban
Agile Life Cycles Agile Scrum
Agile Practices Agile Metrics & Models
Agile Requirements Agile Costs & Benefits
Agile Project Mgt. Models Agile Earned Value Mgt.
Agile Project Mgt. Phases Agile Documentation
Agile Release Planning Agile Automated Tools
Agile Iteration Planning Agile Contract Models
Agile Estimating Agile Change Models
Agile Risk Analysis Agile Case Studies
Agile Automated Testing Agile Summary
Agile Security Engineering Agile Resources 3

Information Age
 U.S. is no longer an industrial-age nation
 U.S. part of a group of post-industrial countries
 U.S. consists of information-age knowledge workers
100%

80%
Percent of Economy

Information
60%
Service

40% Industry

Agriculture
20%

0%
1860 1870 1880 1890 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990

Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books.

4

System Complexity is Growing
 21st century systems are becoming more complex
 Number of physical parts are becoming smaller
 Nano-circuitry and software hide complexity

Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall.

5

Software Century
 No. of software-intensive systems is growing
 80% of US DoD functions performed in software
 Major driver of cost, schedule, & tech. performance

Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20.

6

Technology Change
 21st century systems are technology-intensive
 Technology is evolving at an exponential speed
 Technology is obsolete before project completion

Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.

7

Large, Traditional Projects
 Big projects result in poor quality and scope changes
 Productivity declines with long queues/wait times
 Long projects are unsuccessful or canceled
Size vs. Quality Size vs. Requirements Growth
16.00 40%
Defect Density

12.80 32%

Percentage
9.60 24%

6.40 16%

3.20 8%

0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)

Size vs. Productivity Size vs. Success
5.00 60%
Code Production Rate

4.00 48%
Percentage

3.00 36%

2.00 24%

1.00 12%

0.00 0%
0 2 6 25 100 400 0 2 6 25 100 400
Lines of Code (Thousands) Lines of Code (Thousands)

Jones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill.
8

Global Project Failures
 Challenged and failed projects hover at 67%
 Big projects fail more often, which is 5% to 10%
 Of $1.7T spent on IT projects, over $858B were lost
$1.8
2010 33% 41% 26%

2008 32% 44% 24%
$1.4

Trillions (US Dollars)
2006 35% 46% 19%

2004 29% 53% 18% $1.1
Year

2002 34% 51% 15%

2000 28% 49% 23% $0.7

1998 26% 46% 28%
$0.4
1996 27% 33% 40%

1994 16% 53% 31%
$0.0
0% 20% 40% 60% 80% 100% 2002 2003 2004 2005 2006 2007 2008 2009 2010

Successful Challenged Failed Expenditures Failed Investments

Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.
Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.
9

Requirements Defects & Waste
 Requirements defects are #1 reason projects fail
 Traditional projects specify too many requirements
 More than 65% of requirements are never used at all
Defects Waste
Never
Requirements
45%
47%
Other 7% Always 7%

Implementation
Often 13%
18% Rarely
Design 19%
28% Sometimes
16%

Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20
Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy.
10

Agenda
Agile Background Agile Teamwork
 Agile Introduction Agile Scalability

Today’s Whirlwind Environment

Global
Competition
Work Life
Imbalance
Demanding
Customers
 Overruns
Vague  Attrition
Requirements  Escalation
 Runaways
 Cancellation
Organization
Downsizing
Technology
Change
System
Complexity

12

Need for a New Model
 Need for a new model of system development
 Cope with high-level of uncertainty and ambiguity
 With just the right balance of flexibility and discipline
R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined

 New discoveries  Highly-talented people  Global threats  Customer interaction  New technology  Lightweight strategy

 Complex problems  Cross-functional teams  Market threats  A lot of communication  Quick decision-making  Lightweight plans
 One-off systems  Small team size  New customer needs  Customer demos  Iterative delivery cycles  Lightweight lifecycles
 Vague requirements  A lot of communication  Changing scope  Customer feedback  Frequent deliveries  Security engineering
 Incomplete information  Interpersonal trust  Changing technology  Business value focus  Fast delivery schedules  Light requirements

 High uncertainty  Rich collaboration  Changing regulations  Customer satisfaction  Short timelines  Light architecture
 Experimentation  Empowered decisions  Continuous change  Customer responsive  Fast time-to-market  Lightweight design
 Simulations  Sustainable pace  Flexible culture  Customer sensitivity  First-mover capability  Code reviews
 Prototyping  Daily interaction  Flexible attitudes  Customer relationships  Minimal process costs  Rigorous V&V

 Innovation oriented  Rich communications  Flexible policies  Customer contact  Low work-in-process
-  Rigorous CM
 New products  Face-to-face interaction  Flexible processes  Customer involvement  Flexible processes  Rigorous QA
 Creative solutions  Cohesiveness  Flexible technologies  Customer driven  Market responsiveness  Project reviews

Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
Chin, G. (2004). Agile project management: How to succeed in the face of changing project requirements. Broadway, NY: Amacom.
DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
13

What is Agility?
 A-gil-i-ty (ə-'ji-lə-tē) Property consisting of quickness,
lightness, and ease of movement; To be very nimble
 The ability to create and respond to change in order to
profit in a turbulent global business environment
 The ability to quickly reprioritize use of resources when
requirements, technology, and knowledge shift
 A very fast response to sudden market changes and
emerging threats by intensive customer interaction
 Use of evolutionary, incremental, and iterative
delivery to converge on an optimal customer solution

  Maximizing the BUSINESS VALUE with right-sized, just-
enough, and just-in-time processes and documentation 
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.

14

What are Agile Methods?
 People-centric way to create innovative solutions
 Market-centric model to maximize business value
 Product-centric vs. wasteful processes/documents
Agile Methods Agile Methods Traditional Methods
‘Values’ ‘Principles’ ‘Values’
Customer also Customer valued Contract
known as more than
Collaboration Interaction Negotiation

Individuals & also High Performance valued Processes
known as more than
Interactions Teams & Tools

Working also Iterative valued Comprehensive
known as more than
Systems Development Documentation

Responding also Adaptability valued Following
to Change known as more than a Plan
or Flexibility

Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org.

15

How do Lean/Agile Intersect?
 Agile is naturally lean and based on small batches
 Agile directly supports six principles of lean thinking
 Agile may be converted to a continuous flow system
Agile Values Lean Pillars Lean Principles Lean & Agile Practices Flow Principles
 Customer relationships, satisfaction, trust, and loyalty
Empowered Relationships  Team authority, empowerment, and resources Decentralization
Teams  Team identification, cohesion, and communication
 Product vision, mission, needs, and capabilities
Respect
Customer Value  Product scope, constraints, and business value Economic View
for People  Product objectives, specifications, and performance
Customer
 As is policies, processes, procedures, and instructions
Collaboration  To be business processes, flowcharts, and swim lanes
WIP Constraints
Value Stream
 Initial workflow analysis, metrication, and optimization & Kanban
 Batch size, work in process, and artifact size constraints
Control Cadence
Iterative Continuous Flow  Cadence, queue size, buffers, slack, and bottlenecks
Delivery  Workflow, test, integration, and deployment automation & Small Batches
 Roadmaps, releases, iterations, and product priorities
Continuous  Epics, themes, feature sets, features, and user stories
Customer Pull Fast Feedback
Improvement  Product demonstrations, feedback, and new backlogs
Responding
 Refactor, test driven design, and continuous integration
to Change  Standups, retrospectives, and process improvements
Manage Queues/
Perfection
 Organization, project, and process adaptability/flexibility Exploit Variability

  
Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. New York, NY: Free Press.
Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. New York, NY: Celeritas.
Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. DoD AT&L Magazine, 39(6). 16

When to Use Agile Methods?
 On exploratory or research/development projects
 When fast customer responsiveness is paramount
 In organizations that are highly-innovative & creative
Traditional Project Management Agile Project Management
 Predictable situations  High-levels of uncertainty and unpredictability
 Low-technology projects  High-technology projects
 Stable, slow-moving industries  Fast-paced, highly-competitive industries
 Low-levels of technological change  Rapid pace of technological change
 Repeatable operations  Research-oriented, discovery projects
 Low-rates of changing project performance  Large-fluctuations in project performance
 Long-term, fixed-price production contracts  Shorter-term, performance-based RDT&E contracts
 Achieving concise economic efficiency goals  Achieving high-impact product/service effectiveness
 Highly-administrative contracts  Highly-creative new product development contracts
 Mass production and high-volume manufacturing  Customer-intensive, one-off product/service solutions
 Highly-predictable and stable market conditions  Highly-volatile and unstable market conditions
 Low-margin industries such as commodities  High-margin, intellectually-intensive industries
 Delivering value at the point-of-plan  Delivering value at the point-of-sale

Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.

17

Agile World View
 Agility has many dimensions other than IT
 Ranges from leadership to technological agility
 The focus of this brief is systems development agility
Agile Leaders
Agile Organization Change
Agile Acquisition & Contracting
Agile Strategic Planning
Agile Capability Analysis

 Agile Program Management
Agile Project Management

Agile Systems Development
Agile Processes & Practices
Agile Tools
Agile Information Systems
Agile Tech.
18

Agenda
 Agile Business Case Agile Lean/Kanban

Agile Adoption Rates
 VersionOne found 80% using agile methods today
 Most are using Scrum with several key XP practices
 Release planning/continuous integration are vital tools

House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne.

20

Surveys of Agile Methods
 Many surveys of agile methods since 2003
 AmbySoft and VersionOne collect annual data
 Agile benefits are above 50% in most categories

Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdf.

21

Case Studies of Agile Methods
 Agile (138 pt.) and traditional methods (99 pt.)
 Agile methods fare better in all benefits categories
 Agile methods 359% better than traditional methods
Category Agile Traditional Difference
Cost Reduction 9%
Schedule Reduction 33%
Productivity Improvement 55%
Quality Improvement 24%
Customer Satisfaction Imp. 56%
Return on Investment 2,811% 470% 2,341%

Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.

22

Benefits of Agile Methods
 Analysis of 23 agile vs. 7,500 traditional projects
 Agile projects are 54% better than traditional ones
 Agile has lower costs (61%) and fewer defects (93%)
2.8 18
Before Agile Before Agile
3.00 20
After Agile After Agile
2.25 15 11
1.1
1.50 10

61% 39%
0.75 5
Lower Less
Cost Staff
Project Cost in Millions $ Total Staffing

18 2270
Before Agile Before Agile
20 2500
13.5 After Agile After Agile
15 1875

10 1250
381
93%
5 24% 625 Less
Faster
Defects
Delivery Time in Months Cumulative Defects

Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.

23

Benefits of Organizational Agility
 Study of 15 agile vs. non-agile Fortune 500 firms
 Based on models to measure organizational agility
 Agile firms out perform non-agile firms by up to 36%

Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence
in innovation and adaptability and its effect on financial performance. Stamford, CT: BTM Institute.
24

Agenda
 Agile Life Cycles Agile Scrum

Crystal Methods
 Created by Alistair Cockburn in 1991
 Has 14 practices, 10 roles, and 25 products
 Scalable family of techniques for critical systems

Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley.

26

Scrum
 Created by Jeff Sutherland at Easel in 1993
 Has 5 practices, 3 roles, 5 products, rules, etc.
 Uses EVM to burn down backlog in 30-day iterations

Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.

27

Dynamic Systems Dev.
 Created by group of British firms in 1993
 15 practices, 12 roles, and 23 work products
 Non-proprietary RAD approach from early 1990s

Stapleton, J. (1997). DSDM: A framework for business centered development. Harlow, England: Addison-Wesley.

28

Feature Driven Development
 Created by Jeff De Luca at Nebulon in 1997
 Has 8 practices, 14 roles, and 16 work products
 Uses object-oriented design and code inspections

Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice-Hall.

29

Extreme Programming
 Created by Kent Beck at Chrysler in 1998
 Has 28 practices, 7 roles, and 7 work products
 Popularized pair programming and test-driven dev.

Test
User Scenarios
Stories

New
Requirements Bugs
Stories

System Release Latest Customer
Architectural Metaphor Release Plan Version Acceptance Approval Small
Iteration
Spike Planning Tests Releases

Uncertain Confident
Estimates Estimates Next
Iteration

Spike

Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA: Addison-Wesley.

30

Kanban
 Adapted to IT by Dave Anderson in 2006
 Activities, buffers, queues, WIP limits, tasks, etc.
 Lean, JIT pull/demand system leading to high quality

Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.

31

Agenda
 Agile Practices Agile Metrics & Models

Onsite Customers
 Term coined by Kent Beck in 1999
 Customer who sits with developers full-time
 Fast and efficient way to capture customer needs

Tabaka, J. (2006). Collaboration explained: Facilitation skills for software project leaders. Upper Saddle River, NJ: Addison Wesley.

33

Release Planning
 Project plan with a 30-60-90-day timing horizon
 Disciplined and adaptable project management F/W

Beck, K., & Fowler, M. (2004). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.

34

User Stories
 Functions or features of value to customers
 Highly-adaptable requirements engineering process

Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.

35

Test-Driven Development
 Consists of writing all tests before design
 Ensures all components are verified and validated

Beck, K. (2003). Test-driven development: By example. Boston, MA: Addison-Wesley.

36

Pair Programming
 Term coined by Jim Coplien in 1995
 Consists of two side-by-side developers
 Highly-effective group problem-solving technique

Williams, L., & Kessler, R. (2002). Pair programming illuminated. Boston, MA: Pearson Education.

37

Refactoring
 Term coined by William Opdyke in 1990
 Process of frequently redesigning the system
 Improves readability, maintainability, and quality

Fowler, M. (1999). Refactoring: Improving the design of existing code. Boston, MA. Addison-Wesley.

38

Continuous Integration
 Term coined by Martin Fowler in 1998
 Process of automated build/regression testing
 Evaluates impact of changes against entire system

Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

39

Agenda
 Agile Requirements Agile Costs & Benefits

User Story
 Requirement written from perspective of a user
 Function or a feature that has value to a customer
 Discrete unit of functionality written on an index card


41

Conditions of Satisfaction
 Conditions of satisfaction added to user stories
 Serve as a set of user acceptance test criteria
 Used for development and operational tests


42

Detailed Sub-Stories
 Details can be added in smaller sub-stories
 Good way to functionally-decompose user stories
 May also represent an object-oriented point-of-view


43

Epics
 Epics are very large enterprise requirements
 They are often called capabilities or feature sets
 A very-large unit of work that must be decomposed


44

User Story Workshops
 Form stakeholder groups to brainstorm user stories
 Goal is to write as many user stories as possible
 Start with epics and decompose user stories


45

Agenda
 Agile Project Mgt. Models Agile Earned Value Mgt.
Agile Autoamted Testing Agile Summary

Scrum Project Management
 Product backlog comprised of customer needs
 Barely-sufficient project management framework
Initial Planning Sprint Cycle

Discovery Session Sprint

 Agile Training  Select Tasks and Create Tests
 Project Discovery  Create Simple Designs
 Code and Test Software Units
 Process Discovery
 Perform Integration Testing
 Team Discovery
 Maintain Daily Burndown Chart
 Initial Backlog  Update Sprint Backlog

Release Planning Sprint Planning Daily Scrum Sprint Review

 Business Case  Set Sprint Capacity  Completed Backlog Items  Present Backlog Items
 Desired Backlog  Identify Tasks  Planned Backlog Items  Record Feedback
 Estimate Tasks  Impediments to Progress  Adjust Backlog
 Hi-Level Estimates
 Prioritize Backlog
 Finalize Backlog
Sprint Retrospective

Product Backlog Sprint Backlog Potentially Shippable Product

 Prioritized Requirements  List of Technical Tasks Assigned to a Sprint  Working Operational Software

Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.

47

XP Project Management
 Release plan is comprised of customer needs
 Lightweight, rigorous near-term planning element
Release Planning Iteration Planning

Exploration Phase Exploration Phase

 Build a Team  Split User Stories  Analyze Release Plan  Read User Stories
 Write User Stories  Spike User Stories  Identify Iteration Goal  Develop Tasks
 Estimate User Stories  Write User Tests  Select User Stories  Split Tasks

Commitment Phase Commitment Phase

 Sort by Value  Choose a Scope  Accept Tasks  Analyze Schedules
 Sort by Risk  Set Iteration Length  Set Individual Velocity  Set Load Factors
 Set Velocity  Develop Release Plan  Estimate Tasks  Balance Tasks

Steering Phase Steering Phase

 Select Iteration  New Release Plan  Select Partner  Unit/Integration Test
 Adjust Velocity  Select Tools  Write Unit Tests  User Acceptance Test
 Insert New Stories  Adjust Teams  Design and Code  Record Progress


48

Project Leadership Model
 Created by Sanjiv Augustine at CC Pace in 2005
 Builds agile cultures, mind-sets, and environments
 Leadership model for managing agile project teams
Foster Alignment and Cooperation Encourage Emergence and Self Organization Learning/Adaptation

Organic Teams Guiding Vision Simple Rules Open Information Light Touch Adaptive Leadership

Leadership Leadership Leadership Leadership Leadership Leadership

 Craftsmanship  Team Vision  Culture of Change  Conduct Standups  Adapt Style  Embodied Presence
 Collaboration  Team Alignment  Value Focus  Promote Feedback  Roving Leadership  Embodied Learning
 Guiding Coalition  Bold Future  Build Trust  Go With Flow
 Community  Shared Expectations  Facilitate Action  Work Life Quality
 Build on Strengths
 Gain Commitments

Management Management Management Management Management Management

 Identify Community  Business Outcomes  Assess Status Quo  Team Collocation  Decentralize Control  Daily Feedback
 Design Structures  Delineate Scope  Customize Method  Get Onsite Customer  Pull vs. Push  Monitor/Adapt Rules
 Get Team Players  Estimate Effort  Release Plan  Practice Pairing  Manage Flow  Monitor Practices
 Adaptive Enterprise  Design Vision Box  Iteration Plans  Information Radiator  Use Action Sprints  Retrospectives
 Elevator Statement  Facilitate Design  Map Value Stream  Scenario Planning
 Conduct Testing
 Manage Releases

Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.

49

Flexible Project Management
 Created by Doug DeCarlo at Cutter in 2004
 Focus is on collaboration, scoping, and speed
 Thinner traditional project management approach
Visionate Speculate Innovate Re-evaluate Disseminate

Sponsor’s Vision Planning Meeting Learning by Doing Business Questions Product Launch

 Interview Sponsor  Collective Vision  SCORE Model  Who Needs It?  Acceptance Testing
 Describe Objectives  Size Deliverables  Architecture  What Will It Take?  Documentation
 Project Prospectus  Map Schedule  Development  Can We Get It?  Support Plan
 Business Questions  Choose Life Cycle  Construction  Is It Worth It?  Maintenance Plan
 Requirements ID’d  Testing  Deploy Solution
 Development Tools  Time Boxing  Customer Service
Collective Vision Project Review
 Risk Planning  Trial and Error
 Scope Meeting  Check Performance
 Collaboration
 Future Scenarios  Check Schedule Stabilization
Post Meeting
 Project Skinny  Check Costs  Training/Education
 Project Boundaries  PM Infrastructure Generate Results  Check Benefits  Utilization
 Project Vision  Financial Goals  Visibility  Check Project ROI  Performance
 Win Conditions  Benefit Plan  Early Value  Go/No-Go Decision  Feedback
 Benefit Map  Partner Agreements  Fast Failures  Corrective Action
 Wow Factor
Project Changes
 Uncertainty Profile Business Questions Business Questions Lessons Learned
 Re-Direct As-Needed
 Go/No-Go Decision  Modify Questions  Update Vision
Collective Vision Team Rewards
 Update Stakeholders
Select Core Team Update Prospectus Update Prospectus  Re-examine Team Track Benefits

DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass.

50

Adaptive Project Management
 Created by Bob Wysocki for consulting in 2008
 Designed to be a generic model for non-IT projects
 Lightweight traditional project management approach
Adaptive Project Framework

Scoping Planning Feasibility Checkpoint Review

 Identify Opportunity  Identify Project Type  Develop Prototype  Analyze Needs  Finalize Documents
 Develop CoS  Prioritize Constraints  Reprioritize Needs  Evaluation Solution  Lessons Learned
 Write PoS  Develop WBS  Detailed WBS  Estimate Value  Process Changes
 Document Needs  Team Formation  Estimate Resources  Determine Success  Final Report
 Stage Gate 1 Review  Stage Gate 2 Review  Stage Gate 3 Review  Stage Gate 4 Review  Stage Gate 5 Review

Cyclical Product or Service Implementation

Cycle Planning Product or Service Implementation Daily Meetings Cycle Reviews

 Responsibilities  Select Personnel with Needed Skills  Arrange Facilities  Update Requirements
 Timelines  Identify Detailed Technical Tasks  Prepare Agendas  Update Scope
 Work Packages  Create Detailed Architectures and Designs  Send Meeting Notices  Update Schedules
 Communications  Select and Implement Technical Solutions  Facilitate Meetings  Update Plans
 Governance  Perform Development and Operational Tests  Record Action Items  Inform Stakeholders

Continuous Improvement
Stage Gate 3.n
 Continually improve process, documents, team, architecture, designs, implementation, tests, etc. Review

Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.

51

 Created by Jim Highsmith at Cutter in 2003
 Focus on strategic plans and capability analysis
 Most holistic agile project management framework
Innovation Lifecycle

Envision Speculate Explore Launch Close

 Product Vision  Gather Requirements  Iteration Management  Final Review  Clean Up Open Items
 Product Architecture  Product Backlog  Technical Practices  Final Acceptance  Support Material
 Project Objectives  Release Planning  Team Development  Final QA  Final Retrospective
 Project Community  Risk Planning  Team Decisions  Final Documentation  Final Reports
 Delivery Approach  Cost Estimation  Collaboration  Final Deployment  Project Celebration

Iterative Delivery

Technical Planning Development, Test, & Evaluation Operational Testing Adapt

 Story Analysis  Development Pairing  Integration Testing  Focus Groups
 Task Development  Unit Test Development  System Testing  Technical Reviews
 Task Estimation  Simple Designs  Operational Testing  Team Evaluations
 Task Splitting  Coding and Refactoring  Usability Testing  Project Reporting
 Task Planning  Unit and Component Testing  Acceptance Testing  Adaptive Action

Continuous
Story Deployment
 Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration


52

Agenda
 Agile Project Mgt. Phases Agile Documentation

Envision Phase
 Determine product vision and project objectives
 Identifies project community and project team
 The major output is a “Product Vision Box”
Envision Phase

Product Vision

 Product Vision Box
 Elevator Test Statement
 Product Roadmap
 Product Features
Delivery Approach  Product Vision Document Product Architecture

 Self-Organization Strategy  Skeleton Architecture
 Collaboration Strategy  Hardware Feature Breakdown
 Communication Strategy  Software Feature Breakdown
 Process Framework Tailoring  Organizational Structure
 Practice Selection & Tailoring  Guiding Principles

Project Community Project Objectives

 Get the Right People  Project Data Sheet
 Participant Identification  Key Business Objectives
 Types of Stakeholders  Tradeoff Matrix
 List of Stakeholders  Exploration Factor
 Customer-Developer Interaction  Requirements Variability


54

Speculate Phase
 Determine organizational capability/mission needs
 Identifies feature-sets and system requirements
 The major output is a “System Release Plan”
Speculate Phase

Gather Requirements

 Analyze Feasibility Studies
 Evaluate Marketing Reports
 Gather Stakeholder Suggestions
 Examine Competitive Intelligence
Cost Estimation  Collaborate with Customers Product Backlog

 Establish Estimate Scope  Product Features List
 Establish Technical Baseline  Feature Cards
 Collect Project Data  Performance Requirements
 Size Project Information  Prioritize Features
 Prepare Baseline Estimates  Feature Breakdown Structure

Risk Planning Release Planning

 Risk Identification  Project Startup Activities
 Risk Analysis  Assign Stories to Iterations
 Risk Responses  First Feasible Deployment
 Risk Monitoring  Estimate Feature Velocity
 Risk Control  Determine Product Scope


55

Explore Phase
 Determine technical iteration objectives/approaches
 Identifies technical tasks and technical practices
 The major output is an “Operational Element”
Explore Phase

Iteration Management

 Iteration Planning
 Estimate Task Size
 Iteration Length
 Workload Management
Collaboration  Monitoring Iteration Progress Technical Practices

 Pair Programming  Reduce Technical Debt
 Daily Standup Meetings  Simple Design
 Daily Product Team Interaction  Continuous Integration
 Stakeholder Coordination  Ruthless Automated Testing
 Customer Interactions  Opportunistic Refactoring

Team Decisions Team Development

 Decision Framing  Focus Team
 Decision Making  Molding Group into Team
 Decision Retrospection  Develop Individual Capabilities
 Leadership and Decision Making  Coach Customers
 Set and Delay Decision Making  Orchestrate Team Rhythm


56

Launch Phase
 Determine the state of the final deployment system
 Perform final development, test, and QA reviews
 The major output is a “Deployment Package”
Launch Phase

Final Review

 Final Release Plan Review
 Final Requirements Review
 Final Design Review
 Final Code Review
Final Deployment  Final Development Team Review Final Acceptance

 Final Source Code  Final Test Plan Review
 Final Build  Final Test Case Review
 Final Integration  Final Test Environment Review
 Final Image  Final Acceptance Test Review
 Final Deployment Package  Final Test Results Review

Final Documentation Final Quality Assurance

 Final Release Plans  Final Functional Configuration Audit
 Final Requirements Database  Final Physical Configuration Audit
 Final Development Documents  Final Quality Assurance Plan Review
 Final Maintenance Documents  Final QA Procedures Review
 Final Operations Documents  Final Quality Assurance Review


57

Close Phase
 Determine project outcome and effectiveness
 Identifies strengths, weaknesses, and rewards
 The major output is a “Lessons-Learned Report”
Close Phase

Clean Up Open Items

 Close Open Action Items
 Close Open Change Requests
 Close Open Problem Reports
 Close Open Defect Reports
Project Celebration  Close Open Project Issues Support Material

 Individual Rewards  Finalize Documentation
 Group Rewards  Finalize Production Material
 Partner Rewards  Finalize Manufacturing Material
 Managerial Rewards  Finalize Customer Documentation
 Product Rewards  Finalize Maintenance Information

Final Reports Final Retrospective

 End-of-Project Reports  Process Performance Assessment
 Administrative Reports  Internal Product Assessment
 Release Notes  External Product Assessment
 Financial Reports  Team Performance Assessment
 Facilities Reports  Project Performance Assessment


58

Leadership Considerations
 Agile management is delegated to the lowest level
 There remain key leadership roles & responsibilities
 Communication, coaching, & facilitation are key ones
Facilitate selection of methods for obtaining and maintaining executive commitment, project
Customer Communication resources, corporate communications, and customer interaction
 Product Visioning
Facilitate selection of methods for communicating product purpose, goals, objectives, mission,
vision, business value, scope, performance, budget, assumptions, constraints, etc.

Distribution Strategy Facilitate selection of virtual team distribution strategy to satisfy project goals and objectives

Facilitate selection of methods for training, coaching, mentoring, and other team building
Team Development approaches
 Standards & Practices
Facilitate selection of project management and technical practices, conventions, roles,
responsibilities, and performance measures

Telecom Infrastructure Facilitate selection of high bandwidth telecommunication products and services

Development Tools Facilitate selection of agile project management tools and interactive development environment

High Context Meetings Facilitate selection of high context agile project management and development meetings
 Coordination Meetings
Facilitate selection of meetings and forums for regular communications between site
coordinators
Facilitate selection of methods for maximizing periodic face to face interactions and
F2F Communications collaboration
Facilities selection of methods for process improvement, problem resolution, conflict
Performance Management management, team recognition, product performance, and customer satisfaction

Rico, D. F. (2010). The paradox of agile project management and virtual teams. Fairfax, VA: Gantthead.Com.

59

Agenda
 Agile Release Planning Agile Automated Tools

Release Planning
 Release planning is basic agile planning approach
 Begins with capturing and ordering customer needs
 Output is a release plan with resources and timelines
Write User Stories Estimate User Stories Prioritize User Stories Split User Stories Develop Release Plan

• Hold customer • Estimate size • Estimate total • Evaluate story • Select release
meeting using Delphi resources size scope
(PERT)
• Propose user • Estimate • Evaluate • Select iteration
stories • Estimate using business value needed velocity &
planning poker resources length
• Clarify user • Estimate
stories • Estimate using technical risks • Evaluate • Estimate
analogy business value release budget
• Record user • Sequence user
stories • Estimate user stories • Evaluate risks • Identify overall
algorithmic and sequence constraints
• Verify user • Verify overall
models
stories sequence • Divide and • Develop
• Estimate using reorder user release plan
prototypes stories
(spikes)

Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education.
61

Write User Stories
 Release planning begins by identifying user needs
 User needs are captured in form of user stories
 Customer records needs on user story cards
Write User Stories

Hold
Customer
Meeting
Verify Propose
User User
Stories Stories

Record Clarify
User User
Stories Stories

62

Estimate User Stories
 The complexity of each user story is then estimated
 Complexity is captured in the form of story points
 Story points are a relative size of user needs
Estimate User Stories

Estimate
Using
Delphi (PERT)
Estimate Estimate
Using Using
Prototypes (Spikes) Planning Poker

Estimate Estimate
Using Using
Algorithmic Models Analogy

63

Prioritize User Stories
 Customers must prioritize all of their user stories
 Cost, value, risk, and other factors are considered
 Tradeoffs are made when rank ordering user stories
Prioritize User Stories

Estimate
Total
Resources
Verify Estimate
Overall Business
Sequence Value

Sequence Estimate
User Technical
Stories Risks

64

Split User Stories
 Stories may be decomposed for a variety of reasons
 Oftentimes, user stories are too big and complex
 Customers are responsible for splitting them
Split User Stories

Evaluate
User Story
Size
Divide Evaluate
and Reorder Needed
User Stories Resources

Evaluate Evaluate
Risks and Business
Sequence Value

65

Develop Release Plan
 Customers identify which user stories they want
 Developers estimate iteration length, budget, etc.
 A release plan is designed covering 9 to 18 months
Develop Release Plan

Select
Release
Scope
Develop Select
Release Iteration
Plan Velocity & Length

Identify Estimate
Overall Release
Constraints Budget

66

Agenda
 Agile Iteration Planning Agile Contract Models

Write Technical Tasks
 Customer and developers review user stories
 Developers divide user stories into technical tasks
 Detailed technical activity is recorded on task cards
Write Technical Tasks

Hold
Customer
Meeting
Develop Review
Acceptance User
Criteria Stories

Write Identify
Task Technical
Descriptions Tasks

68

Assign Technical Tasks
 Complete task list is reviewed by developers
 Technical requirements are aligned by skill sets
 Technical tasks are assigned to programmer pairs
Assign Technical Tasks

Evaluate
Initial
Tasks
Assign Identify
Tasks Technical
to Pairs Requirements

Organize Align with
Into Skills and
Pairs Interests

69

Estimate Technical Tasks
 Technical tasks are analyzed by pair groupings
 Effort is estimated by analogy, Delphi method, etc.
 Unit test cases are developed and tasks are verified
Estimate Technical Tasks

Analyze
Assigned
Tasks
Verify Estimate
Technical by Analogy,
Tasks Delphi, Tool, etc.

Develop Determine
Unit Level Effort in
Test Cases Ideal Days

70

Decompose Technical Tasks
 Overall technical task sizes are evaluated
 Larger tasks are decomposed into smaller ones
 New technical tasks are developed and propagated
Decompose Technical Tasks

Analyze
Technical
Task Sizes
Assign New Decompose
Technical Tasks Large
to Pairs Technical Tasks

Write New Identify
Technical Task New
Descriptions Technical Tasks

71

Develop Iteration Plans
 Establish individual productivity time and pace
 Balance the workload among individual resources
 Develop iteration plans with tasks, dates, pairs, etc.
Develop Iteration Plans

Establish
Personnel
Load Factors
Establish Balance
Iteration Personnel
Plan Resources

Compile Establish
Technical Task Technical Task
Assignments Traceability

72

Release/Iteration Plan
 An example of release and iteration plan
 Relationships between user stories and plans
 Shows key data such as story points and velocity
Product Backlog, Release Plan, & Iteration Plan

Product Backlog Release Plan Iteration Plan
User Story Points Release Iteration Task Team Plan Actual

 Find a flight 1  Release 1 Iteration 1  Specify airport Bob/Sue 2 hours 1 hours
 Specify dates 2 hours 1 hours
 Specify times 2 hours 1 hours
 Reserve a flight 2 Iteration 2  Enter name John/Dave 4 hours 3 hours
 Enter address 4 hours 3 hours
 Get confirmation no 4 hours 3 hours
 Book a flight 4 Iteration 3  Enter credit card Barb/Carol 8 hours 6 hours
 Enter billing info 8 hours 6 hours
 Get receipt 8 hours 6 hours
 Verify a flight 1  Release 2 Iteration 4  Enter confirmation no Matt/Ken 2 hours 2 hours
 View itinerary 2 hours 2 hours
 View payment info 2 hours 2 hours
 Generate itinerary 2 Iteration 5  Enter confirmation no Jim/Jane 4 hours 3 hours
 Print itinerary 4 hours 3 hours
 Download itinerary 4 hours 3 hours
 Check flight status 4 Iteration 6  Enter confirmation no Nat/Tim 8 hours 6 hours
 View flight status 8 hours 6 hours
 View gate info 8 hours 6 hours
 Change flight 4  Release 3 Iteration 7  Enter confirmation no Kim/Pat 8 hours 6 hours
 Change dates 8 hours 6 hours
 Change times 8 hours 6 hours
 Cancel flight 1 Iteration 8  Enter confirmation no Sam/Ron 2 hours 2 hours
 Cancel flight 2 hours 2 hours
 Verify cancellation 2 hours 2 hours
 Get a refund 2 Iteration 9  Enter confirmation no Mark/Dan 4 hours 4 hours
 Initiate refund 4 hours 4 hours
 Verify refund status 4 hours 4 hours

73

Agenda
 Agile Estimating Agile Change Models

Wideband Delphi (PERT)
 Created by RAND corporation in 1940s
 Applied to software effort estimation in 1970s
 Relies on expert judgment and consensus (PERT)
Estimate Using Wideband Delphi (PERT)

Hold
Meeting with
Customers
Discuss Review
and Verify Each
Estimates User Story

Use PERT Solicit
to Combine Individual
Estimates Estimates

Graefe, A., & Armstrong, J. S. (2011). Comparing face-to-face meetings, nominal groups, delphi, and prediction markets on an estimation task.
International Journal of Forecasting, 27(1), 183-195.
75

Planning Poker
 Created by James Grenning for Scrum in 2002
 Similar to Wideband Delphi (or PERT) estimating
 Goal is to estimate size (complexity) in story points
Estimate Using Planning Poker

Hold
Meeting with
Customers
Discuss Distribute
and Verify Planning
Estimates Poker Cards

Vote on Review
Size in Each
Story Points User Story

Molokken-Ostvold, K., & Haugen, N. C. (2007). Combining estimates with planning poker: An empirical study. Proceedings of the 18th Australian
Software Engineering Conference (ASWEC 2007), Melbourne, Australia, 349-358.
76

Analogous Estimating
 Utilized for software estimating in the 1970s
 Goal is to match new user stories with prior ones
 Generates estimate based on similar historical work
Estimate by Analogy

Hold
Meeting with
Customers
Agree on Review
Size of New Each
User Stories User Story

Match Analyze
Old and New Previous
User Stories User Stories

Wen, J., Li, S., & Tang, L. (2009). Improve analogy-based software estimation using principal components analysis and correlation weighting.
Proceedings of the 16th Asia-Pacific Software Engineering Conference (APSEC'2009), Penang, Malaysia, 179-186..
77

Algorithmic Models
 First regression models popularized in 1970s
 Grew into complex logarithmic models in 1990s
 Many algorithms and tools exist for agile estimates
Estimate Using Algorithmic Models

Hold
Meeting with
Customers
Average Review
Output of Each
Algorithmic Models User Story

Generate Select
One or More One or More
Estimates Algorithmic Models

Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, test-driven development,
pair programming, and scrum (using real options). TickIT International, 10(4), 9-18..
78

Prototypes (Spikes)
 Prototyping applied to software in the 1970s
 Used for estimation by JAD and Spiral in 1980s
 Agile teams create rapid “Spikes” to size user stories
Estimate Using Prototypes (Spikes)

Hold
Meeting with
Customers
Estimate Review
User Story Each
from New Data User Story

Develop Identify
Rapid Problematic
Prototype (Spike) User Stories

Keaveney, S., & Conboy, K. (2006). Cost estimation in agile development projects. Proceedings of the
European Conference on Information Systems (ECIS 2006), Goteborg, Sweden.
79

Agenda
 Agile Risk Analysis Agile Case Studies

Risk Planning
 Kickoff meeting is held during release planning
 Type of project and risks of initial stories identified
 Risk management process is aligned with challenges
Risk Planning

Hold
Customer
Meeting
Identify
Review and Approve
Risk Processes
Risk Plan
or Stages

Identify Identify
Risk Evaluation Risk Tracking
Criteria Artifacts

Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011
from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes.
81

Risk Identification
 Low level risks identified at each stage
 Risks are attached to stories, tasks, tests, etc.
 Many risks identified during standups/retrospectives
Risk Identification

Identify
Risks During
Release Planning
Identify Identify
Risks During Risks During
Retrospectives Sprint Planning

Identify Identify Risks
Risks During During Daily
Sprint Reviews Standups

82

Risk Assessment
 Risk backlog is periodically reviewed
 Risks are categorized along with likelihood
 Risk impact is estimated and risk data is verified
Risk Assessment

Review
Risk
Backlog
Verify Categorize
Risk or Determine
Assessment Data Type of Risk

Identify Determine
Impact of Risk Probability
Potential Risk or Likelihood

83

Risk Response
 Risks are reviewed along with response types
 Appropriate responses are selected and assigned
 Contingency plans are developed if risks are realized
Risk Response

Review
Risk
Assessment Data
Verify Review
Risk Risk Response
Response Data Categories

Define Select a
Contingency Risk Response
Plans and Actions Category

84

Risk Review
 Risk meetings are held with customers
 High priority risks are evaluated from backlog
 Risks are mitigated and reprioritized as necessary
Risk Review

Review
Risk
Backlog
Re-categorize Evaluate
& Reprioritize High-Priority
Risk Backlog Risks

Activate Determine if
Risk Responses Risks Have
if Necessary Been Realized

85

Agenda
 Agile Automated Testing Agile Summary

What is Agile Testing?
 Traditional testing is a late, manual process
 Agile testing is an early and automated process
 The goal of agile testing is to deliver early and often
Traditional Testing Agile Testing

Combining source files Code is frequently checked in
Combining software and environment Code is automatically retrieved
Combining software and data Compilation is done automatically
Combining software and tests Tests are done automatically
Combining developers Code reports are generated
Developers get instant feedback
Code is automatically deployed or
packaged for delivery

Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.

87

Agile Automated Testing
 Developers check-in changes as they occur
 Server detects all changes and initiates testing
 Server compiles, tests, analyzes, builds, and deploys

Build
Status
Compile Source
Code
Commits Run Unit Tests
Changes Provides
Developer A
Run Coverage
Tests
Commits Watches Uses Static Code
Changes Analysis

Developer B
Build Database

Commits Version Build Generate Help
Build Files
Changes Control Integration
Scripts
Server Server Archive and
Deploy
Developer C

Rady, B., & Coffin, R. (2011). Continuous testing: With ruby, rails, and javascript. Raleigh, NC: Pragmatic Bookshelf.
Humble, J., & Farley, D. (2011). Continuous delivery: Reliable software releases through build, test, and deployment automation. Boston, MA: Pearson.
88

Agile Testing Practices
 Agile testing consists of seven broad practices
 Includes automated builds, testing, inspections, etc.
 Also includes reporting, documentation, deployment, etc.
Practice Description
Building Frequently assembling products and services to ensure delivery readiness

Database Frequently generating/analyzing database schemas, queries, and forms

Inspections Frequently performing automated static analysis of product/service quality

Testing Frequently performing automated dynamic product and service evaluation

Feedback Frequently generating automated status reports/messages for all stakeholders

Documentation Frequently performing automated technical/customer document generation

Deployment Frequently performing automated delivery of products/services to end users


89

Agile Testing Statistics
 Fewer builds leave in higher bug counts
 A high number of builds eliminates the defects
 Goal is to have as many, early builds as possible

Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 387-392.

90

Scaling Agile Testing
 Agile testing slows down with very large systems
 Slow testing slows integration and increases bugs
 Agile testing can speed back up with proper attention

Kokko, H. (2009). Increase productivity with large scale CI: Reduce feedback cycle from weeks to 100 minutes. Proceedings of
the Agile 2009 Conference, Chicago, Illinois, USA.
91

Agile Testing Costs & Benefits
 Most agile testing tools are “free” open source
 A build server is no more than a commodity PC
 10x more efficient/effective than traditional testing

Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.
Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Japanese Symposium on Software Testing, Tokyo, Japan.
92

Agile Testing Cost of Quality
 Agile testing is 10x more efficient than manual tests
 ROI of agile testing is 27x more than traditional testing
 Performed 1,500x more often than traditional tests yearly

Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Proceedings of the Sixth Japan Symposium
on Software Testing (JASST 2008), Tokyo, Japan.
93

Agile Testing Side Effects
 Eliminates big-bang integration in the 11th hour
 Creates a repeatable and reliable testing process
 Evaluates system-wide changes throughout project


94

Agenda
 Agile Security Engineering Agile Resources 95

Security by Plan
 First step is to appoint a security team lead
 Identifying security risks & requirements is key
 Emphasis on training & security incident prevention
Security by Plan

Appoint
Security
Coordinator
Develop Perform
Security Security
Plan Training

Identify Security Perform Security
& Privacy & Privacy Risk
Requirements Assessment

Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author.
Microsoft. (2010). Security development lifecycle. Redmond, WA: Author.
96

Security by Design
 Next step is to identify design requirements
 Identify security architecture and subsystems
 Develop threat model and reduce attack surface
Security by Design

Identify Security
& Privacy Design
Requirements
Perform Document Security
Security Architecture &
Design Review Attack Surface

Develop and
Identify Critical
Analyze Threat
Components &
Model & Reduce
Security Assets
Attack Surface

97

Security by Implementation
 Then identify development & evaluation tools
 Identify and apply security patterns & practices
 Must perform manual & automated code reviews
Security by Implementation

Identify
Development
Environment
Perform Manual
Identify Static
& Automated
& Dynamic
Security
Security Tools
Code Analysis

Identify Security
Apply
Coding Patterns,
Security Coding
Standards, &
Best Practices
Practices

98

Security by Validation
 Also develop security test plans and procedures
 Perform automated security testing & analysis
 Validate to-be vs. as-is security architecture
Security by Validation

Create
Security & Privacy
Test Plans &
Review Procedures
Perform Dynamic
Test Results &
Security Testing
Update Security
& Analysis
Documentation

Perform Threat Perform Fuzz
Model & Attack & Penetration
Surface Review Testing

99

Security by Support
 Finally, develop security incidence response plan
 Systematically collect security incident reports
 Analyze, implement, re-verify, and update
Security by Support

Develop
Incidence
Response Plan
Implement & Verify
Perform Final
Security Changes,
Security Review &
Enhancements,
Archive Project
& Upgrades

Collect, Analyze,
Develop & Prioritize
& Classify
Security
Security Incident
Maintenance Plans
Reports

100

Top 25 Vulnerabilities
 Top 25 security vulnerabilities identified each year
 Many resources available to help mitigate them
 88% are preventable by security engineering
Top 25 Most Dangerous Security Vulnerabilities

Interactions Resources Defenses

 Cross Site Scripting  Buffer Overflow  Access Control

 SQL Injection  Path Traversal  Untrusted Inputs

 Cross Site Requests  PHP File Inclusion  Missing Encryption

 Unrestricted File Upload  Incorrect Buffer Length  Hard Coded Credentials

 OS Command Injection  Improper Exceptions  Missing Authentication

 Information Exposure  Array Index Validation  Permission Assignment

 URL Redirection  Integer Overflow  Cryptographic Algorithm

 Race Condition  Buffer Size Calculation

 Software Download

 Resource Allocation

Brink, D. E. (2010). Security and the software development lifecycle: Secure at the source. Boston, MA: Aberdeen Group.
Sans Institute. (2010). Top 25 most dangerous software errors. Retrieved April 21, 2011 from http://www.sans.org/top25-software-errors.
101

Agenda
Agile Background  Agile Teamwork

Agile Teamwork Model
 A key element of any project is good teamwork
 Agile projects depend upon teamwork even more
 Balance between cohesion & out-of-the-box thinking
Factor Attributes
Leadership Credible, experienced, likeable, & nurturing project champion

Boundaries Clear vision, mission, goals, & objectives

Empowerment Adequate time, money, tools, & authority

Competence Applicable skills, knowledge, experience, & personality

Structure Clear roles, responsibilities, technical approach, & operating rules

Manageability Small, collaborative, cohesive, & frequently-communicating

Motivation Compensation, incentives, desire-to-succeed, & consequences

Rico, D. F. (2011). The key attributes and factors of teams and teamwork for agile project management. Fairfax, VA: Gantthead.Com.

103

Well-Coached
 Agile teams start with great servant-leaders
 Agile teams rely more on coaches and mentors
 Coaches and mentors are wise and trusted teachers

Davies, R., & Sedley (2009). Agile coaching. Raleigh, NC: Pragmatic Bookshelf.
Adkins, L. (2010). Coaching agile teams: A companion for scrummasters, agile coaches, and project managers in transition. Boston, MA: Addison-Wesley.
104

Clear Vision
 Agile teams must be given clearly-stated mission
 Customers should specify their needs, not solution
 Agile teams must form a clear vision of the end-state

Belsky, S. (2010). Making ideas happen: Overcoming the obstacles between vision and reality. New York, NY: Penguin Group.
Kossoff, L. L. (1999). Executive thinking: The dream, the vision, the mission achieved. Palo Alto, CA: Davies-Black Publishing.
Bates, S. (2009). Motivate like a CEO: Communicate your strategic vision and inspire people to act. New York, NY: McGraw-Hill. 105

Fully-Empowered
 Agile teams are empowered to get the job done
 Teams must have power, authority, and resources
 Egalitarian decision-making unleashes team capability

Wordenweber, B. (2005). Innovation cell: Agile teams to master disruptive innovation. Berlin, Germany: Springer-Verlag.
Wellins, R. S., Byham, W. C., & Wilson, J. M. (1993). Empowered teams: Creating self-directed work groups that improve
quality, productivity, and participation. San Francisco, CA: Jossey-Bass. 106
.

Highly-Talented
 Agile teams consist of highly-competent individuals
 Individuals must have the requisite training and skills
 Highly-talented individuals are the heart of agile teams

Bach, J. (1995). Enough about process: What we need are heroes. IEEE Software, 12(2), 96-98.
Hunt, A., & Thomas, D. (1999). The pragmatic programmer. From journeyman to master. Reading, MA: Addison-Wesley.
Martin, R. C. (2009). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall. 107

Great Teamwork
 Agile teams should be small and very manageable
 They should exhibit collectivism, cohesion, and trust
 Agile teams must seamlessly complement each other

Eckert, B., & Vehar, J. (2007). More lightning, less thunder: How to energize innovation teams. Paul Smiths, NY: New & Improved.
Ancona, D., & Bresman, H. (2007). X-teams: How to build teams that lead, innovate, and succeed. Boston, MA: Harvard Business School Press.
Kayser, T. (2010). Mining group gold: How to cash in on the collaborative brain power of a team for innovation and results. New York, NY: McGraw-Hill. 108

Agenda
Agile Introduction  Agile Scalability

Multi-Level Teams
 Enables projects to plan for the future and present
 Decomposes capabilities into implementable pieces
 Unclogs the drainpipes to let the execution flow freely






Highsmith, J. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.

110

Multi-Level Backlog
 Enables multiple levels of abstraction to co-exist
 Allows customers and developers to communicate
 Makes optimum use of everyone’s time and resources







111

Multi-Level Planning
 Enables multiple level enterprise plans to co-exist
 Allows stakeholders to build viewpoint-specific plans
 Ensures capabilities are delivered at regular intervals







112

Multi-Level Coordination
 Enables lean and agile methods to scale-up
 Allows enterprises to create large-scale programs
 Unleashes optimum productivity and overall control


113

Multi-Level Governance
 Enables enterprises to achieve functional needs
 Allows programs to coordinate functional activities
 Ensures optimal technical performance is achieved
R T S

R R R T T T S S S
R R R T T T S S S
R R R T T T S S S

R A D R A D R A D R A D R A D R A D R A D R A D R A D
I T C I T C I T C I T C I T C I T C I T C I T C I T C
Q W S Q W S Q W S Q W S Q W S Q W S Q W S Q W S Q W S




114

Multi-Level Delivery Model
 Begins with a high-level product vision/architecture
 Includes multi-level teams and product requirements
 Demonstrates agile delivery model for large programs

Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.

115

Agenda
Agile Business Case  Agile Lean/Kanban

What is Kanban?
 Kan-ban ('kæn-bæn): Signboard, billboard, signal
cards; Lean, just-in-time system of production
 A lean and just-in-time manufacturing process for
regulating the flow of production based on demand
 A pull-system philosophy of customized production vs. a
push-system of mass-market manufacturing
 A set of principles for creating a lean, efficient, and
waste-free product flow by limiting work-in-process
 Use of simple organizational policy changes resulting in
order-of-magnitude performance improvements

  Framework for optimizing workflow that maximizes
efficiency, product quality, and customer satisfaction

117

Kanban Goals
 Kanban seeks initially to change as little as possible
 Change without resistance is the first Kanban goal
 Focus on improving quality, lead time and morale
Goal 1 Optimize existing processes (rather than change them)

Goal 2 Deliver high product quality (to build stakeholder trust)

Goal 3 Reduce long lead times (and stabilize them)

Goal 4 Achieve sustainable pace (work-life balance)

Goal 5 Provide process slack (for process improvement)

Goal 6 Simplify workload prioritization (of customer needs)

Goal 7 Provide transparency (into design and operations)

Goal 8 Strive for process maturity (to improve performance)


118

Kanban Recipe for Success
 Based on principles for product development flow
 Uses operations and mathematical queue theory
 Pragmatic operating principles for development
Focus on Quality Reduce WIP Deliver Often Balance Demand Prioritize Attack Variability

 Walkthroughs  Process flowcharting  Short releases  Regulate inputs  Prioritize inputs  Work item size

 Inspections  Workflow analysis  Short increments  Identify bottlenecks  Business focus
-  Work item type mix
 Technical reviews  Kanban boards  Short iterations  Create slack  Business value focus  Service class mix
 Peer reviews  Limit work tasks  Small releases  Limit work-in-process  Influence prioritization  Irregular flow
 Pair programming  Limit queues  Frequent releases  Create pull system  Stabilize process  Rework

 Test driven design  Limit buffers  Small batch sizes  Focus on precision  Build stakeholder trust  Ambiguous reqmnts.
 Continuous integration  Limit backlogs  Customer collaboration  Focus on quality  Perform risk analysis  Expedited requests
 Design patterns  Simple prioritization  Developer collaboration  Take pride in work  Analyze demand  Environment avail.
 Refactoring  Adequate resources  Ample communication  Improve morale  Evaluate size  Market fluctuations

 Design simplicity  Process automation  Frequent builds  Learn new skills  Evaluate complexity  Coordination
 Usability engineering  Policy statements  Deploy often  Obtain training  Market forecasting  Technological change
 Formal methods  Simplify process  Automatic updates  Continuously improve  Technology analysis  Skill/experience mix


119

Value Stream Mapping
 Start by flow-charting the as-is product workflow
 Add buffers and queues one feels are necessary
 Add WIP limits to buffers, queues, and activity


120

Work-in-Process
 High work-in-process leads to longest lead times
 Low work-in-process greatly reduces lead times
 Results in better customer trust and satisfaction
Bad Project Good Project
175 240

140 192
Features

Features
105 144

70 96

35 48

0 0
10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26 2/10 2/17 2/24 3/2 3/9 3/16

Time Time
Inventory Started Designed Coded Complete Inventory Started Designed Coded Complete


121

Agenda
Agile Life Cycles  Agile Scrum

Scrum Project Management
 Product backlog comprised of customer needs
 Barely-sufficient project management framework
Initial Planning Sprint Cycle

Discovery Session Sprint

 Agile Training  Select Tasks and Create Tests
 Project Discovery  Create Simple Designs
 Code and Test Software Units
 Process Discovery
 Perform Integration Testing
 Team Discovery
 Maintain Daily Burndown Chart
 Initial Backlog  Update Sprint Backlog

Release Planning Sprint Planning Daily Scrum Sprint Review

 Business Case  Set Sprint Capacity  Completed Backlog Items  Present Backlog Items
 Desired Backlog  Identify Tasks  Planned Backlog Items  Record Feedback
 Estimate Tasks  Impediments to Progress  Adjust Backlog
 Hi-Level Estimates
 Prioritize Backlog
 Finalize Backlog

Product Backlog Sprint Backlog Potentially Shippable Product

 Prioritized Requirements  List of Technical Tasks Assigned to a Sprint  Working Operational Software


123

Scrum Roles
 There are only three roles in the Scrum paradigm
 Product Owner is single wringable neck (cust. rep.)
 Scrum Master is overall process facilitator (i.e., coach)

Scrum Master Scrum Master - Responsible for facilitating the
process

Product Owner - Represents the client and
owns the requirements

Scrum Team - Responsible for completing the
work and fulfilling the requirements

Scrum Master assists the Product Owner in
Planning Progress planning the release and making resources
available

Scrum Scrum Master helps the Scrum Team make
progress by removing impediments

Product Owner Scrum Team Product Owner works closely with the Scrum
Team to provide clarification and approval on
Clarification requirements

Whole team meets daily to review progress and
review the completed work at the end of each
sprint


124

Sprint Planning
 An eight hour timeboxed Sprint planning meeting
 Identifies highest priority requirements to implement
 Purpose is to produce a Sprint plan for 14 to 30 days
Eight Hour Time Limit

Customer
Release Planning Product
Needs Backlog
 Create Stories
 Make ROI Goals
 Set Release Plans
Select Stories Agreed to
Backlog
 Select Stories
 Suggest Stories
 Determine Stories
Prepare Sprint Sprint
Backlog
 Ask Questions
 Develop Tasks
 Create Estimates
 Make Assignments

Product Owner, Scrum Master, Team


125

Sprint
 A 14 to 30 day timeboxed development iteration
 High priority requirements decomposed into tasks
 Purpose is to produce shippable product increment
30 Day Time Limit

Sprint
Manage Sprint Development
Backlog Tasks
 Freeze Backlog
 Seek Information
 Adjust Backlog
 Decision to Proceed Create Product Development
 Analyze Tasks Status

 Design Solution
 Implement Solution
 Test Solution Track Status Shippable
Product
 Checkoff Tasks
 Estimate Velocity
 Burndown Charts



126

Daily Scrum Meeting
 A 15 minute timeboxed daily status meeting
 Developers state progress in a round robin style
 Purpose is to ensure that developers collaborating
15 Minute Time Limit

Yesterday’s
Meeting Kickoff Meeting
Progress Initiation
 Begin Meeting
 Facilitate Meeting
 Enforce Protocols
Report Status Daily
Status
 Report Progress
 State Daily Plans
 Note Impediments
Establish Followup Followup
Notices
 Ask for Help
 Identify Issues
 Plan Followup



127

Sprint Review
 A four hour timeboxed product demonstration
 Developers discuss requirements implemented
 Purpose is to show customers the result of Sprint
Four Hour Time Limit

Shippable
Prepare for Review Product
Product Demo
 Arrange Location
 Verify Product
 Prepare Demo
Hold Review Customer
Feedback
 State Sprint Goal
 List Requirements
 Report Progress
 Present Product Close Review New
Backlog
 Gauge Satisfaction
 Rearrange Backlog
 Identify New Needs

Product Owner, Scrum Master, Team, Customers


128

 A three hour timeboxed lessons learned meeting
 Developers identify potential process improvements
 Purpose is to identify new non-functional requirements
Three Hour Time Limit

Sprint
Facilitate Meeting Sprint
Results Outcomes
 Check Attendance
 Verify Preparations
 Enforce Protocol
Hold Retrospective Process
Improvements
 State Strengths
 State Weaknesses
 State Improvements
Review Changes Approved
Changes
 Discuss Changes
 Prioritize Changes
 Baseline Chances



129

Agenda
Agile Practices  Agile Metrics & Models

Basic Agile Metrics
 Agile methods are based on traditional measures
 Size, effort, and velocity metrics are most common
 Top-notch shops use complexity and testing metrics
Type Example
Size Story Points, Ideal Days, Function Points, Lines of Code, etc.

Effort Ideal or Actual Hours, Days, Weeks, Months, Years, etc.

Velocity Release/Iteration Burndown/Burnup, Cumulative Flow, EVM, etc.

Structure Object-Oriented, Relational Database, McCabe, Halstead, etc.

Quality Running Tested Features, Defect Density, FURPS, MTBF, etc.

Satisfaction CUPRIMDA, Communications, Trust, Loyalty, Retention, etc.

Business Value Costs, Benefits, BEP, B/CR, ROI, NPV, IRR, ROA, EBV, etc.

Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation.
Ft. Lauderdale, FL: J. Ross Publishing.
131

Burndown/Burnup Metrics
 Time expended is used for project tracking
 Tracked on a per-iteration or per-sprint basis
 Often described as a basic earned-value metric
Type Example
Ideal Days How many days something takes without interruptions

Actual Days How many days something takes with interruptions

Ideal Hours How many hours something takes without interruptions

Actual Hours How many hours something takes with interruptions

User Stories How many customer requirements have been satisfied

Story Points How many units of software size have been satisfied

Technical Tasks How many technical tasks have been completed

Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education.

132

Agile Cost Models
 Costs based on productivity and quality
 Development costs based on LOC  productivity
 Maintenance costs based on defects  KLOC  MH
Type Example
Basic Form (LOC  Productivity + Quality  KLOC  100)  Hourly Rate

XP (LOC  16.1575 + 0.7466  KLOC  100)  Hourly Rate

TDD (LOC  29.2800 + 2.1550  KLOC  100)  Hourly Rate

PP (LOC  33.4044 + 2.3550  KLOC  100)  Hourly Rate

Scrum (LOC  05.4436 + 3.9450  KLOC  100)  Hourly Rate

Agile (LOC  21.2374 + 1.7972  KLOC  100)  Hourly Rate

133

Agile Business Value
 A major principle of Agile Methods is creating value
 ROI is the measure of value within Agile Methods
 There are seven closely related ROI measures
Type Example
Costs Total amount of money spent on agile methods

Benefits Total amount of money gained from using agile methods

Breakeven Point when the benefits of using agile methods exceed the costs

B/CR Ratio of agile methods benefits to costs of using agile methods

ROI Ratio of adjusted agile methods benefits to costs of using them

NPV Present value of agile methods benefits that result from their use

Real Options Value gained from incremental investments in high-risk projects

134

Agile EVM
 EVM has been adapted to Agile Methods
 EVM based on notion that total scope is known
 EVM may “not” be well-suited for large agile projects

Type Example
PMB Total number of story points planned for a release

SBL Total number of iterations multiplied by iteration length

BAC The planned budget for the release

PPC Number of current iterations divided by planned iterations

APC Total story points completed divided by story points planned

SPC Story points of work completed from backlog during iteration

SPA Story points added/subtracted from backlog during iteration

Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects. Proceedings of the Agile
2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16.
135

Agenda
Agile Requirements  Agile Costs & Benefits

Extreme Programming
 Costs based on avg. productivity and quality
 Productivity ranged from 3.5 to 43 LOC an hour
 Costs were $136,551, benefits were $4,373,446
Metric Formula Value
Costs (10,000 16.1575 0.7466 10 30) 100 $136,551

Benefits (10,000 .51 – 6,666.7 ) 100 – $136,551 $4,373,446

B/CR $4,373,446 $136,551 32:1

ROI ($4,373,446 – $136,551) $136,551 100% 3,103%

NPV ( ($4,373,446 1.055) – $136,551
5
i 1 5) $3,650,396

BEP $136,551 ($4,509,997 $136,551 – 1) $4,263
NORMSDIST (8.07) $4,373,446 –
ROA $4,267,100
NORMSDIST (7.59) $136,551 EXP (–5% 5)

Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes
and documentation. Ft. Lauderdale, FL: J. Ross Publishing.
137

Test-Driven Development
 Productivity ranged from 12 to 46 LOC an hour
Costs (10,000 29.2800 + 2.1550 10 100) 100 $249,653

Benefits (10,000 10.51 – 6,666.67 9) 100 – $249,653 $4,260,344

B/CR $4,260,344 $249,653 17:1

ROI ($4,260,344 – $249,653) $249,653 100% 1,607%

NPV ( ($4,260,344 1.055) – $249,653
5
i 1 5) $3,439,359

BEP $249,653 ($4,509,997 $249,653 – 1) $14,629
NORMSDIST(2.79) $4,260,344 –
ROA $4,074,506
NORMSDIST(1.27) $249,653 EXP(–5% 5)

138

Pair Programming
 Productivity ranged from 15 to 86 LOC an hour
Costs (10,000 33.4044 + 2.3550 10 100) 100 $265,436

Benefits (10,000 10.51 – 6,666.67 9) 100 – $265,436 $4,244,561

B/CR $4,244,561 $265,436 16:1

ROI ($4,244,561 – $265,436) $265,436 100% 1,499%

NPV ( ($4,244,561 1.055) – $265,436
5
i 1 5) $3,409,909

BEP $265,436 ($4,509,997 $265,436 – 1) $16,599
NORMSDIST(2.69) $4,244,561 –
ROA $4,050,919
NORMSDIST(1.10) $265,436 EXP(–5% 5)

139

Scrum
 Productivity ranged from 4.7 to 5.9 LOC an hour
Costs (10,000 5.4436 + 3.9450 10 100) 100 $578,202

Benefits (10,000 10.51 – 6,666.67 9) 100 – $578,202 $3,931,795

B/CR $3,931,795 $578,202 7:1

ROI ($3,931,795 – $578,202) $578,202 100% 580%

NPV ( ($3,931,795 1.055) – $578,202
5
i 1 5) $2,826,321

BEP $578,202 ($4,509,997 $578,202 – 1) $85,029
NORMSDIST(2.08) $3,931,795 –
ROA $3,660,805
NORMSDIST(-0.15) $578,202 EXP(–5% 5)

140

Agile Methods
 Productivity ranged from 3.5 to 86 LOC an hour
Costs (10,000 21.2374 + 1.7972 10 100) 100 $226,807

Benefits (10,000 10.51 – 6,666.67 9) 100 – $226,807 $4,283,190

B/CR $4,283,190 $226,807 19:1

ROI ($4,283,190 – $226,807) $226,807 100% 1,788%

NPV ( ($4,283,190 1.055) – $226,807
5
i 1 5) $3,481,988

BEP $226,807 ($4,509,997 $226,807 – 1) $12,010
NORMSDIST(2.99) $4,283,190 –
ROA $4,110,305
NORMSDIST(1.59) $226,807 EXP(–5% 5)

141

ROI of Agile Methods
 XP ROI 18X more than traditional methods
 Scrum ROI 3.4X more than traditional methods
 Agile methods ROI 10X more than trad. methods
3,700%

3,103%
Return on Investment

2,775%

1,788%
1,850% 1,607%
1,499%

925%
580%

173%
0%
XP Agile TDD PP Scrum CMMI®

Software Method

142

Business Value of Agile Methods
 Productivity is accelerated with light weight processes
 Quality goals are obtained with disciplined processes
 Agile Methods have up to 20 times lower total costs

Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods:
Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross.
143

Agenda
Agile Project Mgt. Models  Agile Earned Value Mgt.

Burndown
 Most basic tracking chart for agile projects
 Tracks number of work or time units completed
 Commonly used to track no. story points completed
Burndown Chart
Work (Story, Point, Task) or Effort (Week, Day, Hour)

Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day)

Rawsthorne, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

145

Burnup
 Popular tracking chart for agile projects
 Tracks number of work or time units completed
 Basic form of cumulative workflow & overall progress
Burnup Chart


Nicolette, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

146

Cumulative Flow
 High work-in-process leads to longest lead times
 Low work-in-process greatly reduces lead times
 Results in better customer trust and satisfaction
Traditional vs. Agile Cumulative Flow

Traditional Cumulative Flow Agile Cumulative Flow


Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)

Anderson, D. J. (2004). Agile management for software engineering: Applying the theory of
constraints for business results. Upper Saddle River, NJ: Pearson Education.
147

Agile EVM
 Adaptation of EVM for agile projects
 Mapping between traditional and agile projects
 Work completed is more authoritative in agile projects
Agile EVM

CPI

SPI

PPC

APC


Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects.
Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16.
148

Earned Business Value
 ROI is estimated for user stories in agile projects
 Value accrues with each completed user story
 Value of completed tasks is more meaningful
Earned Business Value


Rawsthorne, D. (2010). Monitoring scrum projects with agile evm and earned business value metrics. Brisbane, CA: Collab.Net.

149

Agenda
Agile Project Mgt. Phases  Agile Documentation

Agile Documentation
 Myth that voluminous documentation is needed
 Myth that agile methods do not use documentation
 Right-sized, just-in-time processes and documentation
Document Type Agile Documentation
Contracts Performance-based, time-and-materials, level-of-effort
Project Plans Release plans, iteration plans, story boards, agile repositories
Requirements User stories, wire frames, use cases, paper prototypes
Architecture Metaphors, spikes, system modeling language, DoDAF
Design Wire frames, design patterns, unified modeling language
Coding Code patterns, program design language, coding comments
Tests Unit, component, integration, system, and acceptance tests
User guides XML documents, online help, Wikis, FAQs, video and audio clips
Quality Assurance Performance, reliability, code structure analysis, and test reports

Rueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.

151

Release Plan
 Fluid, informal roadmap for planning releases
 Includes dates for releases, iterations, and stories
 Must prioritize, split, estimate, and order user stories

Release Plan Release Plan
Release Iteration Story
Release Plan 1 1 01 thru 06
Release 1 2 07 thru 12
Iteration 2 3 13 thru 18
2 4 19 thru 24
n n 25 thru nn


152

Iteration Plan
 Plan that divides iterations into development tasks
 Each iteration is one to three weeks in duration
 Iteration plans updated using daily standups


153

User Story
 A function or feature of value to a customer
 An estimable and testable software requirement
 Six user stories should be implemented per iteration


154

System Metaphor
 Simple story about how the whole system works
 Overarching 10,000 foot view of system architecture
 Pushes the system into a sense of coherent cohesion


155

Acceptance Tests
 Black-box, functional tests to be performed
 Specified by customers during iteration planning
 Run when user stories and unit tests are completed


156

Agenda
Agile Release Planning  Agile Automated Tools

Agile Tools & Automation
 Agile tools exist to support the entire lifecycle
 Key tools exist as free and open source software
 Maximize flexibility, efficiency, reporting, and quality

158

Agile Workflow Tools
 Range from project management to communications
 Includes information sharing/knowledge management
 Workflow tools are helpful for large, distributed projects

Project Management
 Version One
 Rally
 Scrum Works Collaboration
 Xplanner
 WebEx
 Ice Scrum
 Skype
 Mingle
 MeetMe Wiki
 Wimba
 MediaWiki
 SameTime
 TracWiki
 NetMeeting
 PhpWiki Chat
 MoinMoin
 ICQ
 TikiWiki
 AOL
 WakkaWiki
 MSN
 Cahoots
 Yahoo
 PowWow

Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.

159

Agile Engineering Tools
 Range from requirements to unit testing automation
 Includes design automation such as screen mockups
 Agile engineering tools are good for distributed projects

Requirements
 DOORS
 RequisitePro
 SLATE Design
 RDD-100
 Rhapsody
 Core
 Telelogic SA
 RTM
 Rational SA Coding
 Artisan
 Notepad++
 Papyrus
 JEdit
 Statemate
 Notepad2 Testing
 Prog. Notepad
 JUnit
 Crimson Editor
 NUnit
 ConTEXT
 Xunit
 CPPUnit
 Gtest
 Fit

Ambler, S. W. (2002). Agile modeling: Effective practices for extreme programming and the unified process. New York, NY: John Wiley & Sons.
Ambler, S. W. (2004). The object primer: Agile model-driven development with UML 2.0. New York, NY: Cambridge University Press.
160

Agile Support Tools
 Range from code analysis to continuous integration
 Includes one-touch system-level regression analysis
 Agile support tools are scalable to large-scale projects

Quality Assurance
 CheckStyle
 PMD
 EMMA Configuration Mgt
 Jdepend
 Subversion
 Cobertura
 CVS
 Gcov
 ClearCase Build Automation
 MKS
 Ant
 Perforce
 NAnt
 VSS
 Maven Continuous Integ
 Make
 Cruise Control
 Rake
 Hudson
 Jar
 BuildBot
 Continuum
 TeamCity
 AntHill

Mason, M. (2006). Pragmatic version control: Using subversion. Raleigh, NC: Pragmatic Bookshelf.
Clark, M. (2004). Pragmatic project automation: How to build, deploy, and monitor jave apps. Raleigh, NC: Pragmatic Bookshelf.
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley. 161

Agile Middleware Tools
 Range from IDEs to middleware frameworks
 Includes Web mashup application composition
 Agile middleware tools are useful for all projects

Environments
 Eclipse
 Visual Studio
 Sun Studio Frameworks
 NetBeans
 Spring
 GNAT Prog Studio
 Hibernate
 OpenWatson
 Struts Mashups
 AJAX
 Google Maps
 Google Guice
 Google Search
 HiveMind
 Google Docs Documentation
 Amazon Web
 NDoc
 Flickr
 Javadoc
 Twitter
 Doxygen
 iText
 SoDa
 ROBODoc

Hemrajani, A. (2006). Agile java development with spring, hibernate, and eclipse. Indianapolis, IN: Sams Publishing.
Klocker, C. (2008). Mashups: A new concept in web application programming. Saarbrucken, Germany: VDM Verlag.
162

Agile E-Commerce Tools
 Range from Web graphics to turnkey e-commerce
 Includes full-service Web hosting and shopping carts
 Agile e-commerce tools are ideal for very large projects

Web Graphics
 PhotoShop
 Illustrator
 Painter Website Design
 Manga
 Flash
 Artweaver
 Fireworks
 Opencanvas
 ColdFusion Website Hosting
 Dreamweaver
 Inmotion
 FrontPage
 iPage
 Freehand
 JustHost Web Stores
 WebHostingPad
 Shopsite Pro
 FatCow
 Merchandizer Pro
 WebHostingHub
 Network Solutions
 SunShop
 StoreFront
 Mercantec

Elad, J. (2008). Web stores: Do it yourself for dummies. Hoboken, NJ: Wiley Publishing.
Kaye, D. (2002). Strategies for web hosting and managed services. New York, NY: John Wiley.
163

Agenda
Agile Iteration Planning  Agile Contract Models

Agile Contracting Models
 New contract models emerged for agile contracts
 Goals, objectives, and visions are established early
 Buyers and suppliers collaborate throughout contract
Contract Type Description
Dynamic Value Specify initial scope and needs (with iterative enhancements)

Performance Based Establish performance objectives (but not technical solutions)

Target Cost Broad boundaries for time, cost, and quality (but not scope)

Optional Scope Set minimum and maximum costs (based on initial scope)

Collaborative Outline initial scope (with fixed no. of releases and iterations)

Lean Lean tools such as small batches, Kanban, WIP constraints, etc.

Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com.

165

Performance-Based Acquisition
 Developed by U.S. DoD in the 2000 timeframe
 Born out of radical acquisition reforms of 1990s
 Focuses on objectives and outcomes vs. process
Performance Based Services Acquisition

Integrated Solutions Team Problem Statement Private and Public Solutions
 Ensure management involvement  Link acquisition to strategic roadmap  Team approach to market research
 Tap multi disciplinary expertise  Link acquisition to mission objectives  Learn from public sector
 Define roles and responsibilities  Link acquisition to performance goals  Consult with private sector firms
 Develop rules of conduct  Define desired results at a high level  One on one industry meetings
 Empower and incentivize team  Decide what constitutes success  Look for existing contracts
 Identify stakeholders  Determine current performance level  Document market research

Statement of Objectives Measure Performance Select Contract Manage Performance
 Elevator message  Success determinants  Compete the solution  Keep the team together
 Describe the scope  Quality standards  Oral presentations  Roles and responsibilities
 Performance objectives  Proposed metrics  Past performance  Assign accountability
 Share objectives  Meaningful measures  Best value evaluation  Formal kick off meeting
 Identify the constraints  Contractual language  Final source selection  Performance based mgt
 Develop the background  Order of precedence  Conflict of interest  Review performance

Gansler, J. S. (2000). Guidebook for performance based services acquisition in the U.S. DoD. Washington, DC: Author.
Sade, M. (2009). Seven steps to performance based services acquisition. Washington, DC: General Services Administration.
166

Target Cost
 Concept attributed to Toyota Production System
 Adapted for agile project management in 2005
 Good balance of structure, flexibility, & trust
Target Cost Contract

Scope Statement Statement of Work Master Agreement Release Plan Closeout
 Business vision  Development days  Non-disclosure terms  Feature priorities  Acceptance test
 System metaphor  Support estimate  Product ownership  Wireframes  Final documentation
 User stories  Contingency  Indemnification terms  Development tasks  Document handover
 Effort estimate  Cost estimate  Non-compete terms  Task effort  Deployment testing
 Priorities  Fixed profit  Administration  Iteration plan  Joint evaluation
 Roadmap  Total cost estimate  Termination terms  Workflow tool  Administrative close

Development

Iterations, Sprints, or Increments Change Management
 Perform daily standup meetings  Perform customer demonstration
 Develop acceptance and unit tests  Solicit feedback from client
 Create or refactor software code in pairs  Classify and categorize feedback
 Check-in code and perform unit testing  Negotiate scope changes with client
 Perform continuous integration  Update letter of agreement (LOA)
 Hold iteration retrospective  Update release and iteration plans

Support Processes
 Security engineering, user experience design, software certification testing, quality assurance, configuration management, etc.

Eckfeldt, B., Madden, R., & Horowitz, J. (2005). Selling agile: Target cost contracts. Proceedings of the Agile Conference (Agile 2005), Denver, Colorado, USA, 160-166.

167

PS2000 for Agile
 Developed by Norwegian Computer Society
 Adapted for IT, incremental, and agile methods
 Upfront scoping similar to Feature Driven Design
PS2000 Agile Contract

Needs Phase Solution Description Phase Approval and Completion Phase
 Perform needs analysis  Develop high level prototypes  Perform acceptance testing
 Develop uncertainty matrix Sign
 Develop architecture and design  Perform quality certification
 Analyze top level risks areas Contract  Establish development priorities  Deliver final documentation
 Identify development environment  Prepare description of solution  Perform joint project evaluation
 Prepare milestones and schedules  Verify solution description  Perform limited maintenance

Approve Prepare
Solution Delivery

Iterative Construction

Detailed Planning Product Development and Verification Testing and Debugging

 Analyze needs and solution description  Document development methods and tools  Prepare test plans and specifications
 Develop detailed iteration plan  Develop prototypes and components  Perform detailed component testing
 Develop detailed specifications  Demonstrate prototypes and components  Perform integration and system testing
 Develop detailed design models  Gather customer or end user feedback  Monitor, log, and remediate defects
 Verify detailed design  Perform verification and quality assurance  Perform quality and reliability modeling

Checkpoints, Beta Testing, and Other Services
 Configuration management, iteration retrospectives, checkpoint progress reviews, re-planning and mid-course corrections, training, etc.

Norwegian Computer Society. (2010). PS2000 standard contract for software development. Oslo, Norway: Author.

168

Evolutionary Acquisition
 Idea originated from Barry Boehm in 1985
 Adapted to U.S. DoD acquisitions in 1999/2000
 Incrementally insert emerging technology into acq.
Evolutionary Acquisition
MDD 6 Months MDD 12 Months MDD 18 Months MDD 24 Months MDD 30 Months
Material Increment 1 Increment 2 Increment 3 Increment 4 Increment 5
Solution Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3

Analysis Technology Strategy Technology Strategy Technology Strategy Technology Strategy Technology Strategy

A1 A2 A3 A4

Increment 1 Increment 2 Increment 3 Increment 4
Technology Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3
Development System Prototype System Prototype System Prototype System Prototype

B1 B2 B3

Increment 1 Increment 2 Increment 3
Engineering & Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3
Manufacturing Finished System Finished System Finished System

CDR C1 CDR C2 CDR

Increment 1 Increment 2
Production &
Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3
Deployment LRIP LRIP

FDR IOC FDR

Increment 1
Operations &
Spiral 1 Spiral 2 Spiral 3
Support FRPS

FOC

Ford, D. N., & Dillard, J. (2009). Modeling the performance an risks of evolutionary acquisition. Defense Acquisition Review Journal, 16(2), 143-158.

169

Lean & Agile Acquisition
 Originated from agile methods popularity in 2002
 Gained foothold in U.S. DoD with scrum popularity
 Frontloads systems engineering with early systems
Lean & Agile Acquisition

Material
Technology Engineering & Production & Operations &
Solution
Development Manufacturing Deployment Support
Analysis

6 months 12 months 18 months 24 months 30 months

Release 1 Release 2 Release 3 Release 4 Release 5
Program 1 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6

Operational Capability Operational Capability Operational Capability Operational Capability Operational Capability

MDD A1 B1 CDR C1 FDR FRP IOC FOC

Program 2 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6



Program n Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6



Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. Defense AT&L Magazine, 39(6), 48-52.

170

Agenda
Agile Estimating  Agile Change Models

Diffusion of Innovations
 Idea originated with Everett Rogers in 1962
 A few early adopters will embrace a new idea
 The majority will resist change for a longer time
Diffusion of Innovations
Diffusion

Early Early Late
Innovators Laggards
Adopters Majority Majority

Rogers, E. (2003). Diffusion of innovations. New York, NY: Free Press.

172

Crossing the Chasm
 Idea originated with Geoffrey Moore in 1991
 Time between adoption phases is not uniform
 Large gap between early adopters and majority
Crossing the Chasm
Diffusion

Early Early Late
Innovators Laggards
Adopters Majority Majority

Moore, G. A. (2002). Crossing the chasm: Marketing and selling high tech products to mainstream customers. New York, NY: HarperCollins..

173

Virginia Satir Model
 Idea originated with Virginia Satir in 1980s
 Large changes plunge organizations into chaos
 Depth and length of chaos is related to its magnitude
Virginia Satir Model
Productivity

Status New
Resistance Chaos Recovery
Quo State

Satir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books.

174

Incremental Change
 Large change, no matter how good, often fails
 Goal is to break changes into smaller increments
 Smaller and imperceptible change is more successful
Incremental Change
Productivity

Status Resist- Reco- New Status Resist- Reco- New Status Resist- Reco- New
Chaos Chaos Chaos
Quo stance very State Quo ance very State Quo ance very State

Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications.

175

Organization Change Methods
 Top down big bang change is most often tried
 Punctuated equilibrium is most well known form
 Project champions and coaching are very effective
Organization Change Methods
Punctuated Equilibrium One time radical organizational change often motivated by a severe crisis, i.e., crisis is a catalyst for change

Personal Influence Informal appeal for authority to change based on personal trust or relationships, i.e., elevator speech

Business Case Compelling qualitative and quantitative business value analysis, i.e., return on investment analysis

Executive Coaching Formal or informal mentoring or tutoring of organizational executives and senior leaders

Executive Commitment A personal endorsement for change from an organizational executive or senior leader

Adequate Resources Formal allocation of resources to execute a large organizational change initiative

Top Down Change One time organization change initiative based on a formal strategic plan, i.e., big bang organization change

Model Driven Change Isolated change initiatives based on step by step frameworks, i.e., PDCA, DMAIC, DMADV, etc.

Manager Involvement Psychological involvement and commitment of middle managers to avoid bureaucratic obfuscation

Employee Involvement Psychological involvement and commitment of lower level workforce to avoid operational resistance

Training & Education Formal classroom instruction and education to impart the skills necessary for successful change

Evolutionary Change The implementation of numerous smaller scale changes to prevent long term psychological resistance and chaos


Project Champion Formal appointment of an individual to take personal responsibility for success of change, i.e., heavyweight PM

Coaching & Mentoring Formal or informal mentoring or tutoring of employees or team members to help them overcome hidden obstacles

Just Do It Assuming personal responsibility for change with or without formal authorization, i.e., forgiveness vs. permission

Holman, P., Devane, T., & Cady, S. (2007). The change handbook: The definitive resource on today’s best methods for emerging whole systems. Berrett-Koehler.

176

How to Cross the Chasm
 Change, no matter how small or large, is difficult
 Smaller focused changes help to cross the chasm
 Shrinking, simplifying, and motivation are key factors
How to Cross the Chasm

Switch How to Change Things When Change is Hard Influencer The Power to Change Anything

Direct the Rider Make the Undesirable Desirable
 Create new experiences - Make it interesting
 Follow the bright spots - Clone what works  Create new motives - Appeal to sensibility
 Script the critical moves - Use prescriptive behaviors
 Point to the destination - Focus on the end game Surpass your Limits
 Perfect complex skills - Establish milestones
 Build emotional skills - Build maturity and people skills

Motivate the Elephant Harness Peer Pressure
 Recruit public personalities - Involve public figures
 Find the feeling - Appeal to emotion
 Recruit influential leaders - Involve recognized figures
 Shrink the change - Use incremental change
 Grow your people - Invest in training and education Find Strength in Numbers
 Utilize teamwork - Enlist others to help out
 Enlist the power of social capital - Scale up and out

Shape the Path Design Rewards and Demand Accountability
 Use incentives wisely - Reward vital behaviors
 Tweak the environment - Simplify the change
 Use punishment sparingly - Warn before taking action
 Build habits - Create simple recipes for action
 Rally the herd - Get everyone involved Change the Environment
 Make it easy - Simplify the change
 Make it unavoidable - Build change into daily routine

Heath, C., & Heath, D. (2010). Switch: How to change things when change is hard. New York, NY: Random House.
Patterson, K., et al. (2008). Influencer: The power to change anything: New York, NY: McGraw-Hill.
177

Agenda
Agile Risk Analysis  Agile Case Studies

Agile Case Studies
 80% of worldwide IT projects use agile methods
 Includes highly-regulated industries like U.S. DoD
 Even split between top-down and bottom-up adoption
Industry Org Project Purpose Size Metrics
 20 teams  1,838 User Stories
Electronic
Google Adwords Advertising  140 people  6,250 Function Points
Commerce  5 countries  500,000 Lines of Code
Shrink Project
Primavera Primavera  90 people  91,146 Function Points
Wrapped Management  Collocated  7,291,666 Lines of Code
Health Blood
FDA m2000  20 people  5,640 Function Points
Care Analysis  Collocated  451,235 Lines of Code
Law Case File
FBI Sentinel  50 people  13,419 Function Points
Enforcement Workflow  Collocated  1,073,529 Lines of Code

U.S. Knowledge  3 teams  390 User Stories
Stratcom SKIweb  12 people  1,324 Function Points
DoD Management  Collocated  105,958 Lines of Code

Rico, D. F. (2010). Lean and agile project management: For large programs and projects. Proceedings of
the First International Conference on Lean Enterprise Software and Systems, Helsinki, Finland, 37-43.
179

E-Commerce—Google
 Google started using agile methods in 2005
 Used it on one of their most profitable products
 Incrementally adopted agile one practice at a time
Project Name AdWords

Project Type Pay-per-Click (PPC) Internet Advertising Mechanism

Project Size 20 teams of 140 people distributed over 5 countries

Product Size 1,838 user stories, 6,250 function points, 500,000 lines of code

Environment Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured

Before APM Chronic schedule delays, poor quality, unpredictability, poor estimation

APM Practices Release planning, wikis for APM support, early testing and continuous integration

After APM Better planning and estimates, earlier testing, better quality, large-scale adoption

Lessons Learned Agile fit like a hand-in-glove, introduce agile methods slowly and then scale-up

Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201.

180

Shrink-Wrapped—Primavera
 Primavera started using agile methods in 2004
 Used it on their flagship project management tools
 Adopted agile all-at-once with top-down mgt. support
Project Name Primavera

Project Type Enterprise Project Management Tool

Project Size 15 teams of 90 people collocated at one site

Product Size 26,809 user stories, 91,146 function points, 7,291,666 lines of code

Environment Top-down, hierarchical, command and control, traditional, waterfall approach

Poor relationships, quality, usability, and customer satisfaction, functional silos,
Before APM 18-hour days, 7-day work weeks, frustration, disappointment, apathy, exhaustion

APM Practices Release planning, agile project management tools, automated testing tools

After APM 75% quality and 40% cycle time improvement, 40-hour work week, 0% attrition

Lessons Learned Agile results in better communication, motivation, and empowerment

Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development. IEEE Software, 22(3), 36-42.

181

Healthcare—FDA
 FDA suppliers started using agile methods in 2008
 Used it on most stringent Class 3 certified products
 Used to modernize 1990s era products & processes
Project Name m2000 Real-time PCR Diagnostics System

Project Type Human Blood Analysis Tool (i.e., HIV-1, HBV, HCV, CT, NG, etc.)


Product Size 1,659 user stories, 5,640 function points, 451,235 lines of code

Environment FDA-regulated medical devices, real-time, safety-critical, Class III–most stringent

Cumbersome process, poor quality, long cycle time, slow big-bang integration, obsolete,
Before APM hard-to-staff tools and methods, inability to keep pace with changing requirements,
Intense market competition, exponential rate of technological change, fewer resources

APM Practices Release planning, lighter-weight agile testing techniques, continuous integration

After APM 25% cycle time and staff-size reduction, 43% cost reduction, fewer defects

Lessons Learned Agile enables the ability to balance fast cycle time with high-quality safety-critical solutions

Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile
2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155.
182

Law Enforcement—FBI
 IC started using agile methods following 9/11
 Used it on billion dollar transformation initiatives
 Goal is to catch bad guys better, faster, and cheaper
Project Name Inter-Agency Intelligence Sharing System

Project Type Domestic Terrorist Database/Data Warehouse


Product Size 643 user stories, 2,188 function points, 175,000 lines of code

CMMI Level 3, ISO 9001, government-mandated document-driven waterfall life cycle,
Environment emerging federal directives for more information sharing and integration among
intelligence community partners, rapidly changing customer requirements

Unresponsive waterfall life cycles, chronic schedule delays, anxious customers, unhappy
Before APM developers, resource focus on becoming CMMI Level 3 certified caused everyone to lose
track of the real goal, which was to “catch bad guys”

APM Practices Release planning, user stories, test-driven development, continuous integration

After APM 50% quality improvement, 200% productivity increase, FBI created policy for agile methods

Lessons Learned Agile enables fast response times, customer satisfaction, and ability to "catch bad guys"

Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009),
Chicago, Illinois, USA, 96-100.
183

U.S. DoD—STRATCOM
 U.S. DoD started using agile methods following 9/11
 Used it on billion-dollar software-intensive systems
 Goals are to respond to rapidly emerging threats
Project Name Strategic Knowledge Integration Website (SKIweb)

Project Type Knowledge Management System (KMS)—Advanced Search Capability


Product Size 390 user stories, 1,324 function points, 105,958 lines of code

Traditional linear documentation-based development, contract-oriented, hierarchical
communication, rapidly changing operational requirements, need for leaner U.S. military
Environment force, seeking better and faster ways of getting critical information to decision makers,
decentralization, migration to net-centric service oriented architectures, egalitarian decisions

Before APM Long cycle times, dissatisfied customers, unresponsive life cycles, poor quality

APM Practices Release planning, frequent customer collaboration, continuous integration

After APM Good teamwork, 200% productivity increase, improved quality, fewer defects

Lessons Learned Agile improves customer satisfaction/communication, and overall product quality

Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project.
Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii, USA, 464-473.
184

Agenda
Agile Automated Testing  Agile Summary

Agile Myths
 Common myths still abound, although agile methods
have been around for ~20 years
 Agile methods are only good for rapid prototypes
 Agile methods are only for software development
 Agile methods are only for small co-located teams
 Agile methods have no requirements or documents
 Agile methods need traditional system architectures
 Agile methods have no project management model
 Agile methods are undisciplined and unmeasurable
 Agile methods create unmaintainable systems
 Agile methods result in security vulnerabilities
 Agile methods mean deliver it fast and fix it later
186

Advanced Agile Measures
 Agile Methods are a fundamentally new paradigm
 Agile Methods are “not” lighter Traditional Methods
 They should not be viewed through a traditional lens

Traditional Metrics
Customer Collaboration Contracts
 Frequent comm.  Multiple comm. channels valued  Contract compliance
 Close proximity  Frequent feedback more than  Contract deliverables
Agile Metrics

 Regular meetings  Relationship strength  Contract change orders

Individuals & Interactions Processes
 Leadership  Competence valued  Lifecycle compliance
 Boundaries  Structure more than  Process Maturity Level
 Empowerment  Manageability/Motivation  Regulatory compliance

Working Software Documentation
 Clear objectives  Short/timeboxed durations valued  Document deliveries
 Small/feasible scope  Valid operational results more than  Document comments
 Acceptance criteria  Regular cadence/intervals  Document compliance

Responding to Change Project Plans
 Org. flexibility  System flexibility valued  Cost Compliance
 Mgt. flexibility  Technology flexibility more than  Scope Compliance
 Process flexibility  Infrastructure flexibility  Schedule Compliance

187

Agile User Experience Design
 User experience is key ingredient to success
 UX should be included throughout agile life cycle
 UX involves end to end product & service experience
Product Owner Agile UX Development

Define Product Vision & Define Build Build
Strategy User Needs User Experience Product

 Competitive Analysis  User Interviews  GUI Implementation  Front End Code
 Define Feature Set  Contextual Inquiry  Core Capabilities  Back End Code
 Quantify Business Value  User Flows  Core Services  Database Schema
 Prioritization  Wireframes & Mockups  Value Adding Capabilities  Technology Selection
 Define Business Rules  Prototyping  Value Adding Services  Usability Testing
 Pricing & Budgeting  Usability Testing  Distributed Framework  User Experience Testing
 Project Accountability  Web Metrics Analysis  Central Framework  Market Testing
 Partnerships & Licensing  User Feedback  Support Services  Overall Product Evaluation

Johnson, J. D. (2010). Agile UX retreat: We should value competencies over roles. Retrieved April 22, 2011 from http://www.jeremydjohnson.com/index.php/2010/03
Kollmann, J., Sharp, H., & Blandford, A. (2009). The importance of identity and vision to user experience designers on agile projects. Proceedings of the Agile 2009
Conference, Chicago, Illinois, USA, 11-18. 188

Conclusion
 Agility is the evolution of management thought
 Confluence of traditional and non-traditional ideas
 Improve performance by over an order-of-magnitude
Agile methods are …
 Systems development approaches
 New product development approaches
 Expertly designed to be fast and efficient
 Intentionally lean and free of waste (muda)
 Systematic highly-disciplined approaches
 Capable of producing high quality systems
 Right-sized, just-enough, and just-in-time tools
 Scalable to large, complex mission-critical systems
 Designed to maximize business value for customers

“The world of traditional methods belongs to yesterday”
“Don’t waste your time using traditional methods on 21st century projects”
189

Agenda
Agile Security Engineering  Agile Resources 190

Intros to Agile Methods
 Term agile methods coined around 2001
 Earliest holistic text books emerged in 2002
 Highsmith, Shore, & Cockburn most complete

Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
Shore, J., & Warden, S. (2008). The art of agile development. Sebastopol, CA: O'Reilly.
Subramaniam, V., & Hunt, A. (2006). Practices of an agile developer. Raleigh, NC: Pragmatic Bookshelf.
Cockburn, A. (2007). Agile software development: The cooperative game. Boston, MA: Pearson Education.
Martin, R. C. (3003). Agile software development: Principles, patterns, and practices. Upper Saddle River, NJ: Pearson.
191

 Over 15 text books for agile project management
 Many of them stem from Planning XP by Kent Beck
 Agile Project Mgt. by Jim Highsmith is most complete

Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education.
192

Agile Development
 100s of agile methods books exist for all disciplines
 Range from requirements through documentation
 Thwart notion that agile methods have big gaps

Coplien, J. O., & Bjornvig, G. (2010). Lean architecture: For agile software development. West Sussex, UK: John Wiley & Sons.
Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall.
Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Boston, MA: Addison-Wesley.
Ruping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, UK: John Wiley & Sons.
193

Scaling Agile Methods
 Scaling is the last frontier in agile methods research
 Many of them stem from Planning XP by Kent Beck
 Meta models of agile project mgt. address scaling

Eckstein, J. (2004). Agile software development in the large: Diving into the deep. New York, NY: Dorset House..
Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.
Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press.
Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.
Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.
194

Agile Specialty Topics
 Agile Methods are applied to many domains
 Include CMMI, CM, QA, Offshoring, Games Dev.
 Agile-CMMI textbooks are the newest phenomenon

McMahon, P. E. (2010). Integrating CMMI and agile development: Case studies and proven techniques for faster performance improvement. Boston, MA: Addison-Wesley.
Moreira, M. E. (2009). Adapting configuration management for agile teams: Balancing sustainability and speed. New York, NY: John Wiley.
Stamelos, J. G., & Sfetsos, P. (2007). Agile software development quality assurance. Hershey, PA: Idea Group.
Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed scrum. Indianapolis, IN: IBM Press.
Clinton, K. (2010). Agile game development with scrum. Boston, MA: Addison-Wesley.
195

A 3-Day Introduction for Sr. Engineers and Tech. Support Staff

More Related Content

Viewers also liked (9)

Similar to A 3-Day Introduction for Sr. Engineers and Tech. Support Staff (20)

More from David Rico (20)

A 3-Day Introduction for Sr. Engineers and Tech. Support Staff