Overview of Disciplined Agile Delivery Framework
-
Upload
irshadnizami -
Category
Presentations & Public Speaking
-
view
420 -
download
4
Transcript of Overview of Disciplined Agile Delivery Framework
Overview of Disciplined Agile Delivery (DAD) Framework And Its Comparison with Scaled Agile Framework (SAFe) For Scaling Agile
1
Disciplined Agile Manifesto: Values
Our Values
We value:
Individuals and interactions over processes and tools
Consumable solutions over comprehensive documentation
Stakeholder collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, disciplined
agilists value the items on the left more.
2
Disciplined Agile Manifesto: Principles1. Our highest priority is to satisfy the stakeholder through early and continuous delivery of valuable
solutions.
2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the customer’s competitive advantage.
3. Deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
4. Stakeholders and developers must work together daily throughout the project.
5. Build teams around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
7. Consumable solutions are the primary measure of progress.
8. Agile processes promote sustainable delivery. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximizing the amount of work not done – is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
13. Leverage and evolve the assets within your enterprise, collaborating with the people responsible for those assets to do so.
14. Visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum.
15. Evolve the enterprise to support agile, non-agile, and hybrid teams.
3
Disciplined Agile: Introduction
Not a scaling framework as such but effective from single
small team to Agile at scale.
NOT a prescriptive method with step-by-step guidance. Rather
a process framework which you can adapt to the unique
aspects of your project and organization.
Extends Scrum and includes strategies from Agile Modeling
(AM), XP, and Unified Process (UP).
Addresses areas not thoroughly covered in existing small-
scale frameworks.
Recommended 3 phases: Inception, Construction, Transition.
Construction phase is similar to Scrum. (However, some DAD
teams that have also adopted lean strategies may not have
iterations. )
4
Disciplined Agile Delivery: Lifecycle
5
DAD Process Framework: Characteristics
People first
Learning-oriented
Agile
Hybrid: Adopts strategies from Scrum, XP, AM (Agile
Modeling), UP (Unified Process), AD (Agile Data), Kanban
IT Solution Focused
Full delivery lifecycle
Goals driven
Risk and value driven
Enterprise aware
6
Disciplined Agile Delivery: Roles
Primary roles:
• Team member
• Stakeholder
• Architecture Owner
• Team Lead
• Product Owner
Secondary roles:
• Domain expert
• Specialist
• Technical Expert
• Independent Tester
• Integrator
7
Mapping DAD terminology to Scrum and XP
DISCIPLINED AGILE SCRUM XP
Team Lead ScrumMaster Coach
Iteration Sprint Iteration
Coordination meeting Daily Scrum Daily standup
Product Owner Product Owner Customer
Team member Team member Extreme Programmer
Architecture Owner - -
Work item list Product/Sprint
backlog
-
Spike - Spike
Development
guidelines
- Coding standard
8
Practices adopted from Scrum
■ Work item list (Product backlog)
■ Value-driven lifecycle: In addition, DAD adopts risk-value-driven lifecycle
■ Coordination meeting: Primary question people should address is whether they foresee any upcoming problems.
■ Release planning: Levels of scope to consider: portfolio, solution, release, iteration and day.
■ Iteration planning
■ Iteration review and demonstration
■ Retrospective : Experienced teams can hold retrospectives whenever it makes sense to do so.
■ User story-driven development : DAD follows usage-driven development as it is less prescriptive where the primary requirements artifact is usage focused, such as a user story, usage scenario, or use case.
9
Disciplined Agile: Milestones
■ Stakeholder Vision: Address each of the DAD inception goals. Review a short set of slides with key stakeholders at the end of the Inception phase to ensure that everyone is on the same page with regard to the project intent and delivery approach.
■ Proven Architecture: Build an end-to-end skeleton of working code that implements technically risky business requirements. As a result, early iteration reviews/demos often show the ability of the solution to support NFRs in addition to, or instead of, functional requirements.
■ Project Viability: Optional milestone. A checkpoint to ensure that the project is progressing consistent with the vision agreed to at the end of Inception.
■ Sufficient Functionality: at the end of Construction
■ Production Ready: ensure solution is consumable before you deploy it.
■ Delighted Stakeholders : when the initiative is officially over.
10
Inception Phase: Goals
11
Inception Phase: Initial Release Planning Choosing the right scope for the plan (The agile planning onion)
Choosing a general planning strategy: Recommendation is to combine agile
release planning (predictive –light) with adaptive – detailed, if team is
relatively new to agile, else agile release planning with adaptive – light with
an experienced team.
Choosing cadences: It is recommended to aim for release cadence of no
more than 6 months, with a goal of getting it down to 3 months or shorter.
Formulating an initial schedule
Estimating the cost and value ( using planning poker and educated guesses
by the team)
Identifying risks
12
Inception Phase: Patterns
■ Short and sufficient: Inception phase shouldn’t take >1
month (with the exception of research or ground-breaking
projects). Ideally, this should be completed in 2 weeks or
less.
■ Ranged estimates: It is highly desirable to provide ranged
cost and schedule estimates to provide sufficient flexibility
for the development team to deliver a good solution.
■ Minimal but sufficient documentation: Documentation
should include some basic models (diagrams) of the
envisioned architecture and other views of the solution and
additionally, concise vision statement and a work item list.
Also, there will be other critical diagrams resulting from
requirements and architecture envisioning efforts which are
actively used by team to guide their efforts.
13
Construction Phase: Goals
14
Construction Phase: Patterns
■ The team can be reliably depended on to demonstrate
increments of software at the end of each iteration.
■ Team members finish their tasks ahead of schedule and ask
to help others with their tasks.
■ Iteration dates never move.
■ Any stakeholder can walk into the common work area and
request to see a demonstration of the working software as it
currently sits, at any time.
15
Transition Phase: Goals
16
Transition Phase: Activities
Ensuring Production Readiness
• Transition planning (detailed implementation plan)
• End of lifecycle testing and fixing
• Deployment testing
• Data migration preparation
• Pilot/beta of the solution
• Finalize documentation
Preparing Stakeholders for the Release
• Communicate deployment to stakeholders
• Train/educate stakeholders
• Prepare/support environment stakeholders (Helpdesk, Disaster recovery)
17
Transition Phase: Activities
Deploying the solution: High-level activities might include:
• Running of any batch jobs against the existing system
• Backup of existing system
• Migrating source data to new formats or even to new
technologies
• Deployment of solution artifacts to target environment
• Execute deployment testing: “smoke testing”
• Back up the new solution
• Make the new solution available to customers : make
the system “live”.
• Enable your support system
• Communicate successful deployment
18
Transition Phase: Patterns
■ Short and sufficient
■ Multiple iterations e.g. scaled rollout in several iterations for
geographically dispersed set of users
■ Proven deployment/installation
■ Choose your release patterns
19
Agile Scaling Model (ASM)
■ Core agile development
• Small teams (<15 member teams)
• Co-located
■ Agile Delivery
• Small-to-medium size teams: Up to 30 people
• Near-located (within driving distance)
■ Agility@scale : This is where one or more scaling factors apply. Scaling factors include team size, geographical distribution, regulatory compliance, cultural or organizational complexity, technical complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management).
20
Factors to be considered when scaling DAD
Team size
Geographical distribution
Domain complexity
Organizational distribution
Technical complexity
Regulatory compliance
CMMi compliance
21
Team Organization in DAD : Medium and large-sized teams
■ Medium-sized team : 10-40 people
■ Large team : 30 or more people
■ Team organization strategies:
Feature teams : used in 80-90% of situations
Component teams: used for another 10-20%
Internal open-source : 1-4%
22
Agility at scale
23
Scaled Agile Framework (SAFe)
Based on Lean-Agile principles
Prescriptive approach to scaling Agile
Suitable for scaling agile in large teams working in
programs or portfolios
24
DAD vs SAFe
Disciplined Agile Delivery Framework Scaled Agile Framework
Provides guidance (Not too much guidance, so not
overly prescriptive)
Prescriptive (tells what to do)
Easier to implement (due to similarities with basic
Agile frameworks, methods)
Needs a specific expertise for implementation;
May not fit in some situations
Evolving (Disciplined Agile 2.0) Evolving (SAFE 4.0)
Lightweight compared to SAFe Heavyweight compared to DAD
Provides foundation for scaling. Suitable for small
to large teams
Scaling framework
Levels: Day, Iteration, Release, Solution, Portfolio Levels: Team, Program, Value Stream, Portfolio,
Team size: 30 or more (in large team) Team size : 50-125 per ART
25
DAD vs SAFe: Roles
Disciplined Agile Framework Scaled Agile Framework
Team Lead Scrum Master
Product Owner Product Owner/Business Owners
Architecture Owner System Architect / Engineer
Team member Team member
- RTE (Release Train Engineer), VTE (Value Train
Engineer)
Stakeholder Customer
Product Management Product Management
26
Disciplined Agile Certification path (Shu-Ha-Ri)
27
Links:
■ http://www.disciplinedagiledelivery.com/blog/
■ http://www.disciplinedagiledelivery.com/agility-at-
scale/large-agile-teams/
28