Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
Lean & AgileProject Management
- Simplified -Leading Large Programs & Projects
Dr. David F. Rico, PMP, CSEP, ACP, CSM, SAFe
Twitter: @dr_david_f_ricoWebsite: http://www.davidfrico.com
LinkedIn: http://www.linkedin.com/in/davidfricoFacebook: http://www.facebook.com/profile.php?id=1540017424
Dave’s Agile Resources: http://www.davidfrico.com/daves-agile-resources.htm
Agenda
2
• Introduction• Models
• Stories
• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
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 BUSINESS VALUE with right sized, just-
enough, and just-in-time processes and documentationHighsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.
3
What are Agile Methods?
4
People-centric way to create innovative solutions Product-centric alternative to documents/process Market-centric model to maximize business value
Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.orgRico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.Rico, D. F. (2012). Agile conceptual model. Retrieved February 6, 2012, from http://davidfrico.com/agile-concept-model-1.pdf
Customer Collaboration
Working Software
Individuals & Interactions
Responding to Change
valuedmore than
valuedmore than
valuedmore than
valuedmore than
Contracts
Documentation
Processes
Project Plans
Frequent comm. Close proximity Regular meetings
Multiple comm. channels Frequent feedback Relationship strength
Leadership Boundaries Empowerment
Competence Structure Manageability/Motivation
Clear objectives Small/feasible scope Acceptance criteria
Timeboxed iterations Valid operational results Regular cadence/intervals
Org. flexibility Mgt. flexibility Process flexibility
System flexibility Technology flexibility Infrastructure flexibility
Contract compliance Contract deliverables Contract change orders
Lifecycle compliance Process Maturity Level Regulatory compliance
Document deliveries Document comments Document compliance
Cost Compliance Scope Compliance Schedule Compliance
NetworkComputer
Operating SystemMiddlewareApplications
APIsGUI
How Agile Works Agile requirements implemented in slices vs. layers User needs with higher business value are done first Reduces cost & risk while increasing business success
5Shore, J. (2011). Evolutionary design illustrated. Norwegian Developers Conference, Oslo, Norway.
Agile Traditional1 2 3 Faster
Early ROI
Lower Costs
Fewer Defects
Manageable Risk
Better Performance
Smaller Attack Surface
Late
No Value
Cost Overruns
Very Poor Quality
Uncontrollable Risk
Slowest Performance
More Security Incidents Seven Wastes1.Rework2.Motion3.Waiting4.Inventory5 .Transportation6.Overprocessing7 .Overproduction
MINIMIZES MAXIMIZES
JIT, Just-enough architecture Early, in-process system V&V Fast continuous improvement Scalable to systems of systems Maximizes successful outcomes
Myth of perfect architecture Late big-bang integration tests Year long improvement cycles Breaks down on large projects Undermines business success
Thousands of TestsContinuously Executed
No More Late BigBang Integration
Agile Development Model User needs designed & developed one-at-a-time Changes automatically detected, built, and tested System fully tested and deployed as changes occur
6Humble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration. Boston, MA: Addison-Wesley.
BuildIntegration
Server
VersionControlServer
BuildScripts
UsesWatches
BuildStatus
ProvidesDeveloper A
Developer B
Developer C
CommitsChanges
CommitsChanges
CommitsChanges
Builds
Database
Analysis
Testing
Reporting
Documentation
Deployment
Early, Automated, Fast,Efficient, & Repeatable
Constant ReadinessState & CM Control
Lean, Waste Free, Low WIP,No Deadlocked Test Queues
Rapidly & SuccessfullyDev. Complex Systems
Org. system needs into capabilities, features, user stories Prioritize features, group into releases, and start sprints Develop minimum set of features with highest value
7
Capability/MMF #1
●Feature 1●Feature 2●Feature 3●Feature 4●Feature 5●Feature 6●Feature 7
Capability/MMF #2
●Feature 8●Feature 9●Feature 10●Feature 11●Feature 12●Feature 13●Feature 14
Capability/MMF #3
●Feature 15●Feature 16●Feature 17●Feature 18●Feature 19●Feature 20●Feature 21
Capability/MMF #4
●Feature 22●Feature 23●Feature 24●Feature 25●Feature 26●Feature 27●Feature 28
Capability/MMF #5
●Feature 29●Feature 30●Feature 31●Feature 32●Feature 33●Feature 34●Feature 35
Capability/MMF #6
●Feature 36●Feature 37●Feature 38●Feature 39●Feature 40●Feature 41●Feature 42
Capability/MMF #7
●Feature 43●Feature 44●Feature 45●Feature 46●Feature 47●Feature 48●Feature 49
Evolving “Unified/Integrated” Enterprise Data Model
“Disparate” LEGACY SYSTEM DATABASES (AND DATA MODELS)
ETL
A
“Legacy” MS SQL Server Stovepipes “Inter-Departmental” Linux Blade/Oracle/Java/WebSphere Server
“Leased” DWA/HPC/Cloud Services
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
Release
Release
Release
Release
ETL ETL ETL ETL ETL ETL
Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture: Enriching EA with lean, agile, and enterprise 2.0 practices. Waltham, MA: Elsevier.
Agile Development In-the-Large“Incremental Business Value”
(for example, assume 25 user stories per feature, 175 user stories per capability/MMF, and 1,225 user stories total)
What is Agile Project Mgt.? A-P-M (ā-pē-ĕm): Light, flexible, collaborative, and
adaptive; Market-centric project management model: Sound, yet flexible process to manage projects under
uncertainty, urgency, and a need for unique expertise Values, principles, and practices to help project teams
in coming to grips with a challenging environment Managing the flow of human thoughts, emotions, and
interactions in a way that produces business value Rapidly and reliably creating value by engaging
customers, continuously learning, and adapting Lightweight, yet disciplined project management model
for building high-quality technology-intensive systemsAugustine, 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. 8
DOI. (2005). Declaration of interdependence. Retrieved April 8, 2014, from http://www.pmdoi.org 9
Declaration of Interdependence formed in 2005 Carved out a niche for agile project managers Focus on Agile Methods, ROI, and culture
Declaration of Interdependence
•We increase ROI by making continuous flow of value our focus.•We deliver reliable results by engaging customers in frequent interactions and shared ownership. •We expect uncertainty and manage for it through iterations, anticipation, and adaptation. •We unleash creativity and innovation by recognizing that individuals are the ultimate source of value•We create an environment where people can make a difference. •We boost performance through group accountability for results and shared responsibility for team effectiveness. •We improve effectiveness and reliability through situationally specific strategies, processes and practices.
Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.Rico, D. F. (2012). Agile vs. traditional projects. Retrieved February 6, 2013, from http://davidfrico.com/tpm-vs-apm-ii.pdf
Agile Project Management
High levels of uncertainty and unpredictability
High technology projects
Fast paced, highly competitive industries
Rapid pace of technological change
Research oriented, discovery projects
Large fluctuations in project performance
Shorter term, performance based RDT&E contracts
Achieving high impact product/service effectiveness
Highly creative new product development contracts
Customer intensive, one off product/service solutions
Highly volatile and unstable market conditions
High margin, intellectually intensive industries
Delivering value at the point of sale
Traditional Project Management
Predictable situations
Low technology projects
Stable, slow moving industries
Low levels of technological change
Repeatable operations
Low rates of changing project performance
Long term, fixed price production contracts
Achieving concise economic efficiency goals
Highly administrative contracts
Mass production and high volume manufacturing
Highly predictable and stable market conditions
Low margin industries such as commodities
Delivering value at the point of plan
10
Exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly innovative/creative
When to use Agile Project Mgt.?
Agenda
11
• Introduction
• Models• Stories
• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
Models of Agile Project Mgt.
12
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Augustine, S. (2008). Certified scrum master training: Not just how, buy why. Herndon, VA: LitheSpeed.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.
Scrum- 1994 -
XP- 1998 -
XP-Scrum- 2008 -
Adaptive- 2010 -
APM- 2010 -
sAPM- 2011 -
Product BL
Sprint BL
Sprints
Daily standup
Sprint Review
Retrospective
User stories
Estimating
Release plan
Iteration plan
Task plan
Iterating
Release plan
Sprint plan
Sprinting
Daily standup
Sprint review
Retrospective
Scoping
Planning
Feasibility
Cyclical dev.
Checkpoint
Review
Envision
Speculate
Explore
Iteration
Launch
Close
Vision
Roadmap
Release plan
Sprint plan
Daily Scrum
Review-Retro
Dozens of Agile project management models emerged Stem from XP, Scrum, and new product development Vision, release, iteration, and learning are common
Scrum
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.
Created by Jeff Sutherland at Easel in 1993 Product backlog comprised of needed features Sprint-to-sprint, iterative, adaptive emergent model
13
Extreme Programming
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
Created by Kent Beck at Chrysler in 1998 Release plan is comprised of customer needs Lightweight, rigorous near-term planning element
14
UserStories
ArchitecturalSpike
ReleasePlanning Iteration Acceptance
TestsSmall
Releases
Spike
TestScenarios
SystemMetaphor
CustomerApproval
LatestVersion
ReleasePlan
NextIteration
BugsNewStoriesRequirements
UncertainEstimates
ConfidentEstimates
Scrum-XP Hybrid
Augustine, S. (2008). Certified scrum master training: Not just how, buy why. Herndon, VA: LitheSpeed.
Created by Sanjiv Augustine of Lithespeed in 2008 Release planning used to create product backlog Extends Scrum beyond Sprint-to-sprint planning
Initial Planning Sprint Cycle
Discovery Session
Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog
Release Planning
Business Case Desired Backlog Hi-Level Estimates Prioritize Backlog Finalize Backlog
Product Backlog
Prioritized Requirements
Sprint Planning
Set Sprint Capacity Identify Tasks Estimate Tasks
Sprint Review
Present Backlog Items Record Feedback Adjust Backlog
Daily Scrum
Completed Backlog Items Planned Backlog Items Impediments to Progress
Sprint Backlog
List of Technical Tasks Assigned to a Sprint
Potentially Shippable Product
Working Operational Software
Sprint
Select Tasks and Create Tests Create Simple Designs Code and Test Software Units Perform Integration Testing Maintain Daily Burndown Chart Update Sprint Backlog
Sprint Retrospective
15
Adaptive Project Framework
Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.
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
Identify Opportunity Develop CoS Write PoS Document Needs Stage Gate 1 Review
Planning
Identify Project Type Prioritize Constraints Develop WBS Team Formation Stage Gate 2 Review
Feasibility
Develop Prototype Reprioritize Needs Detailed WBS Estimate Resources Stage Gate 3 Review
Checkpoint
Analyze Needs Evaluation Solution Estimate Value Determine Success Stage Gate 4 Review
Review
Finalize Documents Lessons Learned Process Changes Final Report Stage Gate 5 Review
Cyclical Product or Service Implementation
Cycle Planning
Responsibilities Timelines Work Packages Communications Governance
Continually improve process, documents, team, architecture, designs, implementation, tests, etc.Stage Gate 3.n
Review
Cycle Reviews
Update Requirements Update Scope Update Schedules Update Plans Inform Stakeholders
Daily Meetings
Arrange Facilities Prepare Agendas Send Meeting Notices Facilitate Meetings Record Action Items
Product or Service Implementation
Select Personnel with Needed Skills Identify Detailed Technical Tasks Create Detailed Architectures and Designs Select and Implement Technical Solutions Perform Development and Operational Tests
Continuous Improvement
16
Agile Project Management
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Created by Jim Highsmith of Cutter in 2010 Front-end visions and architectures and final QA Light project model wrapped around agile practices
Innovation Lifecycle
Envision
Product Vision Product Architecture Project Objectives Project Community Delivery Approach
Speculate
Gather Requirements Product Backlog Release Planning Risk Planning Cost Estimation
Explore
Iteration Management Technical Practices Team Development Team Decisions Collaboration
Launch
Final Review Final Acceptance Final QA Final Documentation Final Deployment
Close
Clean Up Open Items Support Material Final Retrospective Final Reports Project Celebration
Iterative Delivery
Technical Planning
Story Analysis Task Development Task Estimation Task Splitting Task Planning
Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and IntegrationStory Deployment
Adapt
Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive Action
Operational Testing
Integration Testing System Testing Operational Testing Usability Testing Acceptance Testing
Development, Test, & Evaluation
Development Pairing Unit Test Development Simple Designs Coding and Refactoring Unit and Component Testing
Continuous
17
Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.
Created by Mark Layton at PlatinumEdge in 2012 Mix of new product development, XP, and Scrum Simple codification of common XP-Scrum hybrid
18
Agile Project Management“Simplified”
Agenda
19
• Introduction
• Models
• Stories• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
User Story
Beck, K., & Fowler, M. (2004). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.
A function or feature of value to a customer An estimable and testable software requirement 7 to 15 stories should be implemented per iteration
20
User Story Examples
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
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
21
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
22Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
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
23Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
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
24Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
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
25Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.
Agenda
26
• Introduction
• Models
• Stories
• Phases• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
Process Steps
1. Develop product objective.
2. Create draft vision statement.
3. Validate and revise vision statement.
4. Finalize vision statement.
Stage 1—Vision Description. Product goals aligned with strategy Owner. Product Owner Frequency. At least annually [1-2 hours]
27
Product owner identifies product vision. Vision is project's destination. It defines what product is, how it supports organization strategy, who will use it, and why people will use it.
Vision
Example
• For. <target customer>• Who. <needs it>• The. <product name>• Is a. <product category>• That. <product benefit, reason to buy>• Unlike. <competitors>• Our product. <differentiator, value added>
• For. Bank customers• Who. Want mobile banking• The. Mobile banking application• Is a. Mobile device enable banking app• That. Provides secure, 24x7 mobile banking• Unlike. Brick-and-mortar access points• Our product. Enable 24-hour a day services
Stage 2—Product Roadmap Description. Holistic view of product features Owner. Product Owner Frequency. At least biannually [2-4 hours]
28
Process Steps
1. Identify product features.
2. Arrange product features.
3. Estimate and order product features.
4. Determine high-level time frames.
Product owner creates product roadmap. Roadmap is high-level view of product requirements with loose timeframe for development. Identify, estimate, valuate, prioritize, and schedule themes.
Features
Roadmap
Account• Open acct.• Modify acct.• Close acct.
Transaction• Deposit• Withdrawal• Transfer
Status• Login• Balances• Statements
1Q 2Q 3Q 4Q 5Q
Transaction
Status
Account
Stage 3—Release Planning Description. Release timing for product functions Owner. Product Owner Frequency. At least quarterly [4-8 hours]
29
Process Steps
1. Decompose product features.
2. Create release plan.
Establish release goal.
Prioritize or order user stories.
Set release date.
Refine user stories.
Verify release plan.
Product owner creates release plan. Release plan identifies high-level timetable for releasing functions. Mid-term goals that team mobilizes around. There are many releases in priority order.
Decomposition
Release Plan
Account
ModifyOpen Close
• Create• Login• Setup
• Password• Address• Type
• Notify• Refund• Rationale
Sprint 1 Sprint 2 Sprint 3 Release 1
• Story 1
• Story 11
• Story 1
• Story 11
• Story 1
• Story 11
• Story 1
• Story 11
Stage 4—Sprint Planning Description. Specific iteration goals and tasks Owner. Product Owner and Development Team Frequency. At the start of each sprint [2-4 hours]
30
Process Steps
1. Establish goals and choose user stories.
2. Decompose stories into tasks and create sprint backlog.
Product owner, Scrum Master, and Developers create sprint plan. Sprint planning done at start of sprint. Product backlog must be ready. Developers select sprint goal and what can be done.
Goals & User Stories
Sprint Backlog
As a mobile banking customer, I want to create an account so I can write personal checks
• Create account.• Login to account.• Setup checking account.
Task Pri Status Who App. M T W T F
• Create account: Setup 1 Done Sue Joe 4 4 0 0 0 Install 2 Done Sue Joe 4 4 0 0 0 Schema 3 Done John Joe 0 0 8 0 0 Queries 4 In-work Bob - 0 0 0 8 0 Forms 5 N/S Patty - 0 0 0 0 0 Test 6 N/S Sam - 0 0 0 0 0
Stage 5—Daily Scrum Description. Establish & coordinate daily priorities Owner. Development Team Frequency. Daily [15-minutes]
31
Developers hold daily standup meetings. Purpose is to coordinate daily priorities. Identify what was done, what will be done, and impediments. Task boards and Sprint burndown are updated.
Daily Standup
Sprint Burndown
Process Steps
1. Hold daily standup meeting.
2. Update sprint burndown chart.
3. Perform design, development, test, and evaluation.
All Developers on Team Answer Three Questions in Round-Robin Style
• What has been done since the last meeting?• What will be done before the next meeting?• What obstacles are in my way?
Stage 6—Sprint Review Description. Demonstration of working product Owner. Product Owner and Development Team Frequency. At the end of each sprint [2-4 hours]
32
Process Steps
1. Prepare sprint review meeting.
2. Hold sprint review meeting.
3. Collect feedback from stakeholders.
Developers hold a sprint review. Sprint review performed at end of sprint. Developers demo validated code to stakeholders. Stakeholders vote on demo outcome. Product backlog reprioritized.
Product Demonstration
Stakeholder Feedback
Developers Perform a Live Demo Target Hardware and Answer Stakeholder Questions
• What was the goal of the sprint?• What user stories were attempted?• What user stories were implemented?
Poll Stakeholders One-by-One in Round-Robin Style to Solicit their Feedback
• Is the product acceptable as implemented?• Is the product acceptable with modifications?• Is the product unacceptable as implemented?
Stage 7—Sprint Retrospective Description. Refine environment and processes Owner. Development Team Frequency. At the end of each sprint [1-2 hours]
33
Process Steps
1. Plan sprint retrospective meeting.
2. Hold sprint retrospective meeting.
3. Inspect and adapt.
Developers hold sprint retrospective. Retrospective held at end of sprint. Developers identify the good and bad. Scrum master records results. Processes, tools, and backlog may be adjusted.
Sprint Retrospective
Process Improvements
Developers Perform a Live Demo Target Hardware and Answer Stakeholder Questions
• What went well in the last sprint?• What could be improved in the next sprint?• What people, process, and tools should change?
Scrum Master Records Action Items and Prepares Process Improvement Plan
• Scrum master records suggested improvements.• Developers prioritize suggested improvements.• Add high-priority non-functional items to backlog.
Agenda
34
• Introduction
• Models
• Stories
• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
Multi-Level Teams
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables projects to plan for the future and present Decomposes capabilities into implementable pieces Unclogs the drainpipes to let the execution flow freely
Multi-Level Teams
Product Management Team Product Management Team
Chief Product Manager Chief Architect Product Development Manager Release Management Team members (1-2 per release team)
Release Management Team
Feature Team
Release Management Team
Product Manager Project Manager Chief Architect Feature team members (1-2 per feature team)
Feature Teams
Product Specialist (and owner) Iteration Manager Technical and product Members Development team members (1-2 per development team)
35
Multi-Level Planning
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables multiple level enterprise plans to co-exist Allows stakeholders to build viewpoint-specific plans Ensures capabilities are delivered at regular intervals
Multi-Level Planning
Product Roadmap Product Roadmap
Enterprise architecture needs Capability focused Vision, objectives, and backlog 18 to 36 weeks
Release Plan
Iteration Plan
Release Plan
Subsystem architecture Feature set focused Strategy, objectives, and backlog 6 to 12 weeks
Iteration Plan
Component-level architecture User story focused Implementation plan, objectives, and backlog 2 to 4 weeks
36
Multi-Level Backlog
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables multiple levels of abstraction to co-exist Allows customers and developers to communicate Makes optimum use of people’s time and resources
Multi-Level Backlog
Capabilities Capability
Mission goal or objective level High-level business or product function Also called an Epic, i.e., multiple feature sets Comprises 18-90 days worth of work
Feature Set
Cross-functional mission threads Related user stories that are grouped together Also called a Theme, i.e., implemented as an entity Comprises 6 to 30 days worth of work
User Story
Functional, system-level requirements Simple requirement written by customer or user A small unit of functionality having business value Comprises 2 to 10 days worth of work
Capability1
Capability2
Capability3
Feature Sets
Feature1
Feature2
Feature3
User Stories
Story 1 Story 4 Story 7
Story 2 Story 5 Story 8
Story 3 Story 6 Story 9
37
Multi-Level Coordination
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables lean and agile methods to scale-up Allows enterprises to create large-scale programs Unleashes optimum productivity and overall control
38
Multi-Level Coordination & Governance
User Story Teams User Story Teams User Story Teams
Feature Set Team
Capability Team
Feature Set Team Feature Set Team
Multi-Level Governance
Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.
Enables enterprises to achieve functional needs Allows programs to coordinate functional activities Ensures optimal technical performance is achieved
Multi-Level Governance
Feature Team Feature Team Feature Team
Functional Team
Governing Team
Functional Team Functional Team
R T S
RRR
RRR
RRR
TTT
TTT
TTT
SSS
SSS
SSS
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
QIR
TA
SCD
M M M
M M
M M M
M
M M M
M M M
M M M
M M M
M M M
M M M
39
Value Stream Mapping
40Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.
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
Agenda
41
• Introduction
• Models
• Stories
• Phases
• Scaling
• Portfolio• Metrics
• Tools
• Leading
• Summary
Agile Enterprise Frameworks
42
Dozens of Agile enterprise frameworks have emerged Many stem from principles of Extreme Programming All include product, project, & team management
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press.Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education.Thompson, K. (2013). cPrime’s R.A.G.E. is unleashed: Agile leaders rejoice! Retrieved March 28, 2014, from http://www.cprime.com/tag/agile-governanceHumble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.
eScrum- 2007 -
SAFe- 2007 -
LeSS- 2007 -
DaD- 2007 -
RAGE- 2012 -
eCD- 2011 -
Product Mgt
Program Mgt
Project Mgt
Process Mgt
Business Mgt
Market Mgt
Strategic Mgt
Portfolio Mgt
Program Mgt
Team Mgt
Quality Mgt
Delivery Mgt
Business Mgt
Portfolio Mgt
Product Mgt
Area Mgt
Sprint Mgt
Release Mgt
Business Mgt
Portfolio Mgt
Inception
Construction
Iterations
Transition
Business
Governance
Portfolio
Program
Project
Delivery
Source Ctrl
Build Auto
Test Auto
Cont Integ
Release Auto
Cont Deploy
Enterprise Scrum (eScrum)
Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press.
Created by Ken Schwaber of Scrum Alliance in 2007 Application of Scrum at any place in the enterprise Basic Scrum with extensive Backlog grooming
43
Scaled Agile Framework (SAFe) Created by Dean Leffingwell of Rally in 2007 Knowledge to scale agile practices to enterprise Hybrid of Kanban, XP release planning, and Scrum
44Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.
Large Scale Scrum (LeSS) Created by Craig Larman of Valtech in 2008 Scrum for larger projects of 500 to 1,500 people Model to nest product owners, backlogs, and teams
45Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.
Product Owner
Product Backlog
Area Product Owner
Area Product Backlog
SprintBacklog
Daily Scrum15 minutes
Product Backlog Refinement5 - 10% of Sprint
2 - 4 Week Sprint
1 DayFeature Team +Scrum Master
Sprint Planning II2 - 4 hours
SprintPlanning I2 - 4 hours
Potentially ShippableProduct Increment
SprintReview
JointSprint
Review
Sprint Retrospective
Disciplined Agile Delivery (DaD) Created by Scott Ambler of IBM in 2012 People, learning-centric hybrid agile IT delivery Scrum mapping to a model-driven RUP framework
46Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education.
Recipes for Agile Governance (RAGE) Created by Kevin Thompson of cPrime in 2013 Agile governance model for large Scrum projects Traditional-agile hybrid of portfolio-project planning
47Thompson, K. (2013). cPrime’s R.A.G.E. is unleashed: Agile leaders rejoice. Retrieved March 28, 2014, from http://www.cprime.com/tag/agile-governance
Enterprise Continuous Delivery Created by Jez Humble of ThoughtWorks in 2011 Includes CM, build, testing, integration, release, etc. Goal is “one-touch” automation of deployment pipeline
48
Humble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration. Boston, MA: Addison-Wesley. Ohara, D. (2012). Continuous delivery and the world of devops. San Francisco, CA: GigaOM Pro.
Agenda
49
• Introduction
• Models
• Stories
• Phases
• Scaling
• Portfolio
• Metrics• Tools
• Leading
• Summary
50
Agile Performance MeasurementW
ork
(Sto
ry, P
oint
, Tas
k)or
Eff
ort
(Wee
k, D
ay, H
our)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Burndown
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Cumulative Flow
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Earned Value Management - EVMCPI
SPI
PPC
APC
Wor
k (S
tory
, Poi
nt, T
ask)
or E
ffor
t (W
eek,
Day
, Hou
r)
Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)
Earned Business Value - EBV
Agile Metrics Taxonomy Agile methods are based on traditional measures Story points, velocity, and burndown basic metrics Experts use Agile EVM, portfolio, contract, ent., etc.
51Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.
Agile Metrics
1. Traditional Metrics
2. Basic Agile Metrics
3. Agile EVM Metrics
Size Effort Productivity Quality Complexity Cycle Time
Story Points Ideal Days Velocity Burndown Cumulative Flow Running Tested Features
Planned Story Points Planned Sprints Planned Release Budget Completed Story Points Completed Sprints Completed Releases
4. Agile Portfolio Metrics
5. Agile Contract Metrics
6. Agile Enterprise Metrics
Benefit-Cost Ratio Return on Investment Net Present Value Breakeven Point Real Options Earned Business Value
Level of Effort Dynamic Value Performance Based Target Cost Optional Scope Collaborative
Relationships Communications Collaboration Motivation Creativity Satisfaction
0. “No Metrics”1. Traditional Metrics2. Basic Agile Metrics3. Agile EVM Metrics4. Agile Portfolio Metrics5. Agile Contract Metrics6. Agile Enterprise Metrics
Agile Testing Metrics Agile testing also based on traditional metrics Agile testing measures include basic volumetrics Key metrics are RTF, code coverage, complexity, etc.
52Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.
Volumetrics Number of lines of code Number of function points Number of story points Number of user stories Number of features Number of epics Number of capabilities Number of MMFs
Code CoverageRunning Tested Code
Defect DensityCode Complexity
Running tested epics Running tested features Running tested releases Running tested iterations Running tested builds Running tested user stories
Epic coverage Feature coverage Release coverage Iteration coverage Build coverage Statement coverage Function coverage Other coverage types
Epic complexity Feature complexity Release complexity Iteration complexity Build complexity Cyclomatic complexity Actual complexity Other complexity types
Defects per epic Defects per feature Defects per release Defects per iteration Defects per build Defects per user story Defects per story point Defects per other types
Continuous IntegrationBuild number and durationDatabase number and durationInspection number and durationTest number and durationFeedback number and duration
Document number and durationDeployment number and duration
Agile Testing ROI at Google Google early adopter of agile methods and Scrum Google also uses agile testing at enterprise scale 15,000 developers run 120 million tests per day
53Micco, J. (2013). Continuous integration at google scale. Eclipse Con, Boston, MA.Whittaker, J., Arbon, J., & Carollo, J. (2012). How google tests software. Upper Saddle River, NJ: Pearson Education. Kumar, A. (2010). Development at the speed and scale of google. International Software Development Conference (QCon 2010), San Francisco, CA.
15,000+ developers & 4,000 projects in 40+ offices Single monolithic code tree with mixed language code Submissions at head – One branch – All from source 20+ code changes/minute – 50% code change/month 5,500+ submissions/day – 120 million tests/day 80,000 builds per day – 20 million builds per year Automatic code inspections – For low defect density 10X programming productivity improvement $150 million in annual labor savings (ROI as a result)
Agenda
54
• Introduction• Models• Stories• Phases• Scaling
• Portfolio• Metrics• Tools• Leading• Summary
APM Tool Variety
55VersionOne. (2010). 5th annual state of agile survey. Atlanta, GA: Author.Allen, W. (2008). Agile PM tools (hosted). Retrieved May 11, 2011 from http://weblogs.asp.net/wallen
There are literally dozens, if not 100s of APM tools There are dozens of free open source software tools Annual tool & price surveys are frequently conducted
Enables enterprises to be flexible but disciplined Allows enterprises to distribute project work teams Ensures distributed project teams are collaborating
56
Agile Tools“Across the Life Cycle”
Project Management
RequirementsDOORSRequisite ProSLATE
DesignRhapsodyTelelogic System ArchitectRational System Architect
CodingEclipseVisual StudioSun Studio
TestingJUnitNUnitXunitCPPUnit
GtestFitFitnesseSelenium
Quality AssuranceCheckStylePMDEMMAJdependCoberturaGcov
Configuration MgtSubversion (SVN)Concurrent Versions Sys.ClearCase
Build AutomationAntNAntMavenMake
Continuous Integ.Cruise ControlHudsonBuildBot
CollaborationWebExSkypeMeetMeWimba
WikiMediaWikiTracWikiPhpWiki
DocumentationNDocJavadocDoxygeniText
Version OneRallyScrum WorksVSTS
Agile TeamAgile EnterpriseScope ManagerStory Studio
XP Plan ItIterateXP TrackerAgilo
XP CGIXP WebXplannerIce Scrum
Project CardsTarget ProcessXtreme PlannerTeam System
CommunityEnterpriseMingleHansoft
There are literally hundreds of agile testing tools There are tools for building, testing, and deploying Integration tools monitor repositories and initiate tests
57
Agile Tools“In-Depth Test Automation”
Smart, J. (2009). Automated deployment with maven and friends: Going the whole nine yards. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.
Agenda
58
• Introduction
• Models
• Stories
• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading• Summary
Agile World View “Agility” has many dimensions other than IT It ranges from leadership to technological agility The focus of this brief is program management agility
Agile Leaders
Agile Organization Change
Agile Acquisition & Contracting
Agile Strategic Planning
Agile Capability Analysis
Agile Program Management
Agile Tech.
Agile Information Systems
Agile Tools
Agile Processes & Practices
Agile Systems Development
Agile Project Management
59
Agile Leadership
Rico, D. F. (2013). Agile coaching in high-conflict environments. Retrieved April 11, 2013 from http://davidfrico.com/agile-conflict-mgt.pdfRico, D. F. (2013). Agile project management for virtual distributed teams. Retrieved July 29, 2013 from http://www.davidfrico.com/rico13m.pdfRico, D. F. (2013). Agile vs. traditional contract manifesto. Retrieved March 28, 2013 from http://www.davidfrico.com/agile-vs-trad-contract-manifesto.pdf 60
Personal Project Enterprise
• Don't Be a Know-it-All• Be Open & Willing to Learn• Treat People Respectfully• Be Gracious, Humble, & Kind• Listen & Be Slow-to-Speak• Be Patient & Longsuffering• Be Objective & Dispassionate• Don't Micromanage & Direct• Exhibit Maturity & Composure• Don't Escalate or Exacerbate• Don't Gossip or be Negative• Delegate, Empower, & Trust• Gently Coach, Guide, & Lead
• Customer Communication• Product Visioning• Distribution Strategy• Team Development• Standards & Practices• Telecom Infrastructure• Development Tools• High-Context Meetings• Coordination & Governance• F2F Communications• Consensus Based Decisions• Performance Management• Personal Development
• Business Value vs. Scope• Interactions vs. Contracts• Relationship vs. Regulation• Conversation vs. Negotiation• Consensus vs. Dictatorship• Collaboration vs. Control• Openness vs. Adversarialism• Exploration vs. Planning• Incremental vs. All Inclusive• Entrepreneurial vs. Managerial• Creativity vs. Constraints• Satisfaction vs. Compliance• Quality vs. Quantity
Power & authority delegated to the lowest level Tap into the creative nuclear power of team’s talent Coaching, communication, and relationships key skills
Agile Leadership Model
Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.
Guiding Vision Simple Rules Open Information Light Touch
Foster Alignment and Cooperation Encourage Emergence and Self Organization
Adaptive Leadership
Learning/Adaptation
Leadership
Team Vision Team Alignment Bold Future Shared Expectations
Management
Business Outcomes Delineate Scope Estimate Effort Design Vision Box Elevator Statement
Leadership
Culture of Change Value Focus
Management
Assess Status Quo Customize Method Release Plan Iteration Plans Facilitate Design Conduct Testing Manage Releases
Leadership
Conduct Standups Promote Feedback Build Trust Facilitate Action
Management
Team Collocation Get Onsite Customer Practice Pairing Information Radiator Map Value Stream
Leadership
Adapt Style Roving Leadership Go With Flow Work Life Quality Build on Strengths Gain Commitments
Management
Decentralize Control Pull vs. Push Manage Flow Use Action Sprints
Leadership
Embodied Presence Embodied Learning
Management
Daily Feedback Monitor/Adapt Rules Monitor Practices Retrospectives Scenario Planning
Organic Teams
Leadership
Craftsmanship Collaboration Guiding Coalition Community
Management
Identify Community Design Structures Get Team Players Adaptive Enterprise
61
Created by Sanjiv Augustine at CC Pace in 2005 Builds agile cultures, mind-sets, & environments Leadership model for managing agile projects
New Agile Contracts Emerging
Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com.Rico, D. F. (2013). Agile vs. traditional contract manifesto. Retrieved March 28, 2013 from http://www.davidfrico.com 62
Dynamic Value Performance Based Target Cost Optional Scope Collaborative
Business & Mission Value OVER Scope, Processes, & Deliverables
Personal Interactions OVER Contract, Auditor, & Legal Interactions
Conversations and Consensus OVER Contract Negotiations & Control
Collaboration & Co-Dependency OVER Methodology & Adversarialism
Exploration, Evolution, & Emergence OVER Forecasting & Control
Early Continuous Quality Solutions OVER Late, Long-Term Deliveries
Entrepreneurialism & Openness OVER Compliance & Self-Interest
Customer Satisfaction and Quality OVER Policies & Governance
Communication, cooperation, and interaction key Shared responsibility vs. blame and adversarialism Needs greater focus on collaboration vs. legal terms
Organizational Change Models
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.Pink, D. H. (2009). Drive: The surprising truth about what motivates us. New York, NY: Riverhead Books.
Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation key factors
63
SWITCH - How to Change Things When Change is Hard
Follow the bright spots Script the critical moves
Point to the destination
Find the feeling
Shrink the change Grow your people
Tweak the environment Build habits
Rally the herd
Direct the Rider
Motivate the Elephant
Shape the Path
INFLUENCER - The Power to Change Anything
Create new experiences Create new motives
Perfect complex skills Build emotional skills
Recruit public personalities Recruit influential leaders
Utilize teamwork Enlist the power of social capital
Use incentives wisely Use punishment sparingly
Make it easy Make it unavoidable
Make the Undesirable Desirable
Surpass your Limits
Harness Peer Pressure
Find Strength in Numbers
Design Rewards & Demand Acct.
Change the Environment
DRIVE - The Surprising Truth About What Motivates Us
Purpose
Autonomy
Mastery
Purpose and profit equality Business and societal benefit Share control of profits Delegate implementation Culture and goal alignment Remake society and globe
Be accountable to someone Self-selected work tasks Self-directed work tasks Self-selected timelines Self-selected teams Self-selected implementation
Experimentation and innovation Align tasks to abilities Continuously improve abilities Elevate learning over profits Create challenging tasks Establish high expectations
Agenda
64
• Introduction
• Models
• Stories
• Phases
• Scaling
• Portfolio
• Metrics
• Tools
• Leading
• Summary
65
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Augustine, S. (2008). Certified scrum master training: Not just how, buy why. Herndon, VA: LitheSpeed.Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.
Scrum- 1994 -
XP- 1998 -
XP-Scrum- 2008 -
Adaptive- 2010 -
APM- 2010 -
sAPM- 2011 -
Product BL
Sprint BL
Sprints
Daily standup
Sprint Review
Retrospective
User stories
Estimating
Release plan
Iteration plan
Task plan
Iterating
Release plan
Sprint plan
Sprinting
Daily standup
Sprint review
Retrospective
Scoping
Planning
Feasibility
Cyclical dev.
Checkpoint
Review
Envision
Speculate
Explore
Iteration
Launch
Close
Vision
Roadmap
Release plan
Sprint plan
Daily Scrum
Review-Retro
Dozens of Agile project management models emerged Stem from XP, Scrum, and new product development Vision, release, iteration, and learning are common
Recap of Agile Project Mgt.
Recap of Agile Ent. Frameworks
66
Dozens of Agile enterprise frameworks have emerged Many stem from principles of Extreme Programming All include product, project, & team management
Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press.Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education.Thompson, K. (2013). cPrime’s R.A.G.E. is unleashed: Agile leaders rejoice! Retrieved March 28, 2014, from http://www.cprime.com/tag/agile-governanceHumble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.
eScrum- 2007 -
SAFe- 2007 -
LeSS- 2007 -
DaD- 2007 -
RAGE- 2012 -
eCD- 2011 -
Product Mgt
Program Mgt
Project Mgt
Process Mgt
Business Mgt
Market Mgt
Strategic Mgt
Portfolio Mgt
Program Mgt
Team Mgt
Quality Mgt
Delivery Mgt
Business Mgt
Portfolio Mgt
Product Mgt
Area Mgt
Sprint Mgt
Release Mgt
Business Mgt
Portfolio Mgt
Inception
Construction
Iterations
Transition
Business
Governance
Portfolio
Program
Project
Delivery
Source Ctrl
Build Auto
Test Auto
Cont Integ
Release Auto
Cont Deploy
Who is Using Agile Methods 84% of worldwide IT projects use agile methods Includes regulated industries, i.e., DoD, FDA, etc. Agile now used for safety critical systems, FBI, etc.
67
Industry
ShrinkWrapped
ElectronicCommerce
HealthCare
LawEnforcement
Org 20 teams 140 people 5 countries
Size
15 teams 90 people Collocated 4 teams 20 people Collocated 10 teams 50 people Collocated 3 teams 12 people Collocated
U.S.DoD
Primavera
Stratcom
FBI
FDA
Project
Primavera
Adwords
SKIweb
Sentinel
m2000
Purpose
ProjectManagement
Advertising
KnowledgeManagement
Case FileWorkflow
BloodAnalysis
1,838 User Stories 6,250 Function Points 500,000 Lines of Code
Metrics
26,809 User Stories 91,146 Function Points 7,291,666 Lines of Code 1,659 User Stories 5,640 Function Points 451,235 Lines of Code 3,947 User Stories 13,419 Function Points 1,073,529 Lines of Code 390 User Stories 1,324 Function Points 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.
Recap of Agile Methods Agile methods DON’T mean deliver it now & fix it later Lightweight, yet disciplined approach to development Reduced cost, risk, & waste while improving quality
68Rico, D. F. (2012). What’s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from http://davidfrico.com/agile-principles.pdfRico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from, http://davidfrico.com/agile-pros-cons.pdfRico, D. F. (2012). How do lean & agile intersect? Retrieved February 6, 2013, from http://davidfrico.com/agile-concept-model-3.pdf
What How ResultFlexibility Use lightweight, yet disciplined processes and artifacts Low work-in-process
Customer Involve customers early and often throughout development Early feedback
Prioritize Identify highest-priority, value-adding business needs Focus resources
Descope Descope complex programs by an order of magnitude Simplify problem
Decompose Divide the remaining scope into smaller batches Manageable pieces
Iterate Implement pieces one at a time over long periods of time Diffuse risk
Leanness Architect and design the system one iteration at a time JIT waste-free design
Swarm Implement each component in small cross-functional teams Knowledge transfer
Collaborate Use frequent informal communications as often as possible Efficient data transfer
Test Early Incrementally test each component as it is developed Early verification
Test Often Perform system-level regression testing every few minutes Early validation
Adapt Frequently identify optimal process and product solutions Improve performance
How do Lean & Agile Intersect?
69
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
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).
Economic View
Decentralization
Fast Feedback
Control Cadence& Small Batches
Manage Queues/Exploit Variability
WIP Constraints& Kanban
Flow PrinciplesAgile Values
CustomerCollaboration
EmpoweredTeams
IterativeDelivery
Respondingto Change
Lean Pillars
Respectfor People
ContinuousImprovement
Customer Value
Relationships
Customer Pull
Continuous Flow
Perfection
Value Stream
Lean Principles Customer relationships, satisfaction, trust, and loyalty Team authority, empowerment, and resources Team identification, cohesion, and communication
Lean & Agile Practices
Product vision, mission, needs, and capabilities Product scope, constraints, and business value Product objectives, specifications, and performance As is policies, processes, procedures, and instructions To be business processes, flowcharts, and swim lanes Initial workflow analysis, metrication, and optimization Batch size, work in process, and artifact size constraints Cadence, queue size, buffers, slack, and bottlenecks Workflow, test, integration, and deployment automation Roadmaps, releases, iterations, and product priorities Epics, themes, feature sets, features, and user stories Product demonstrations, feedback, and new backlogs Refactor, test driven design, and continuous integration Standups, retrospectives, and process improvements Organization, project, and process adaptability/flexibility
Conclusion
70
Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improves performance by over an order of magnitude
“The world of traditional methods belongs to yesterday”“Don’t waste your time using traditional methods on 21st century projects”
Agile methods are …
Systems development approachesNew product development approachesExpertly designed to be fast and efficientIntentionally lean and free of waste (muda) Systematic highly-disciplined approachesCapable of producing high quality systemsRight-sized, just-enough, and just-in-time tools
Scalable to large, complex mission-critical systems Designed to maximize business value for customers
Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education.