Disciplined Agile Delivery (DAD): A Brief Introduction

Disciplined Agile Delivery (DAD): A Brief Introduction
© Disciplined Agile Consortium

© Disciplined Agile Consortium
Agenda The Disciplined Agile (DA) Framework Defining Disciplined Agile Delivery (DAD) Hybrid Roles Lifecycles Goal driven Enterprise awareness Scaling and tailoring Governance © Disciplined Agile Consortium

The Disciplined Agile Framework
Agile Enterprise Disciplined Agile IT Disciplined DevOps DAD © Disciplined Agile Consortium

Disciplined Agile Delivery (DAD)
Introduction to DAD Disciplined Agile Delivery (DAD) The key characteristics of DAD: People-first Goal-driven Hybrid agile Learning-oriented Full delivery lifecycle Solution focused Risk-value lifecycle Enterprise aware Foundation of the Disciplined Agile (DA) framework The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.” Many organizations start their agile journey by adopting Scrum because it describes a good strategy for leading agile software teams. However, Scrum is only part of what is required to deliver sophisticated solutions to your stakeholders. Invariably teams need to look to other methods to fill in the process gaps that Scrum purposely ignores. When looking at other methods there is considerable overlap and conflicting terminology that can be confusing to practitioners as well as outside stakeholders. Worse yet people don’t always know where to look for advice or even know what issues they need to consider. To address these challenges the Disciplined Agile Delivery (DAD) process decision framework provides a more cohesive approach to agile solution delivery. There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you. For more information, visit © Disciplined Agile Consortium Copyright 2014 Disciplined Agile Consortium

DAD is a Hybrid Framework
SAFe DevOps …and more Outside In Dev. “Traditional” Agile Data Extreme Programming Unified Process Agile Modeling Scrum Kanban Lean DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. © Disciplined Agile Consortium

Disciplined Agile Delivery: Forming DAD Teams
Roles Primary Roles Architecture Owner Product Owner Team Member Team Lead Stakeholder Secondary Roles (for Scaling) Team Lead: Agile process expert, keeps team focused on achievement of goals, removes impediments Product Owner : Owns the product vision, scope and priorities of the solution Architecture Owner: Owns the architecture decisions and technical priorities, mitigates key technical risks Team Member: Cross-functional team members that deliver the solution Stakeholder: Includes the customer but also other stakeholders such as Project Sponsor, operations, architecture, database groups, governance bodies Big Ideas: Architecture requires a “champion” Stakeholders (i.e. Ops, Support, Infra) must have first class representation Some situations demand the Seondary Roles Regulatory (i.e. Ind. Testing may be mandated) Scaling (i.e. with many teams an Integrator may be essential) Timing – 5 min Independent Tester Domain Expert Technical Expert Specialist Integrator © Disciplined Agile Consortium © Disciplined Agile Consortium

Disciplined Agile Delivery (DAD) Supports Several Lifecycles Agile Continuous Delivery: Agile Exploratory Lean Continuous Delivery: Lean © Disciplined Agile Consortium © Disciplined Agile Consortium

The Process Goals of Disciplined Agile Delivery
This goal-driven approach enables DAD to avoid being prescriptive and thereby be more flexible and easier to scale than other agile methods. For example, where Scrum prescribes a value-driven Product Backlog approach to managing requirements DAD instead says that during construction you have the goal of addressing changing stakeholder needs. DAD also indicates that there are several issues surrounding that goal that you need to consider, and there are several techniques/practices that you should consider adopting to do so. DAD goes further and describes the advantages and disadvantages of each technique and in what situations it is best suited for. Yes, Scrum’s Product Backlog approach is one way to address changing stakeholder needs but it isn’t the only option nor is it the best option in most situations. First and foremost, DAD is a process decision framework. One what that it achieves this through it’s goal-driven approach that guides people through the process-related decisions that they need to make to tailor and scale agile strategies to address the context of the situation that they face. There are several fundamental advantages to taking a goal driven approach to agile solution delivery. A goal-driven approach: Supports process tailoring. Goal diagram, visit for examples, make it very clear how DAD enables people to make intelligent process decisions. Enables effective scaling. DAD provides a foundation from which to scale agile approaches. An important part of scaling agile is to tailor your strategy to reflect the realities of the scaling factors which you face. For example, consider your approach to exploring the initial scope of your effort. A large team or a geographically distributed team will make different tailoring decisions than a small co-located team. A team in a regulatory environment will make different decisions, particularly around amount of detail, than teams in non-regulatory environments. These are just three of several scaling factors. Makes your process options very clear. The more detailed goals diagrams make it very clear what you need to consider when tailoring an agile solution delivery process to meet the unique needs of the situation faced by your team. Takes the guesswork out of extending agile methods. Although it makes for wonderful marketing rhetoric, it’s disingenuous for people to claim that simple methods such as Scrum can be tailored to meet your actual needs. Yes, we suppose this claim is true but how do you do so? Shouldn’t you start with a full delivery lifecycle, not just a construction lifecycle? Shouldn’t the framework cover a wider range of issues, such as leadership and requirements management as Scrum does, technical issues as XP does, modeling and documentation as Agile Modeling does, and many other issues? In short, shouldn’t it be a hybrid? Finally, shouldn’t you be given some context-sensitive advice for tailoring the details, as we do with the goal-driven approach described here? Makes it clear what risks you’re taking on. By making your process decision options clear, and by describing the trade-offs associated with those options, DAD makes it very clear what risks you’re taking on. Want to write a detailed requirement specification up front (yes, in a very small number of situations this is in fact a viable option for agile teams) then DAD is going to make it very clear what risks you’ve just taken on by doing so. DAD also makes it clear when this decision is appropriate, so if you’re not in this situation then it is likely time to rethink your approach. Although we cannot prevent challenges such as a Water-Scrum-Fall approach where a heavy approach is taken to Inception and Transition and an agile/Scrum approach to Construction we can certainly make it very clear what the impact is of the decisions that led you to that approach. Since the DAD book came out in June 2012 we’ve spoken with several people who have used the decision tables in it to argue against inappropriate process decisions on their projects. In many situations the argument “that isn’t agile” falls on deaf ears, whereas “that will take longer and here’s why”, “that will be more expensive and here’s why”, “that will result in lower stakeholder value and here’s why” will be listened to. It hints at an agile maturity model. Scott wrote an article for the December 2012 Cutter IT Journal issue about how DAD and CMMI potentially fit together (DAC members may download this from In that article he suggested that in the case of issues where the options are ordered there is a clearly an indication of agile maturity or sophistication. Having said that we have no desire to wade into the agile maturity model morass, but we think it’s an important observation nonetheless. So far we’ve identified two disadvantages to DAD’s goal-driven approach when working with customer organizations. First, it makes the complexities of solution delivery explicit. Although some of us want to believe that the simplistic strategies of other agile methods will get the job done we inherently know that software development, or more accurately solution delivery, is in fact a complex endeavor in practice. Second, some people just want to be told what to do and actually prefer a prescriptive approach. DAD mitigates this problem a bit by suggesting default starting points (shown in italized bold text in the goal diagrams) but even this can be overwhelming for some people. Interestingly, when we were writing the book two of our 30+ reviewers were adamantly against giving people choices because they felt it was better to adopt a more prescriptive approach as we see in older agile methods. January 2017 Update: Added Develop Initial Test Strategy June 2017 Update: Renamed Fulfill Team Mission Goal to Govern Delivery Team DA is not prescriptive! © Disciplined Agile Consortium

Disciplined Agilists Take a Goal-Driven Approach
Disciplined Agile Delivery: Introduction to DAD Disciplined Agilists Take a Goal-Driven Approach Goal Decision Point Option Default Option * Advantages Disadvantages Considerations * Indicates a preference for the options towards the top Source Evolution strategy Size Structure Member skills Completeness Longevity Geographic distribution Support the team Availability Explore the Initial Scope Form the Initial Team Address Changing Stakeholder Needs Tell students that all goals along with details are in Appendix Timing – 7 min In the past Decision Points were called Process Factors, Process Issues, or simply Factors. Co-located Partially dispersed Distributed subteams Fully dispersed © Disciplined Agile Consortium © Disciplined Agile Consortium 2013

Disciplined Agile Delivery: Process Goals Diagrams
Goal: Secure Funding This Inception process goal describes how we obtain funds for the team. To be effective, we need to consider two important questions: How will we fund the team? How will we access those funds? January 2017 Update: Added Choose Funding Scope Updated in Version 3.0 Renamed Funding Strategy to Choose Funding Strategy Renamed Access Strategy to Access Funds Renamed T&M+performance bonus to Cost Plus Added Charge by Feature © Disciplined Agile Consortium © Disciplined Agile Consortium

Goal: Address Changing Stakeholder needs
Disciplined Agile Delivery: Process Goals Diagrams Goal: Address Changing Stakeholder needs This Construction process goal describes our approach to managing requirements changes. Changes may include new functionality, modifications to existing functionality, or potential defects in existing functionality. To be effective, we need to consider several important questions: How are we going to manage work items? How are we going to prioritize changes? When are we going to accept any changes? How will we work with stakeholders? How will our team elicit feedback from stakeholders? New in Release 2.0: Work Item Mgmt Strategy: Renamed Scrum Product Backlog to Requirement backlog Change Acceptance: Renamed None to Never August 2017 Update: Renamed Manage Work ItemsWork item stack to Work item list Added Prioritize WorkCost of delay Reorganized Stakeholder Interaction with TeamIndirectly via proxies to Indirectly via Product Owner and Indirectly via business analyst Renamed Elicit RequirementsLook-ahead modeling to Look-ahead modeling/backlog grooming © Disciplined Agile Consortium © Disciplined Agile Consortium

DAD Teams Are Enterprise Aware
DAD teams strive to leverage and enhance the existing organizational eco system wherever possible Implications: Work closely with enterprise groups Follow existing roadmap(s) where appropriate Leverage existing assets Enhance existing assets People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team. This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team. By working in an enterprise aware manner DAD teams enjoy: Higher levels of productivity because they are less likely to reinvent the wheel Quicker times to deployment/market because they have less work to do Higher return on investment (ROI) because they have less work to do Higher levels of quality through following common conventions and reuse Timing – 2 min © Disciplined Agile Consortium

Governance is Built Into DAD
Governance strategies built into DAD: Risk-value lifecycle Light-weight milestone reviews “Standard” opportunities for increased visibility and to steer the team provided by agile Enterprise awareness Robust stakeholder definition © Disciplined Agile Consortium

Scaling Agile Tactically
Disciplined Agile Delivery: Advanced Topics Scaling Agile Tactically Tactical Agility at Scale Disciplined agile delivery with one or more scaling factors: Large teams Geographically distributed teams Compliance Domain complexity Technical complexity Organizational distribution Disciplined Agile Delivery Delivery focus Risk-value driven lifecycle Self-organization with appropriate governance Goal driven Enterprise aware To understand the need for the Disciplined Agile Delivery (DAD) process framework you must start by recognizing the realities of the situation which you face. The Process Context Framework (PCF) defines a roadmap to effectively adopt and tailor agile strategies to meet the unique challenges faced by an agile software development team. The first step to scaling agile strategies is to adopt a disciplined agile delivery lifecycle that scales mainstream agile construction strategies to address the full delivery process from project initiation to deployment into production. The second step is to recognize which scaling factors, if any, are applicable to your project team and then tailor your adopted strategies to address the range of complexities the team faces. SAFe skips interim step – leads to severe challenges (even failure) Timing – 2 min Agile Construction focus Value driven lifecycle Self-organizing teams Prescriptive Project team aware © Disciplined Agile Consortium © Scott Ambler + Associates

Parting Thoughts It requires discipline to be successful at agile solution delivery DAD provides you with choices – context counts DAD is a solid foundation from which to scale agile tactically © Disciplined Agile Consortium

Join Today Sign up at DisciplinedAgileConsortium.org and become a member It’s free Have access to new and upcoming information about Disciplined Agile strategies © Disciplined Agile Consortium

The Disciplined Agile Consortium (DAC) supports and evolves the Disciplined Agile process decision framework. The DAC site, DisciplinedAgileConsortium.org, provides information on curriculum and learning resources for Disciplined Agile practitioners. It is also the home of the Disciplined Agile certification program. The Disciplined Agile blog, DisciplinedAgileDelivery.com, provides a wealth of articles and blog postings about Disciplined Agile topics. The Disciplined Agile discussion forum, LinkedIn.com/groups/ , is a meeting place for Disciplined Agile practitioners to share their experiences and to get questions answered. © Disciplined Agile Consortium

Disciplined Agile Delivery (DAD): A Brief Introduction

Similar presentations

Presentation on theme: "Disciplined Agile Delivery (DAD): A Brief Introduction"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Disciplined Agile Delivery (DAD): A Brief Introduction

Similar presentations

Presentation on theme: "Disciplined Agile Delivery (DAD): A Brief Introduction"— Presentation transcript:

Similar presentations

About project

Feedback