1. HP Confidential
22 September 2018

2. Agenda
Part 1 of 3
What is Agile? …a brief overview
What is Disciplined Agile? …a brief overview
Part 2 of 3
"Introduction to Agile using Scrum“ … a Disciplined Agile perspective
Part 3 of 3
Reporting Status with Disciplined Agile
Some tips for considering Disciplined Agile for your domain
Where to learn more about Agile
By the end of the course you should know enough about Disciplined Agile to consider it for your domain and know how to take the needed training.
HP Confidential
22 September 2018

3. What is Agile? a brief overview
HP Confidential
22 September 2018

4. Agile/Scrum – What it is NOT
“I don’t have to write down anymore requirements” “Everything will go faster now that we’re Agile” “Let’s just jump in and we’ll figure the rest out later” “Everything we did before we don’t do now” “I don’t have to commit because we constantly replan” “How will my team know what to do if I don’t tell them” “No one is in charge – how will anything get done “We just iterated ourselves into a ditch”
Others?

5. HP Confidential
22 September 2018

6. Agile: A Brief History
“The New, New Product Development Game” and “No Silver Bullet”
The Agile Manifesto
Many Agile Frameworks
Continuous integration and other development-oriented framework (later)
Scrum is a project management framework
Principles common to all agile frameworks
People over process
Working software over documentation
Negotiations over contracts
Being adaptable over following a plan

7. Agile is now mainstream...
Introduction to Agile using Scrum
Agile is now mainstream...
Gartner predicts that by 2012, Agile development methods will be used in 80% of all software development projects.
Agile 35%
Agile adoption has reached mainstream proportions. In the recent Forrester and Dr. Dobbs Survey, 35% of respondents stated that Agile most closely reflects their development process with Scrum being the most widely used.
Both waterfall and iterative approaches are giving ground to much lighter, delivery-focused methods based on the principles of the Agile Manifesto. The older methods are not disappearing, however, 34% of survey respondents stated that they continue to use either an iterative or waterfall development process as their primary method of software delivery.
Iterative 21%
Waterfall 13%
Source: Forrester/Dr. Dobb’s Global Developer Technographics Survey, Q3 2009
Source: Forrester/Dr. Dobb’s Global Developer Technographics Survey, Q3 2009
HP Restricted
May 2010

8. Agile Concepts Defined
Scrum framework – Agile methods are frameworks, not methodologies.
Very disciplined
Empirical (like the scientific method)
Minimizing risk – the guiding purpose and ultimate benefit of Agile development
Iterations – not an attempt to “see the future”, instead, understand and believe the right choices will make themselves known – “inspect and adapt”
Impediments and often dysfunction is exposed
Working software – thick documents are impressive but working software pays the bills

9. The 3 branches of Scrum Government
Product Owner
“The What”
Writes and prioritizes Product Backlog and accepts or rejects the product delivered by the team
Determines the release schedule
Responsible for delivering the ROI
Team
“The How” and “How Much”
Decides how many items in the Product Backlog they will commit to in a given Sprint
Decides how to deliver on backlog items
The team is essentially self-managed
Scrum Master
“The Process”
Removes impediments
Ensures everyone is following the Scrum process

10. Scrum Framework summary
Introduction to Agile using Scrum
Scrum Framework summary
Roles
Product Owner
ScrumMaster
Scrum Team
Ceremonies
Sprint Planning
Daily Scrum Meeting
Sprint Review
Sprint Retrospective
Work Products
Product Backlog
Sprint Backlog
Burndown Chart
To summarize:
The Scrum Framework has three roles: the Product Owner, ScrumMaster and the Scrum Team.
There are four ceremonies: Sprint Planning, Daily Scrum Meeting, Sprint Review, and Sprint Retrospective.
And finally there are three Work Products: Product Backlog, Sprint Backlog, and Burndown Chart.
May 2010

11. Architecture, Infrastructure
Scope of Done-ness
Performance
Analysis
Design
Planning
Coding
User Acceptance
Architecture, Infrastructure
Testing
Documentation
Live

12. Avoid Technical Debt
Avoid over-optimism in assessing availability and capacity (initially, we all tend to under-estimate)
Management redirects attention from applying pressure to removing organizational impediments to progress
Product Owners understand the iron triangle (scope, schedule, resources), ownership of risks and impact of cutting quality
Scrum Master must prevent demonstration of any work that is not “done”
Shared sense of what “done” means

13. What is Disciplined Agile? a brief overview
HP Confidential
22 September 2018

14. “Disciplined” Agile is Agile scoped for the global enterprise context
HP Confidential
22 September 2018

15. Why not use agile as-is?
An HP IT release can easily involve many applications…
HP Confidential
22 September 2018

16. Why not use agile as-is? … which are (often highly) interconnected…
HP Confidential
22 September 2018

17. Why not use agile as-is?
… and each staffed by a global team (which churns).
HP Confidential
22 September 2018

18. Why not use agile as-is? Each team would follow its sprint cycles…
HP Confidential
22 September 2018

19. And this would all have to be synchronized.
Why not use agile as-is?
… against its ranked Feature List.
And this would all have to be synchronized.
HP Confidential
22 September 2018

20. That’s why! Global enterprise Agile is not impossible…
Scrum (of scrums (of scrums…)))
… but Agile is optimized for smaller collocated teams
HP Confidential
22 September 2018

21. What to do? Keep IT Commit the same as Phased
Apply sprints within Design, Construct & Test
Fully exploit Agile benefits within these boundaries
HP Confidential
22 September 2018

22. PHASED AND DISCIPLINED AGILE
A sequential approach with required deliverables to exit a phase
Disciplined Agile
An iterative approach with rapid cycling through multiple phases.
Things that are the Same
Business sign-off on requirements at the end of Scoping
IT Commit at the end of Analysis – definition of what ‘done’ looks like
Automated Build / Continuous Integration
Test automation
Required documentation is the same, timing different
Metrics, both headlights and taillights
Things that are Different
Functional Spec during Analysis
Design Phase followed by Construct & Test phase
Design artifacts before construction starts
Prioritized Feature List during Analysis
Quick iterations through Design, Construct, and Test
Design artifacts by the end of the last sprint
Assessment parameters to determine the best fit
Phased
Agile

23. the same lifecycle for both phased AND disciplined Agile
The same from Acceptance Test through Close-out. At this point, all the documentation is complete
The same until the end of Scoping
Portfolio Selection
Project Scoping
Acceptance Test
Implement
Close-out
Reviews
Planning
Development
Warranty
Analysis
Agile Design, Construct, & Test
Design
Construct & Test
Agile Analysis
Either complete Design and then Construct & Test; Or iterate successively through Design, Construct, and Test
Agile analysis focused on the prioritized list of features to be delivered
IT Commit
What will be delivered to the business (“what ‘done’ looks like”), schedule and resources
The same milestone for both approaches

24. Artifacts at a glance Portfolio Selection Analysis Design
Universal
Phased only
Disciplined Agile only
Stored in SDLC repository
Newly introduced
D.A.
Artifacts at a glance
Portfolio Selection
Required
Project Charter
Analysis
Required
Functional specs with traces from business requirements
Feature list with traces from business requirements
Test Strategy
Security Survey
Supportability Survey
Updated CBA
Updated Work Plans
End of analysis sign-off (eSignature)
Data Objects Lifecycle
Elementary Process Definition
Event Tables
Conceptual data model
Func Spec Process model
Archiving and Records Management Survey
Security Threat Analysis
Recommended
Analysis scorecard
Project Risk Assessment & Mitigation Plan
Design
Required
Technical Specs With traces from functional specs /
feature list
Supportability Design Document
Burn-down chart (design, construct & test iterations)
Application Landscape
Infrastructure Landscape
Security Landscape
Application Security Design Document
UML models
Logical data model
Physical data model
Recommended
Design phase scorecard
Develop prototype, test performance & scalability
Traces from Technical Specs to models
Construct & Test
Required
MTP request
MTP Implement Plan
MTP Comm Plan
Test cases, per strategy
Source code with traces
Recommended
Construct & Test scorecard
D.A.
D.A.
Scoping
Required
Business & IT Requirements
Business Requirements Scorecard
Business Requirements sign-off (eSignature)
APQC L3 Business Process Mapping
Use Cases with traces from Business Requirements
Business Data Objects
Initial Work Plan
Recommended
Project Risk Assessment & Mitigation Plan
D.A.
Acceptance Test
Required
UAT sign-off
Test results, per strategy
NCRs/RCRs with traces
End of test sign-off (eSignature)
Warranty Criteria
Support Training
User Training Material
Close-out
Required
Post Implementation Review (PIR)
Recommended
Project retrospective
Exact list of required deliverables determined by the type of project; some may be waived.
30Jan2011
HP Confidential 24
22 September 2018

25. What’s the right choice?
22 September 2018
What’s the right choice?
Each is optimized for a different type of project
Business engagement
Multiple business groups
One business group
Requirements volatility
Less volatile
More volatile
Business process
Mature, well understood
New, discovery mode in industry
Application interfaces
More, complex interfaces
Fewer, simpler interfaces
Phased
Disciplined Agile
Technology familiarity
Known, stable
New, less experience
Team skill level and stability
Less skilled/stable
More skilled/stable
Project size
Larger
Smaller
Co-location
More than 2 locations
1-2 locations
HP Confidential

26. Example A – User Admin Screen Changes for Large Application
22 September 2018
Example A –
User Admin Screen Changes for Large Application
Business engagement
Multiple business groups
One business group
Requirements volatility
Less volatile
More volatile
Business process
Mature, well understood
New, discovery mode in industry
Application interfaces
More, complex interfaces
Fewer, simpler interfaces
Phased
Disciplined Agile
Technology familiarity
Known, stable
New, less experience
Team skill level and stability
Less skilled/stable
More skilled/stable
Project size
Larger
Smaller
Co-location
More than 2 locations
1-2 locations
HP Confidential

27. Example B SAP – Integrate a New Application Data Source
22 September 2018
Example B
SAP – Integrate a New Application Data Source
Business engagement
Multiple business groups
One business group
Requirements volatility
Less volatile
More volatile
Business process
Mature, well understood
New, discovery mode in industry
Application interfaces
More, complex interfaces
Fewer, simpler interfaces
Phased
Disciplined Agile
Technology familiarity
Known, stable
New, less experience
Team skill level and stability
Less skilled/stable
More skilled/stable
Project size
Larger
Smaller
Co-location
More than 2 locations
1-2 locations
HP Confidential

28. Guidance regarding Part 2
Written for Enterprise Business Team in support of their HP Edge Method
Some concepts don’t apply to Disciplined Agile
Product Owner  Business Analyst
Continuous introduction of new requirements
Scaling Agile
Implementation
Release Cycle
Manage Release
Manage Sprints
Develop Features
Test Application
Check in and Integrate Application Components
Product Backlog
Plan Sprints
Daily Scrum
1-4 weeks
24 hours
Sprint Review &
Retrospective

29. "Introduction to Agile using Scrum“ (Grow@HP 00197670) a disciplined agile perspective
HP Confidential
22 September 2018