Agile Delivery Powerpoint Presentation Slides

Your Company Name
Agile Delivery

Agenda for Agile Delivery
2
To remove traditional software development methods like waterfall, V model because
of which we are facing high cost & unproductivity in development process
Implementation of discipline agile delivery in software development team for aligning
software development methods
Guiding the teams to choose among different agile practices and create a process,
which best suits the project and the organization
Add text here
Add text here
Add text here

Content
3
Introduction
› Project description
› What problems we are facing
› Survey of issues faced by employees
01.
Selection of Strategic Framework
02.
Hybrid Model of Disciplined Agile Delivery
03.
Agile Delivery Planning
› Disciplined agile delivery phases and goals
› Delivery framework
› Development method
› Delivery plan
› Factors affecting agile delivery
04.
Implementation of Discipline Agile Delivery:
› People-first
o People first: primary roles in disciplined agile delivery
o People first: supporting roles in disciplined agile delivery
o Role of agile team
› Learning oriented
› Scalable
o Scaling agile delivery
o Applying agile development to a broader scale
05.
Risk & Value Driven Approach
› Maximizing stakeholders' value by minimizing risk
› Risk and mitigation plan tabular presentation
06.
Agile Enterprise Developed Architecture- Post Implementation
07.
Delivery Metrics
08.

Content
4
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Project Name: Discipline Agile Delivery(DAD) Framework
5
Front End
4 navigation tabs:
› Home
› About Us
› Contact
› My Account
Back End:
A shopping cart, with payment methods
› PayPal and Credit Card
› Customer registration ability
› E-Mail and Newsletter sign up
› Contact form
$ 100,000
Project Duration 01 July’19- 31 Aug’20
Project Cost
Brief about the Project
Web shop development with the purpose of selling fashion merchandise directly through application
Technical Requirements
Design: Responsive and able to be pulled up on mobile devices Code: HTML and CSS
Developing Language
C, C++, java script and SQL
Schedule
This slide is 100% editable. Adapt it to your needs and capture your audience's attention.

What Problems we are Facing?
6
Listed are the problems that we are currently facing in agile project methodologies while using traditional software development methods like waterfall model, V model and Rational unified process
Currently we are using time
consuming traditional methods of
software development like
Waterfall model, the V model &
Rational Unified Process (RUP)
Due to disconnection between customers &
engineer. Usually engineers make the structure of
the software first & later implement system features
that may not be required by the customers, which
causes delay in development process
Unproductivity
The traditional waterfall model is very
rigid to change, thus a slight change in
progress implementation causing
wastage of money and resources
Changes difficult & Costly
64% of the budget is spent on developing methods as
they are expensive & furthermore wasted on developing
features that are not used or required by the customer
High Costs & Budget Deficit

Survey of Issues Faced by Employees
7
This graph depicts the problems what we are facing in organization while choosing software development methods by conducting a survey also showing key takeaways for the same
› Process customization is required to any
selected method for fulfilling the objectives
› Need for the framework and guidelines,
which can benefit the tailoring process
accessible & understandable
› Decision should be based on environmental
factors, customer requirements, project goals
and project tailoring strategies
› Guiding the teams to choose among different
agile practices and create a process, which
best suits the project and the organization
› Improvements are required in methodology
processes
› Add Text here
› Add Text here
Key Takeaways
Survey
Questions
0 50
Follow a unique methodology at the start of the
project
Tailor an existing methodology at the start of the
project
Carry out a project post mortem after project
completion
A feasibilty study is carried out before starting
A resource requirements analysis is carried out
Yes No Percentage
This graph/chart is linked to excel, and changes automatically based on data. Just left click on it and select “Edit Data”.

Content
8
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Selection of Strategic Framework on the basis of Different Criteria
9
Listed are some software development frameworks differentiated on the basis of different criteria’s like scope, technology, adoption, scaling, complexity, cost and globally distributed team. Highlighted one is the framework that has been selected.
Criteria Scrum of Scrums (SoS)
Scaled Agile Framework
(SAFe)
Large-scale Scrum (LeSS)
Disciplined Agile Delivery
(DAD)
Lean Scalable Agility for
Engineering (LeanSAFE)
Scope
Hardware, software & systems:
flexible
Software Software Software Software, hardware, & systems
Differentiator
Enabling scrum for all scales &
situations
Complex with artefacts, roles &
guidelines
Flexibility by offering suggestions
Complex with covering many
models
Works with critical systems
Underlying technology Scrum Scrum & other agile principles, lean Scrum Scrum, lean Scrum, lean
Adoption Usage in many companies Usage in several companies Usage in several companies Usage has started Usage has started
Scaling
Scaling is flexible and good to adapt
in different setting scaling is flexible
& good to adapt in different settings
Target large companies, but is
perceived as heavy
Can be adapted to different settings Can be adapted to different settings Can be adapted to different settings
Complexity Low High Medium Medium Medium
Cost Low High Medium Medium Low
Globally distributed teams Feasible Feasible Feasible Difficult Feasible
Framework

10
This slide shows that disciplined agile delivery is mixture of all the techniques through which agile and lean software development is easy to fit in together.
Disciplined Agile
Delivery (DAD)
Scrum DevOps Kanban Agile Modeling (AM)
Agile Data (AD)
Lean Software
Development
Extreme
Programing (XP)
Traditional Software
Development
Add Text Here Add Text Here Add Text Here Add Text Here

Content
11
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Disciplined Agile Delivery Phases and Goals
12
This slide covers delivery phases like Inception, Construction, Transition and ongoing. Each of these phases are described by specific goals. Some goals, such as Grow Team Members and Address Risk, are applicable throughout the entire lifecycle/
Phases Description Goals Time Span Time Involved
Inception
How do we start ?
Get the team going in the right direction
› Form Team
› Align with Enterprise Direction
› Explore Scope
› Identify Architecture Strategy
› Plan the Release
› Develop Test Strategy
› Develop Common Vision
› Secure Funding
2-3 months Team A and Team D
Construction
How do we produce a solution?
Incrementally build a consumable solution
› Prove Architecture Early
› Address Changing Stakeholder Needs
› Produce a Potentially Consumable Solution
› Improve Quality
› Accelerate Value Delivery
1 month Team c
Transition
How do we deploy?
Release the solution into production
› Ensure Production Readiness
› Deploy the Solution
15 days Team B
Ongoing
What do we do throughout?
Improve and aware in an enterprise aware manner.
› Grow Team Members
› Govern Delivery Team
› Leverage and Enhance Existing Infrastructure
› Address Risk
› Evolve WoW
› Coordinate Activities
On going
Team A, Team B,
Team C and Team D
Add text here Add text here
› Add text here
› Add text here
Add text here Add text here

Agile Delivery Framework
13
This framework moves from Initiation – an understanding of the motivation and needs of the customer and their stakeholders– through customer and innovator planning, to iterative execution, learning, adjusting and enhancing over consecutive sprints, to release. The whole method repeats
learning from a release that in turn informs fresh or modified initiation, planning, and execution.
Release
Execution
Planning
Initiation
Product Sprints Validate Use
O & M
Transitions
Sprint 1
Review Feedback
Requirement Elaboration
Product Readiness Review
› Software
› Development
› Data Mart
› Dashboards &
› Reports
WBS
CPIC Baseline
Operational Test Readiness Review
NO
YES
Project
Planning Review
Post
Implementation Review
Critical Design
Review
Preliminary
Design Review
System
Definition Review
Operational
Readiness Review
Integration
Readiness Review
Gate Review Sprint Review & Retrospective Sprint Planning Task Potentially Shippable Product Daily Scrum
Deployment
Training
Pilot Cutover
Release Closeout
Product Backlog
Release Backlog
Sprint Backlog
Project Lifecycle
Project
Call Order Management
Integration Testing
User Acceptance Testing
System Acceptance
Operational
Readiness
Sprint n
› CPIC- Capital Planning and Investment Control
› O&M- Observations and Measurements
This slide covers the
framework of the
agile delivery from
initiation to release
which users can alter
according to their
requirements.

Agile Delivery- Agile Development Method (1/2)
14
This slide is covering adaption of an Iterative-Incremental development, where each sprint will be of three weeks. Analysis and design will be completed before the start of coding of the sprint and will be done concurrently with the coding and continuous integration of the previous sprint.
Product Backlog Sprint Backlog
2 Weeks 3 Weeks 3 Weeks
A D A D A D
C CI T DM
C CI T DM
C CI T DM UAT
Finished Product for
Production Deployment
K
E
Y
A
Analysis
C
Code
D
Design
T
Test
DM
Demo
UAT
User Acceptance
CI
Continuous Integration
Sprint-0 Sprint-1 Sprint-2…n

Agile Delivery- Agile Development Method (2/2)
15
This slide covers the agile development method through planning, review and retrospective sprints and daily scrum.
Release Backlog
Sprint Backlog
Potentially Shippable
Product Increment
Product Backlog
Sprint Goal
24
Hours
Daily Scrum
2 - 4
Weeks
Scrum
Code
Refactor
Test
Product Vision
Release Planning Sprint Planning Sprint Review Sprint Retrospective

Delivery Plan
16
Listed below, are the tasks and rearrangement of the dependencies from daily stand-ups, here we have determined that my two resources can work on their assigned tasks simultaneously, but some of the other tasks that are also assigned will have to move back to accommodate this new
addition.
Sprint 1 0 Hrs - 0%
Sprint Planning 0 Bella, Dev 1, Dev 2
Set Up Staging
Environment
0 Dev 1 0
Add Text Here 0 Dev 2 0
Create Base Theme 0 Dev 1, Dev 2 0
Add Text Here 0 Dev 1 0
Testing 0 QA 1 0
Fix Period 0 Dev 1, Dev 2 0
Deploy 0 Bella, Dev 1, Dev 2
Sprint 2 0 Hrs - 0%
Sprint Planning 0 Bella, Dev 1, Dev 2
Add Text Here 0 Dev 2 0%
Add Text Here 0 Dev 1 0%
Impliment Metrics 0 Dev 1 0%
Testing 0 QA 1 0%
Fix Priod 0 Dev 1, Dev 2 0%
Deploy 0 Bella, Dev 1, Dev 2
Bella, Dev 1, Dev 2
Dev 1
Dev 2
Dev 1, Dev 2
Dev 1
QA 1
Dev 1, Dev 2
Bella, Dev 1, Dev 2
Bella, Dev 1, Dev 2
Dev 2
Dev 1
Dev 1
QA 1
Bella, Dev 1, Dev 2
Dev 1, Dev 2
15 16 17 18 19 22 23 24 25 26 29 30 31 1 2 5 6 7 8 9 12 13 14 15 16 19 20 21 22 23 26 27 28 29 30 31
%
Complete
Actual
Hrs.
People
Assigned October 2019 November 2019

Factors Affecting Agile Delivery
17
In this slide we are covering agile delivery plan with three releasing dates based on the basis of some scenarios like themes features, architecture impact dependencies and events.
Market/ Customers
Themes/ Features
Benefits
Architecture Impact
Dependencies
Events and/or
Cycles
Release 1
mm/yyyy- mm/yyyy
Release 2
mm/yyyy- mm/yyyy
Release 3
mm/yyyy- mm/yyyy
Market / customers served by the additions; product changes scheduled
Themes represents a set of characteristics or capacities to be integrated into the product
Business advantages quantifiable for each release
IT architecture and infrastructure expected effect (including dev & test settings)
Dependencies of this project team to other teams and dependence on this project from other teams
Events and seasonal cycles that may affect the timing of the release

Content
18
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

› Here Stakeholders, Product Owner, Architecture Owner &Team Members, all these perform
primary role in software development
› Product Owner is not the specialist of all the fields, he hires specialist, integrator, independent
tester, domain expert, technical expert for supporting the primary role members in specific job
› Add text here
› Add text here
Takeaways
People First: Roles in Disciplined Agile Delivery
19
This slide shows the potential roles in disciplined agile teams. Here primary role have stakeholder who works with team leads, team members, product owner and architecture owner. These are prime members in disciplined agile delivery whereas secondary role are those who work with primary
role members for supporting them in specific job.
P
R
I
M
A
R
Y
R
O
L
E
S
Supporting
Roles Specialist Independent Tester Domain Expert Integrator Technical Expert

People First: Primary Roles in Disciplined Agile Delivery
20
This slide describes Primary roles those are commonly found regardless of the level of scale. There are five primary roles that is stakeholder, team leader, team member, architecture owner and product owner.
Roles Description Name
Stakeholder › “Gold owner” who funds the project Chris Evans
Team Role
Team Leads
› Guides the team in performing technical management activities
› Add text here
Ron Smith
Team Member
› Testing, analysis, architecture, design, programming, planning,
estimation
› Add text here
Amanda Joe
Architecture Owner
› Responsible for ensuring the team mitigates this risk
› Also do agile modeling
Ross Butler
Product Owner
› Represents the needs and desires of the stakeholder community to
the agile delivery team.
› Clarifies any details regarding the solution and is also responsible for
maintaining a prioritized list of work items that the team will implement
to deliver the solution
Jonny Dev
Primary
Roles

People First: Supporting Roles in Disciplined Agile Delivery
21
This slide describes secondary roles for the supporting primary roles like domain expert, technical expert, independent tester, integrator and specialist.
Roles Description Name
Domain Expert (Subject Matter Expert)
› Handle complex domain i.e. Expertise in specialized job or task
› Review, approve and improve technical work
› Add text here
Edward Rose
Technical Expert
› Set up software builder scripts
› Designing and test agile database
› Help designing A usable interface
› Add text here
Michael Jenny
Independent Tester
› Test agility at scale situations within complex domains
› Addressing regulatory compliance issues
› Add text here
Robert Smith
Integrator
› Collecting test performed by professional software testers
› Add text here
› Add text here
Joey Tribanni
Specialist
› Coordinate the team leads on various sub teams/squads
› Handling large teams or complex domain and explore the requirements
for software
› Add text here
Christin Grey
Supporting
Roles

Product Manager Product Owner Scrum Master Team
Role of Agile Team(1/2)
22
This slide provides the roles and description of the work that has been started by project manager and continued by other team members
Ensure the project meets its objectives
Manage the team
Manage scope & budget
Manage stakeholder communication
Remove risk & impediments
Manage the process
Manage vision
Self- organization
Continuous improvement

Role of Agile Team(2/2)
23
Listed are some of the activities that are performed by project owner, scrum master, development team etc. like product owner and other manager is involved in integration activity where as scrum master & development team is not like wise product owner is involved in scope activity but only at
macro level after that technical part is handle by development team at sprint level
Project Management Activity Product Owner Scrum Master Development Team Other Manager
Integration - -
Scope Macro Level - Sprint Level -
Time Macro Level
Helps Team
Manage Time
Sprint Level -
Cost -
Story/task
Estimating
-
Quality
Team -
Communication
Risk
Procurement - -

Content
24
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Learning-oriented Techniques in Disciplined Agile Delivery
25
Listed are the learning-oriented techniques along with its activities, completion time and associated trainer and trainee in the program.
Learning
Techniques
Activities Trainer Trainee
Domain Learning
› Initial requirements envisioning
› Incremental delivery of a potentially consumable
solution
› Active stakeholder participation throughout lifecycle
› Add text here
Edward Amanda
Process
Improvement
› Retrospectives at the end of an iteration
› Tracking of improvements
› Sharing of skills through non-solo development
› Add text here
Add name here Add name here
Technical Learning
› Architecture spikes
› Proving the architecture with working code
› Add text here
General Strategies
› Training and Education
› Mentoring/coaching
› Individuals are generalizing specialists, not just
specialists
Time
Time Period
3
weeks
4
weeks
2
weeks
On-going

Content
26
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

› Large Teams
› Geographically Distributed Teams
› Compliance
› Domain Complexity
› Technical Complexity
› Organizational Distribution
› Delivery Focus
› Risk- Value Driven Lifecycle
› Self Organization With Appropriate
Government
› Goal Driven
› Enterprise Aware
› Construction Focus
› Value Driven Lifecycle
› Self-organizing Team
› Prescriptive
› Project Team Aware
Scaling Agile Delivery (1/2)
27
After implementing DAD agility is done on scale and following are the factors that are considered while scaling agile like large teams , geographically distributed teams, compliance, domain complexity, technical complexity and organizational distribution.
Agility at Scale
Disciplined Agile Delivery(DAD)
Agile/Scrum

28
Scaling Agile Delivery (2/2)
Following are the factors that are considered while scaling agile like large teams , geographically distributed teams, compliance, domain complexity, technical complexity and organizational distribution.
Large Team
› Add text here
› Add text here
Geographically Distributed Teams
› Add text here
› Add text here
Compliance
› Add text here
› Add text here
Domain Complexity
› Add text here
› Add text here
Technical Complexity
› Add text here
› Add text here
Organizational Distribution
› Add text here
› Add text here
Agility
at
Scale

Applying Agile Development to a Broader Scale
29
Agile development was applied to projects that were small in scope and relatively straightforward now we want to apply agile development to a broader set of projects, here we explicitly address the complexities that disciplined agile delivery teams face in the real world based on the agile scaling
factors.
Compliance Requirement
› Add text here
› Add text here
Low Risk Critical Audited
Domain Complexity
› Add text here
› Add text here
Straight Forward Intricate, Emerging
Technical Complexity
› Add text here
› Add text here
Homogenous Heterogeneous Legacy
Organization Distribution
Outsourcing, Partnerships
› Add text here
› Add text here
Collaborative Contractual
Geographical Distribution
› Add text here
› Add text here
Co- located Global
Organizational Complexity
› Add text here
› Add text here
Flexible Rigid
Team Size
› Add text here
› Add text here
Under 10
Developers
1000’s of
Developers
Enterprise Discipline
› Add text here
› Add text here
Project Focus Enterprise Focus
Disciplined
Agile Delivery

Content
30
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Maximizing Stakeholders Value by Minimizing Risk
31
This graph includes various factors that deal with the disciplined agile delivery resulting decrease in risk and increase in value throughout the project.
Key
Takeaways
Stakeholders have expectations very different
from our team goals
Inappropriate architecture like technical problems (such as the
solution not integrating well, not being performant, not being reliable)
Add text here
Add text here
Add text here
Risk
Value
Stakeholder Vision
Regular development of a
potentially consumable solution
Proven
Architecture
Sufficient
Functionality
Production
Ready
Delighted
Stakeholders
Decreasing risk and increasing
value throughout a disciplined
agile project by approving the
Inappropriate architecture,
delighting stakeholders by
Reviewing with key stakeholders
at the end of the Inception phase
to ensure that everyone is on the
same page regard to the project
intent and delivery approach &
making product ready to be
shipped on before deadline.

Risk and Mitigation Tabular Presentation
32
This is the tabular presentation of various factors that deals with the disciplined agile delivery resulting decrease in risks and increase in value throughout the project.
Risk Addressing Risk Mitigation Mitigation Team
Unaligned Stakeholder
› Stakeholder vision milestone - this milestone verifies that
our stakeholders are aligned behind a realistic strategy.
› Include a light-weight inception phase
› Review with key stakeholders at the end of the inception
phase to ensure that everyone is on the same page regard
to the project intent and delivery approach.
Team A
Inappropriate Architecture
› Earlier architecture used to be created at once & the
whole architecture was tested at the end resulting to risk
maximization and decrease in value
› Strategy to explore small portions of your architecture,
such as new technologies or combinations of technologies.
Team B
Delivery Team Gets Off Track
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
Insufficient Functionality
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
Solution Isn’t Ready To Be Shipped
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
Dissatisfied Stakeholders
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here
› Add text here

Content
33
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

Initial Vision & Funding
34
This slide shows the architecture of enterprise divided into three phases those are inception, construction and transition after the implementation of Discipline Agile Delivery.
Identify, Select &
Prioritize the Project
Initial Modelling,
Planning
Envision
the future
Roadmaps & Guidelines
Releasing Solution
in Production
Iteration Wrap-up
› Go forward decision
› Stakeholders demo
Support & Operate
Solutions in Production
Initial Architectural Vision
Funding, Feedback
& Learnings
Consumable
Solutions
Change Requests
Work Items
Initial Requirements
& Release plan
Highest Priority
Work Items
Iteration
Backlog
Task
Consumable
Solutions
Daily
Work
Iteration
Daily Coordination Meeting
Sufficient Functionality
Inception Construction Transition
Short iterations
(one or more)
Stakeholder Vision
Proven Architecture
Many Short iterations Short iterations
(one or more)
Continued Viability (several) Production Ready
Delighted Stakeholders

Content
35
Introduction
01.
02.
03.
› Delivery plan
04.
› People-first
› Scalable
05.
06.
07.
Delivery Metrics
08.

37%
44%
45%
49%
54%
55%
63%
66%
Defect density
Accuracy of planning
Unit test coverage
Resourse
Consumption
Functional Coverage
User satisfaction
Security
Performance
Agile
Agile Delivery Metrics (1/2)
36
Listed Here are the metrics used by the organization to measure agile capability on the basis of product performance, security level and user satisfaction.

Agile Delivery Metrics (2/2)
37
Listed are the agile delivery metrics for measuring quality, stakeholder's satisfaction and time market launch on the bases of data warehouse, mobile development and package implementation.
Mobile
Development
Package
Implementation
Data
Warehouse
Quality Time To Market Stakeholder Satisfaction
› Production incidents
› Automated test coverage
› Ratio of data to errors
› Number of empty values
› Data transform error rates
› Cycle time
› Lead time
› Data time to value
› Ranged burn up chart
› Net promoter score (NPS)
› Reports run
› Time in warehouse
› Cyclomatic complexity
› Cycle time
› Lead time
› Session length
› User retention
› Time in app
› Lifetime value
› UAT issues
› Scheduled variance
› Burndown chart
› UAT issues

39
Coffee Break
Presentation will continue 15 mins

Column Chart
41
0%
10%
20%
30%
40%
50%
60%
2017 2018 2019 2020
0%
10%
20%
30%
40%
50%
60%
2017 2018 2019 2020
This graph/chart is linked to excel, and
changes automatically based on data. Just
left click on it and select “Edit Data”.
Product 01
This graph/chart is linked to excel, and
changes automatically based on data. Just
left click on it and select “Edit Data”.
Product 02

Area Chart
42
0
1
2
3
4
5
6
7
8
9
10
FY01 FY02 FY03 FY04
In
Percentage
Product 01 Product 02 Product 03

Location
43
40% Population
Women
60% Population
Men
USA

44
Thank You
Address
# street number, city, state
Contact Number
0123456789
Email Address
emailaddress123@gmail.com

Agile Delivery Powerpoint Presentation Slides

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Agile Delivery Powerpoint Presentation Slides

Semelhante a Agile Delivery Powerpoint Presentation Slides (20)

Mais de SlideTeam

Mais de SlideTeam (20)

Último

Último (20)

Agile Delivery Powerpoint Presentation Slides