How to Successfully Apply Agile at Scale in the Enterprise

How to Successfully Apply Agile at Scale in the Enterprise
Taking Scrum to the Next Level With Disciplined Agile Delivery(DAD): How to Successfully Apply Agile at Scale in the Enterprise © Disciplined Agile Consortium © Scott Ambler + Associates

Let’s explore a few important questions….
Are you struggling with the complexity of software development? Are you really agile? Are you getting the results you expected? How can you address the gaps in mainstream agile methods? How does disciplined agile work? How do teams work together on a disciplined agile project? How do you govern agile projects? What do you need to do to succeed? How we can help © Disciplined Agile Consortium

© Disciplined Agile Consortium
ARE YOU STRUGGLING WITH DEALING WITH THE COMPLEXITY OF SOFTWARE DEVELOPMENT? © Disciplined Agile Consortium

State of Agile Delivery
Introduction to Disciplined Agile Delivery - Instructor Notes State of Agile Delivery In 2001 Agile made great promises: We were going to cut schedules in half Increase developer productivity five fold Increase quality two fold But what actually happened: We achieved minor increases in productivity and quality in the development of new silo applications Chaos Report: In 2002 the success rate was 34% successful and 51% challenged and in 2009 it was 32% successful and 44% challenged Dr. Dobb’s Journal: In 2011 we found an Agile project success rate of 67% successful and 27% challenged and a traditional project success rate of 50% successful and 36% challenged We need to do better Successful means met all success criteria Challenged means still delivered but didn’t meet all success criteria Difference in rates between Standish and Dobb’s is Standish forces a definition of success on you (on time, on budget, to spec) whereas Dobb’s allows you to set your own success criteria (which is exactly how projects are judged in the real world). © Disciplined Agile Consortium Module 1 - Agile and Discipline Agile Delivery Overview

Why This is Hard: The New Environment
The IT market is constantly changing Pace of delivery is increasing SaaS vendors dominating software acquisition model Increased standards and regulations Mobile devices ( different makes / different OSs) Ubiquitous internet wireless Too many project teams are suffering from Water-Scrum-Fall More standards and methods to choose ( XP, Scrum, Kanban, DSDM, Unified Process, …) Information technology departments are losing control over budgets and decision making We need to make sense of it all What’s the story…. © Disciplined Agile Consortium

Why This is Hard: Delivery at Scale
Domain Complexity Straightforward Very complex motivates Geographic Distribution Co-located Global Team Size 2 1000s motivates Technical Complexity Straightforward Very complex motivates varies by motivates motivates Organizational Distribution Single Outsourcing Team Culture Agile Rigid Compliance None Life critical affects affects Teams find themselves in unique situations and must tailor their team structure, tooling, and process accordingly. affects affects Project Type Agile-Friendly Traditional Organizational Culture Agile Rigid © Disciplined Agile Consortium

ARE YOU REALLY AGILE? © Disciplined Agile Consortium

Introduction to Disciplined Agile Delivery
15 April 2009 Introduction to Disciplined Agile Delivery What is Agile? “Agile software development is an evolutionary (iterative and incremental) approach which regularly produces high quality software in a cost effective and timely manner via a value driven lifecycle. It is performed in a highly collaborative, disciplined, and self- organizing manner with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders. Agile software development teams provide repeatable results by adapting just the right amount of ceremony for the situation they face.” Scott Ambler Definition is taken from “The Agile Scaling Model (ASM): Adapting Agile Methods for Complex Environments”, Scott Ambler 2009 © Disciplined Agile Consortium

Organizational Opportunities
Greater level of certainty to deliver results Ability to respond to changes quickly Improved communication Skilled and flexible workforce Increased employee satisfaction Motivated and committed staff Opportunity to create a competitive advantage Value Producing quality Software for the customer Operational Excellence Increased Customer Satisfaction Customer Intimacy © Disciplined Agile Consortium

Agile Adoption and Success Rates
Question: To your knowledge, has your organization successfully applied agile techniques/strategies/processes on one or more development projects? Implication: 86% of respondents work in organizations that are at least trying agile techniques. Source: Dr. Dobb’s Journal Sept 2012 State of IT Union Survey © Disciplined Agile Consortium

Agile Failure Rates Question: To your knowledge, has the organization unsuccessfully applied agile techniques/strategies/processes on one or more development projects? Implication: Agile adoption isn’t always easy. However, the majority organizations are experiencing success with agile. Source: Dr. Dobb’s Journal Sept 2012 State of IT Union Survey © Disciplined Agile Consortium

Why agile? Higher success rates
Detailed results online at Success as defined by the respondent (this is the same for all slides in this deck). See other slides for how IT professionals define success in practice Calculated by summarizing the weighted average of each range (i.e % averages to 95%) times the number of respondents. Same approach taken for other slides too. Definitions used in the survey: On an ad-hoc software development project the team does not follow a defined process. On an iterative software development project the team follows a process which is organized into periods that are often referred to as iterations or time boxes. On any given day of the project team members may be gathering requirements, doing design, writing code, testing, and so on. An example of an iterative process is RUP. On an agile software development project the team follows an iterative process which is also lightweight, highly collaborative, self-organizing, and quality focused. An example of an agile process is OpenUP, Scrum, and XP. On a traditional software development project the team follows a staged process where the requirements are first identified, then the architecture/design is defined, then the coding occurs, then testing, then deployment. Traditional processes are often referred to as "waterfall" or simply "serial" processes. Lean is a label applied to a customer value-focused mindset/philosophy. A lean process continuously strives to optimize value to the end customer, while minimizing waste which may be measured in terms of time, quality, and cost. Ultimately the Lean journey is the development of a learning organization. Examples of Lean methods/processes include Kanban and Scrumban. Source: Dr. Dobb’s Journal 2011 IT Project Success Rate Survey © Disciplined Agile Consortium

Why agile? It works better Scale of -10 to +10
Detailed results online at Bottom Line: Agile teams produce higher quality work, are quicker to deliver, are more likely to deliver the right functionality, and more likely to provide greater ROI than traditional teams Source: Dr. Dobb’s Journal 2011 IT Project Success Rate Survey © Disciplined Agile Consortium

Disciplined Agile Delivery: Agile Foundations
The Agile Manifesto We value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. The Agile Manifesto was drafted in 2001 by the following individuals: Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Utah Ski Trip w/ Alistair Cockburn to discuss “what works” However – now “never to be changed”; that sentiment doesn’t seem to be Agile Timing - 3 min Source: © Disciplined Agile Consortium © Disciplined Agile Consortium

But… We Should Extend Agile Thinking
07/11/2017 Disciplined Agile Delivery: Agile Foundations But… We Should Extend Agile Thinking Solutions, not just software Stakeholders, not just customers The organizational ecosystem, not just development teams The changes that DAD suggests for the Agile Manifesto are straightforward: Where the original manifesto focused on software development, we suggest that it should instead focus on solution delivery. Where the original manifesto focused on customers, we suggest that it focus on the full range of stakeholders instead. Where the original manifesto focused on development teams, we suggest that the overall organizational ecosystem and its improvement be taken into consideration. Timing – 2 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Some “Radical” Agile Ideas
Disciplined Agile Delivery: Construction Some “Radical” Agile Ideas Do the simplest thing possible and no more Changing requirements are a good thing Teams should have all the skills and knowledge required to get the job done Less is often more – Keep all artifacts as lightweight as possible Capture detailed requirements and designs as executable tests, not written documents or models Collaboration is critical to your success Test often and early, and better yet test first Non-solo work is more effective than people working alone Too much up front modeling and planning increases project risk Learn from your experiences, and evolve your strategy as the project progresses Stakeholders have greater visibility into an agile project and greater opportunities to guide the team Big Idea: With information radiators, governance can be accomplished by “wandering around” Timing – 5 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Criteria for a Disciplined Agile Team
Disciplined Agile Delivery: Agile Foundations Criteria for a Disciplined Agile Team Business value Produce a working solution on a regular basis which provides quantifiable value to stakeholders Validation Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach Collaboration Work closely with their stakeholders, or a stakeholder proxy, ideally on a daily basis Self organization Are self-organizing and work within an appropriate governance framework Improvement Regularly reflect on, and measure, how they work together and then act to improve on their findings in a timely manner Big Idea: Discipline is required to do these things Timing – 2 min © Disciplined Agile Consortium © Disciplined Agile Consortium

How Agile Are Teams Claiming to Be Agile?
Disciplined Agile Delivery: Agile Foundations How Agile Are Teams Claiming to Be Agile? Teams Claiming to be Agile Teams Moving to Agile Business value 91% 83% Validation 88% 69% Collaboration 99% 94% Self organization 72% 51% Improvement 92% 90% All Criteria 65% 39% Big Idea: Discipline is required to do these things Timing – 2 min Source: SAA 2013 How Agile Are You? Survey © Disciplined Agile Consortium © Disciplined Agile Consortium

ARE YOU GETTING THE RESULTS THAT YOU EXPECTED?
© Disciplined Agile Consortium

Defining Success Time/Schedule 20% prefer to deliver on time according to the schedule 26% prefer to deliver when the system is ready to be shipped 51% say both are equally important Return on Investment (ROI) 15% prefer to deliver within budget 60% prefer to provide good ROI 25% say both are equally important Value 4% prefer to build the system to specification 80% prefer to meet the actual needs of stakeholders 16% say both are equally important Quality 4% prefer to deliver on time and on budget 57% prefer to deliver high-quality, easy-to-maintain systems 40% say both are equally important Only 12% of respondents indicated that their definition of success on their most recent project included all three of delivering according to schedule, within budget, and to the specification. Of the 178 people who answered the questions about schedule, budget, and specification 22 (12%) indicated that they defined success as including “fixing” all three of those things Schedule valid answers were deliver within schedule or both Budget valid answers for money question were deliver on or under budget or both Specification valid answers for value question were deliver to spec or both © Disciplined Agile Consortium

Are you experiencing any of these pain points?
Requirements backlogs that seem to keep growing Defects found late in the project Poor quality and hard to maintain code Never ending projects Misunderstanding with business about the value of agile Agile being viewed as uncontrolled “hacking” Inconsistency with corporate standards in the areas of architecture, database, governance A Project Management Office (PMO) that wants detailed plans, requirements, and specifications that agile doesn’t have © Disciplined Agile Consortium

HOW DOES DISCIPLINED AGILE DELIVERY (DAD) ADDRESS THE GAPS IN MAINSTREAM AGILE METHODS? © Disciplined Agile Consortium

Disciplined Agile Delivery is a process decision framework
Introduction to DAD Disciplined Agile Delivery is a process decision framework The key characteristics of DAD: People-first Goal-driven Hybrid agile Learning-oriented Full delivery lifecycle Solution focused Risk-value lifecycle Enterprise aware 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

Disciplined Agile Delivery: The Foundation for Scaling Agile
Compliance Domain Complexity Technical Complexity Geographic Distribution Team Size Organizational Distribution Disciplined Agile Delivery (DAD) Scrum Extreme Programming Lean Kanban Unified Process Agile Modeling Agile Data “Traditional” TOGAF DevOps …and more SAFe 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

Scrum Lifecycle Practices Product Backlog (work item list) Value-driven lifecycle Daily Scrum meeting (coordination meeting) Release Planning Sprint planning (iteration planning) Sprint review and demonstration Sprint retrospective User story driven development © Disciplined Agile Consortium

High-Level Delivery Lifecycle

Disciplined Agile Delivery: Agile Lifecycle
…. And there’s a fair bit to the agile delivery lifecycle This lifecycle presents a more detailed view of what we call the Agile/Basic DAD lifecycle which extends Scrum’s construction lifecycle. In addition to this being a more detailed view of the lifecycle, there are several interesting aspects to this lifecycle: It’s iteration based. Like many agile methods, including both Scrum and XP, the solution is built incrementally in a time-boxed manner. These timeboxes are called iterations (what Scrum calls sprints). It uses non-Scrum terminology. Although the lifecycle is Scrum-based we chose to use non-branded terminology in DAD, in the case of this diagram the term iteration instead of sprint. The terminology doesn’t really matter, so if you’re more comfortable with Scrum terminology use that instead. It shows inputs from outside the delivery lifecycle. Although the overview diagram above showed only the delivery lifecycle, the detailed diagram below shows that something occurs before the project before Inception and that agile teams often get new requirements (in the form of change requests and defect reports) coming in from production. These inputs provide important context for the overall delivery lifecycle. There is a work item list, not a product backlog. DAD has a greater scope than Scrum, and when you take this greater scope into account you begin to realize you need a more robust change management approach than Scrum’s product backlog. Work items include requirements, defects, and other non-functionality oriented work such as training, vacations, and assisting other teams. All of this work needs to be prioritized somehow, not just implementation of requirements. For more on this, read Agile Best Practice: Prioritized Requirements. In includes explicit milestones. Along the bottom of the lifecycle diagram there is an indication of suggested light-weight milestones that DAD teams should strive to meet. Such milestones are an important aspect of agile governance. We call this the basic/agile lifecycle because it’s likely where you’re going to start with DAD. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach. © Disciplined Agile Consortium © Disciplined Agile Consortium

Disciplined Agile Delivery: Lean Lifecycle
DAD doesn’t‘ prescribe a single lifecycle This diagram depicts what we call the Advanced/Lean DAD lifecycle. There are several interesting features to this lifecycle: It supports a continuous flow of delivery. In this lifecycle the solution is deployed as often, and whenever, it makes sense to do so. Work is pulled into the team when there is capacity to do it, not on the regular heartbeat of an iteration. Practices are on their own cadences. With iterations/sprints many practices (detailed planning, retrospectives, demos, detailed modeling, and so on) are effectively put on the same cadence, that of the iteration. With a lean approach the observation is that you should do something when it makes sense to do it, not when the calendar indicates that you’re scheduled to do it. It has a work item pool. All work items are not created equal. Although you may choose to prioritize some work in the “standard” manner, either a value-driven approach as Scrum suggests or a risk-value driven approach as both DAD and RUP suggests, but other work may fit this strategy. Some work, particularly that resulting from legislation, is date driven. Some work must be expedited, such as fixing a severity one production problem. So, a work item pool and not a prioritized stack makes a bit more sense when you recognize these realities. We call this the advanced/lean lifecycle because it’s something we see teams evolve to over time. They often start with the basic lifecycle described earlier but as they learn, as they improve the way that they work, the lifecycle they follow becomes leaner. © Disciplined Agile Consortium © Disciplined Agile Consortium

The Phases Disappear Over Time
Disciplined Agile Delivery: Introduction to DAD The Phases Disappear Over Time First release: Inception Construction Transition Second release: I Construction T Third release: I Construction T Nth+ releases: C T . Big Ideas 75 – 85% of Agile teams working on next version of a product already in production Keep teams together reduces team dynamic problems Motivates to commit to product Automate Transition Instrument to monitor in Production This “path” is a multi-year undertaking Timing – 5 min …and promotes continuous learning and improvement. © Disciplined Agile Consortium © Disciplined Agile Consortium

Disciplined Agile Delivery: Agile Continuous Delivery Lifecycle
Instructor notes: Common for stable teams doing Agile Iterations are typically 1-2 weeks, although 1 day also common At the end of the iteration you release into production More like a “very regular delivery” lifecycle than a continuous delivery lifecycle May 2017 update: Added this slide © Disciplined Agile Consortium © Disciplined Agile Consortium

Disciplined Agile Delivery: Lean Continuous Delivery Lifecycle
A good end goal This diagram depicts a Continuous Delivery version of the DAD lifecycle. It is basically a leaner version of the previous lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too. © 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 DAD is Goal-Driven, 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

Goal: Develop Common Vision
07/11/2017 Disciplined Agile Delivery: Process Goals Diagrams Goal: Develop Common Vision This Inception process goal describes how we will come to, and communicate, a common vision as to the purpose of the team. To be effective, we need to consider several important questions: What strategy will we follow to develop the vision? How much detail must we capture? What level of agreement must we come to with our stakeholders before we can move on into Construction? What level of formality must we get for this agreement? Note: Project wikis are commonly used. New in 2.0 Removed None as options (it’s implied) Level of Agreement – Move General agreement to top of list © Disciplined Agile Consortium © Disciplined Agile Consortium

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 – Secure Funding © Disciplined Agile Consortium

Goal – Secure Funding (cont.)

Module 3 - Forming DAD Teams
Scrum Roles Scrum Master Product Owner Team Member 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 © Disciplined Agile Consortium © Scott Ambler + Associates

Disciplined Agile Delivery (DAD) Roles
Disciplined Agile Delivery: Forming DAD Teams Disciplined Agile Delivery (DAD) Roles Primary Roles Architecture Owner Product Owner Team Member Team Lead Stakeholder Secondary Roles (for Scaling) Independent Tester Domain Expert Technical Expert 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 Specialist Integrator © Disciplined Agile Consortium © Disciplined Agile Consortium

Primary Roles on DAD Teams
Disciplined Agile Delivery: Introduction to DAD Primary Roles on DAD Teams 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 January 2017 update: Updated definition of stakeholder Using the role graphics Turned into a build slide Stakeholder Includes the customer but also other stakeholders such as the project sponsor, operations engineers, support staff, architecture, database groups, finance, and so on © Disciplined Agile Consortium © Disciplined Agile Consortium

Secondary Roles on DAD Teams
Disciplined Agile Delivery Secondary Roles on DAD Teams Independent Tester A test/quality professional outside of the team who validates their work Specialist Someone in a specialist role, such as business analyst, program manager, or enterprise architect Domain Expert (Subject Matter Expert) Someone with deep knowledge of the domain, such as a legal expert or marketing expert who is brought in as needed to share their expertise Technical Expert Someone with deep technical knowledge, such as a security engineer or user experience (UX) professional, whose help is needed for a short period January 2017 update: Using the role graphics Turned into a build slide Integrator Someone responsible for the operation of the overall team build Note: “The secondary” DAD roles typically occur at scale © Disciplined Agile Consortium Domain Expert Technical Expert Specialist Integrator © Scott Ambler + Associates

HOW DO DAD TEAMS WORK? © Disciplined Agile Consortium

The Inception Phase © Disciplined Agile Consortium

Industry Data: Inception Activities
Introduction to Disciplined Agile Delivery 07/11/2017 Industry Data: Inception Activities Source: Source: Ambysoft 2009 Agile Project Initiation Survey © Disciplined Agile Consortium © Scott Ambler + Associates

The Agile 3C (Coordinate-Collaborate-Conclude) Rhythm
Module 1 - Introduction to DAD The Agile 3C (Coordinate-Collaborate-Conclude) Rhythm Inception Construction Transition Release rhythm Day to weeks Several iterations Hours to weeks Iteration rhythm Iteration planning Development Iteration wrap up A few hours Several days A few hours Coordination Meeting Daily Work Stabilize Daily rhythm Suggested reading: Software Development Rhythms: Harmonizing Agile Practices for Synergy. Kim Man Lui and Keith C. C. Chan (2008) A few minutes Several hours Varies Coordinate Collaborate Conclude © Disciplined Agile Consortium © Scott Ambler + Associates

Disciplined Agile Delivery: Inception
The Inception Phase Timing – 2 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Construction Phase Goals

The Construction Phase Overview
Disciplined Agile Delivery: Construction The Construction Phase Overview Timing – 1 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Choosing Iteration Lengths
Disciplined Agile Delivery: Inception Choosing Iteration Lengths The average construction iteration length is 2.3 weeks* Heuristics: Shorter is generally better than longer Teams at scale may require slightly longer iterations Big Ideas: Shorter is better than longer Short squeezes out waste Short forces process improvement Timing – 1 min *Source: SA+A 2015 Agile State of the Art Survey © Disciplined Agile Consortium © Disciplined Agile Consortium

Overview of a Construction Iteration
Disciplined Agile Delivery: Construction Overview of a Construction Iteration Timing – 1 min © Disciplined Agile Consortium © Disciplined Agile Consortium

A Typical Day of Construction
Disciplined Agile Delivery: Construction A Typical Day of Construction Note: Important that Task Board is update before Daily Coordination Many will do it at the end of day Timing – 2 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Transition Phase and Goals

Transition/Release Phase on Experienced Agile Teams Average = 4
Transition/Release Phase on Experienced Agile Teams Average = 4.6 weeks Experienced teams = Pretty much agile but working out a few kinks or Mature agile team Average calculated as a weighted average. 1 day or less considered as 1 day. 1 week or less considered as one week weeks taken as 14 weeks. Source: Ambysoft November 2010 Agile State of the Art Survey

Overview of the Transition Phase
Disciplined Agile Delivery: Transition Overview of the Transition Phase Big Idea When do you know you’re done Production ready? Deployed? Delighted Stakeholders? Story from Scott With 10 key stakeholders the team had to receive 5 positive s Timing – 3 min © Disciplined Agile Consortium © Disciplined Agile Consortium

HOW DO YOU GOVERN AGILE PROJECTS?

Governance Addresses a Range of Issues
Team roles and responsibilities Individual roles and responsibilities Decision rights and decision making process Governing body Exceptions and escalation processes Knowledge sharing processes Metrics strategy Risk mitigation Reward structure Status reporting Audit processes Policies, standards, and guidelines Artifacts and their lifecycles Funding © Disciplined Agile Consortium

Why Traditional Governance Strategies Won’t Work For Agile Delivery Teams Traditional assumptions that conflict with agile: You can judge team progress from generation of artifacts Delivery teams should work in a serial manner You want teams to follow a common, repeatable process Projects should be driven by senior IT management © Disciplined Agile Consortium

Aspects of Effective Agile Governance
Trust and respect are the foundation of effective governance Be stakeholder driven Collaboratively define your governance strategy Be transparent Motivate, don’t dictate Enable, don’t enforce Optimize the “IT whole”, not the “governance part” Optimize corporate performance Collaboratively set reasonable guidance Collaboratively define rights and responsibilities Be suitable to task Automate wherever possible © Disciplined Agile Consortium

DAD Milestones Milestone Fundamental Question Asked Stakeholder vision Do stakeholders agree with your strategy? Proven architecture Can you actually build this? Continued viability Does the effort still make sense? Sufficient functionality Does it make sense to release the current solution? Production ready Will the solution work in production? Delighted stakeholders Are stakeholders happy with the deployed solution? © Disciplined Agile Consortium

Practices that Support Governance
“Standard” agile practices: Coordination meeting Iteration demonstrations All-hands demonstrations Retrospective Information radiators/Visual management Disciplined practices: Risk-value lifecycle Explicit light-weight milestones Follow enterprise development guidelines Work closely with enterprise professionals Development intelligence via automated dashboards © Disciplined Agile Consortium

Measuring Agile Teams Talk to people; don’t manage to the metrics Measure teams, not individuals Collect several metrics Trends are better than scalar values Empirical observation is important but limited Prefer automated metrics Some metrics must be gathered manually Prefer pull versus push reporting Beware scientific facades Measure the value of your metrics program Be prepared to educate people The value of many metrics diminishes over time If you collect no metrics at all you’re flying blind If you collect too many metrics you may be flying blinded © Disciplined Agile Consortium

Potential Metrics Acceleration Lifecycle traceability Activity time Net present value (NPV) Age of work items Ranged release burndown Blocking work items Release burndown Build health Return on investment (ROI) Business value delivered Risk mitigation Change cycle time Stakeholder satisfaction Code quality Team morale Defect density Test coverage Defect trend Time invested Effort/cost projection Velocity Iteration burndown © Disciplined Agile Consortium

Why Disciplined Agile Delivery (DAD)?
Increased productivity Enterprise awareness leads to better solution fit Risk-value lifecycle streamlines development – Reduces “surprises” late in the project DAD optimizes the solution delivery whole, not just the agile programming part Easy to tailor Goal-driven approach provides easy-to-follow advice Avoids the “one size fits all” approach of other agile methods Scalable Enterprise awareness leads to better organizational fit Goal-driven Palatable Answers many of the questions experienced agile teams are still struggling with Reflects actual practice, not theory The next step for teams currently doing Scrum © Disciplined Agile Consortium

WHAT DO YOU NEED TO DO TO SUCCEED?

Disciplined Agile Delivery: Advanced Topics
Why Change is Hard © Disciplined Agile Consortium © Disciplined Agile Consortium

Impediments You May Encounter
People may resist: Collocation Transparency Accountability Sustained pace of agile Collaborative work Common cultural challenges: Perfectionist behavior Resistance to building without a detailed specification Over specialization of roles Preference for a traditional/serial process Different cultures within teams © Disciplined Agile Consortium

Primary Challenge to Adoption is Culture Change
Disciplined Agile Delivery: Advanced Topics Primary Challenge to Adoption is Culture Change Demonstrate early success Invite stakeholders to participate at every opportunity, level of transparency and accountability may surprise them Invite them to coordination meetings, explain the charts and models on the walls Focus on delivering visible value to stakeholders regularly Specialists can struggle with this at first Invite stakeholders to regular demonstrations, this may be new to them Focus on high-value activities Many traditional “best practices” are abandoned Agile teams are self organizing Many existing managers struggle with this, and some people like being directed Disciplined agile teams are governed appropriately Your IT governance strategy will need to change Quality focused Quality is everyone’s job Note the general “evaporation” of a Project Manager role Timing – 1 min © Disciplined Agile Consortium © Disciplined Agile Consortium

Agile Champions/Sponsors
Agile champions external to the team can help support and promote change Help to accelerate agile “transformation” in the organization Without executive sponsors in it for the long term it is very unlikely your adoption will succeed © Disciplined Agile Consortium

The Use of Agile Coaches Increases Your Chance of Agile Adoption Success Role and responsibilities of an agile coach Provide advice to the team Provide opportunities for people to learn, even through mistakes Pair with the people they are coaching to provide detailed mentoring, especially team leads, product, and architecture owners Help teams to solve problems Negotiate conflicts within the team Promote self organization and self discipline within the team Help foster self awareness for improvements within the team Motivate teams to deliver on their commitments © Disciplined Agile Consortium

General Adoption Advice for Team Members
Project Manager Independent Tester Product Owner Team Lead Architecture Team Member Designer Programmer Architect Analyst Likely option Good option Be prepared to pair with others to transfer your skills to them and to pick up new skills from them Accept that “the rules” have changed and you need to as well Accept the idea that your traditional role may not exist anymore although the activities of your traditional role still occur Be prepared to work in an evolutionary and collaborative manner Be prepared to move away from a specialist role to become a generalizing specialist Be prepared to deliver a potentially consumable solution every few weeks © Disciplined Agile Consortium

Agile Changes Your Relationship with the Business
Introduction to Disciplined Agile Delivery Agile Changes Your Relationship with the Business Your business and IT processes must reflect one another Plans must be high-level with the details coming just in time (JIT) Emphasize delivery of value via a consumable solution rather than transitory work products of questionable value Schedules and estimates must be given in ranges Traditional business approaches will eliminate most benefits of agile The new relationship with the business: They must be actively involved with development all the way through the lifecycle The greater visibility and control that they now have implies the need for greater accountability on their part They often don’t understand the implications of what they ask for, you need to educate them You need to demonstrate that disciplined agile delivery is not cowboy programming. It is very likely far more disciplined than their current processes Suggested strategy: Help your customers to understand what is expected of them and why Business decision makers need to be coached too Be selective about the projects you apply agile strategies to. If the business isn’t willing to step up then the project isn’t a good choice for agile © Disciplined Agile Consortium © Scott Ambler + Associates

Anti-patterns of Adoption
Thinking you’re already agile Thinking that you’re in a special situation where agile can’t help Trying to adopt too many agile practices at once Focusing on a subset of the delivery process Focusing on individual roles one at a time Believing that one agile process is enough (such as Scrum or XP) Following any agile process prescriptively Assuming agile team members with agile experience on their resume or a certification are agile experts and don’t need coaching © Disciplined Agile Consortium

WE CAN HELP! A SELECTION OF COURSES AND SERVICES

BOOTCAMP: MOVING FROM SCRUM TO DAD
A boot camp is a short path to avoid common pitfalls organizations experience when they rely solely on Scrum Build the foundation for your success with details on the full delivery lifecycle, including the Inception and Transition Phases © Disciplined Agile Consortium

PROFESSIONAL ASSESSMENT
A comprehensive look at strengths and blind spots may be just what is required... from a fresh set of eyes Experts versed in disciplined enterprise agile transformations offer the best way to mitigate risks and maximize the gain from your investment © Disciplined Agile Consortium

TRAINING: DISCIPLINED AGILE FOR EXECUTIVES
Learn how to go beyond Scrum to take a disciplined agile approach to solution delivery that provides a foundation from which to scale To help cut through some of the agile rhetoric, industry statistics will be discussed throughout this workshop © Disciplined Agile Consortium

PRACTITIONER TRAINING: A DISCIPLINED APPROACH
Training courses, based on agile thought leadership, are the most disciplined path to innovation and excellence Sample: Agile Model Driven Development, User Stories, Acceptance Criteria, Agile Architecture, Agile Database Techniques and Business Modeling with BPMN © Disciplined Agile Consortium

DAD COACHING: PILOT PROJECT
When piloting DAD for the first time, you may require an experienced guide to bring fresh perspectives, fill knowledge gaps and meet the challenge at hand Our experts supervise and drive your transition to a positive conclusion © Disciplined Agile Consortium

Shuhari and Disciplined Agile Certification
Module 2 - Agile Foundations Shuhari and Disciplined Agile Certification At the shu stage you are beginning to learn the techniques and philosophies of disciplined agile development. Your goal is to build a strong foundation from which to build upon. At the ha stage you reflect upon and question why disciplined agile strategies work, seeking to understand the range of strategies available to you and when they are best applied. At the ri stage you seek to extend and improve upon disciplined agile techniques, sharing your learnings with others. We have adopted a Shuhari strategy for this certification program. Shuhari is a martial arts concept that represents the stages of someone's learning: Shu (Learn). At the shu stage you are beginning to learn the techniques and philosophies of disciplined agile development. Your goal is to build a strong foundation from which to build upon. This beginner stage of learning is represented by the DA and CDA designations. Ha (Detach). At the ha stage you reflect upon and question why disciplined agile strategies work, seeking to understand the range of strategies available to you and when they are best applied. This intermediate stage of learning is represented by the CDAP designation. Ri (Transcend). At the ri stage you seek to extend and improve upon disciplined agile techniques, sharing your learnings with others. This "master" stage of learning is represented by the CDAC designation. © Disciplined Agile Consortium © Scott Ambler + Associates

Got Discipline? DisciplinedAgileConsortium.org
DisciplinedAgileDelivery.com Disciplined Agile Delivery Please get involved with the DAD conversation. © Disciplined Agile Consortium

Recommended Resources

How to Successfully Apply Agile at Scale in the Enterprise

Similar presentations

Presentation on theme: "How to Successfully Apply Agile at Scale in the Enterprise"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

How to Successfully Apply Agile at Scale in the Enterprise

Similar presentations

Presentation on theme: "How to Successfully Apply Agile at Scale in the Enterprise"— Presentation transcript:

Similar presentations

About project

Feedback