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 Mark Lines Managing Partner mark@scottambler.com Mark_Lines © Scott Ambler + Associates © 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 © Scott Ambler + Associates

© Scott Ambler + Associates ARE YOU STRUGGLING WITH DEALING WITH THE COMPLEXITY OF SOFTWARE DEVELOPMENT? © Scott Ambler + Associates

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). © Scott Ambler + Associates 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…. © Scott Ambler + Associates

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 © Scott Ambler + Associates Twitter: @scottwambler

© Scott Ambler + Associates ARE YOU REALLY AGILE? © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © 2012 Scott W. Ambler www.ambysoft.com/surveys/

© 2012 Scott W. Ambler www.ambysoft.com/surveys/ 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 © 2012 Scott W. Ambler www.ambysoft.com/surveys/

Why agile? Higher success rates Detailed results online at www.ambysoft.com/surveys/ 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. 90-100% 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 Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/

Why agile? It works better Scale of -10 to +10 Detailed results online at www.ambysoft.com/surveys/ 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 Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/

Introduction to Disciplined Agile Delivery 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. This manifesto is the work of the organization created as the “Agile Alliance”. The Agile Manifesto is a set of principles put forth by a group of software development thought leaders that were frustrated with past project failures resulting from overly structured and bureaucratic processes. The 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 Source: www.agilemanifesto.org © Scott Ambler + Associates © Scott Ambler + Associates

But… DAD Extends Agile Thinking Introduction to Disciplined Agile Delivery 19/04/2017 But… DAD Extends Agile Thinking Solutions, not just software Stakeholders, not just customers These enhancements reflect the realities faced by most Disciplined Agile Delivery (DAD) teams. The changes that DAD suggests for the Agile Manifesto are straightforward: Where the original manifesto focused on software development, a term that too many people have understood to mean only software development, we suggest that it should instead focus on solution delivery. Where the original manifesto focused on customers, a word that for too many people appears to imply only the business stakeholders, we suggest that it focus on the full range of stakeholders instead. Where the original manifesto focused on development teams, we suggest that the over- all organizational ecosystem and its improvement be taken into consideration. The organizational ecosystem, not just development teams © Scott Ambler + Associates © Scott Ambler + Associates

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 development 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 © Scott Ambler + Associates

Criteria for a Disciplined Agile Team Introduction to Disciplined Agile Delivery 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 The slide lists criteria to determine if a project team is taking a disciplined approach to agile. Important: Each criterion is relative. For example, regular basis varies by team (every two weeks, ever four weeks, …) Survey says: Business value: 94% Validation: 87% Stakeholder collaboration: 95% Self organization: 56% Improvement: 88% All 5: 53% Everything but self organization: 72% Source: 2010 How Agile Are You Survey, www.ambysoft.com/surveys/ © Scott Ambler + Associates © Scott Ambler + Associates

How Agile Are Teams Claiming to Be Agile? Introduction to Disciplined Agile Delivery 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% Source: SAA 2013 How Agile Are You? Survey © Scott Ambler + Associates © Scott Ambler + Associates

ARE YOU GETTING THE RESULTS THAT YOU EXPECTED? © Scott Ambler + Associates

Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/ 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 Copyright 2011 Scott W. Ambler www.ambysoft.com/surveys/

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 © Scott Ambler + Associates

© Scott Ambler + Associates HOW DOES DISCIPLINED AGILE DELIVERY (DAD) ADDRESS THE GAPS IN MAINSTREAM AGILE METHODS? © Scott Ambler + Associates

Disciplined Agile Delivery (DAD) Introduction to Disciplined Agile Delivery Disciplined Agile Delivery (DAD) Disciplined Agile Delivery (DAD) 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 From this definition, you can see that the DAD process framework has several important characteristics. These characteristics are: People first Learning oriented Agile Hybrid IT solution focused Goal-driven Delivery focused Risk and value driven Enterprise aware © Scott Ambler + Associates © Scott Ambler + Associates

Disciplined Agile Delivery: The Foundation for Scaling Agile Compliance Domain Complexity Technical Complexity Geographic Distribution Team Size Organizational Distribution Disciplined Agile Delivery (DAD) Scrum Lean Kanban XP Agile Modeling And more… SAFe Outside In Dev. DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner. © Scott Ambler + Associates

© Scott Ambler + Associates Scrum 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 © Scott Ambler + Associates

Full Delivery Lifecycle: A High-Level View © Scott Ambler + Associates

The Scrum-Based Basic/Agile Lifecycle © Scott Ambler + Associates

DAD Lifecycle: Advanced/Lean © Scott Ambler + Associates

The Phases Disappear Over Time First release: Inception Construction Transition Second release: I Construction T Third release: I Construction T Nth+ releases: C T . © Scott Ambler + Associates

DAD Lifecycle: Continuous Delivery © Scott Ambler + Associates

© Scott Ambler + Associates DAD is Goal-Driven © Scott Ambler + Associates

© Scott Ambler + Associates Goal Driven Approach Advantages Disadvantages Considerations Goal Issue Option Default Option * * Source Team size Team structure Team members Geographic distribution Supporting the team Availability Form the Initial Team Co-located Partially dispersed Fully dispersed Distributed subteams © Scott Ambler + Associates

Goal: Develop Common Vision Introduction to Disciplined Agile Delivery 19/04/2017 Goal: Develop Common Vision Project wikis are commonly used. © Scott Ambler + Associates © Scott Ambler + Associates

Another example - Goal: Secure Funding © Scott Ambler + Associates

© Scott Ambler + Associates Goal – Secure Funding © Scott Ambler + Associates

Goal – Secure Funding (cont.) © Scott Ambler + Associates

Introduction to Disciplined Agile Delivery 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 © Scott Ambler + Associates © Scott Ambler + Associates

Disciplined Agile Delivery (DAD) Roles Introduction to Disciplined Agile Delivery Disciplined Agile Delivery (DAD) Roles Primary Roles Team Lead Product Owner Team Member Stakeholder Architecture Owner Secondary Roles (for scaling) Independent Tester Specialist Domain Expert Technical Expert Integrator 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 © Scott Ambler + Associates © Scott Ambler + Associates

Primary Roles on DAD Teams Disciplined Agile Delivery: Adopting 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 Stakeholder Includes the customer but also other stakeholders such as Project Sponsor, DevOps, architecture, database groups, governance bodies © Scott Ambler + Associates © Scott Ambler + Associates

Secondary Roles on DAD Teams Disciplined Agile Delivery: Adopting DAD Secondary Roles on DAD Teams “The secondary” DAD roles typically occur at scale Specialist Someone in a specialist role, such as business analyst, program manager, or enterprise architect Domain 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 Independent Tester A test/quality professional outside of the team who validates their work. Integrator Someone responsible for the operation of the overall team build © Scott Ambler + Associates © Scott Ambler + Associates

© Scott Ambler + Associates HOW DO DAD TEAMS WORK? © Scott Ambler + Associates

The DAD Inception Phase Also known as: project initiation, startup phase, iteration zero Summary of goals: Clarify business problem Identify viable technical solution Plan the approach Setup the work environment and team Gain stakeholder concurrence that it makes sense to proceed with chosen strategy The average agile team invests about four weeks performing these activities* * 2009 Agile Project Initiation Survey, Ambler © Scott Ambler + Associates

Industry Data: Inception Activities Introduction to Disciplined Agile Delivery 19/04/2017 Industry Data: Inception Activities Source: http://www.ambysoft.com/surveys/projectInitiation2009.html Source: Ambysoft 2009 Agile Project Initiation Survey © Scott Ambler + Associates © 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 © Scott Ambler + Associates © Scott Ambler + Associates

© Scott Ambler + Associates The Inception phase © Scott Ambler + Associates

The Construction Phase Goals: Produce a potentially consumable solution Address changing stakeholder needs Move closer to deployable release Improve quality Prove architecture early © Scott Ambler + Associates

The Construction phase © Scott Ambler + Associates

Construction Iteration Lengths The average construction iteration length is 2.3 weeks for experienced teams Heuristics: Shorter is generally better than longer Teams at scale may require slightly longer iterations Source: Ambysoft November 2010 Agile State of the Art Survey © Scott Ambler + Associates

A Construction Iteration © Scott Ambler + Associates

A Typical Day of Construction © Scott Ambler + Associates

© Scott Ambler + Associates The Transition Phase Phase goals Ensure the solution is consumable Deploy the solution Ongoing goals Fulfill the project mission Improve team process and environment Grow team members Leverage and enhance existing infrastructure Address risk © Scott Ambler + Associates

Copyright 2010 Scott W. Ambler www.ambysoft.com/surveys/ 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. 12+ weeks taken as 14 weeks. Source: Ambysoft November 2010 Agile State of the Art Survey Copyright 2010 Scott W. Ambler www.ambysoft.com/surveys/

© Scott Ambler + Associates The Transition phase © Scott Ambler + Associates

HOW DO YOU GOVERN AGILE PROJECTS? © Scott Ambler + Associates

Governance Should Address 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 © Scott Ambler + Associates

Why Traditional Governance Strategies Won’t Work 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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

© Scott Ambler + Associates DAD Milestones Milestone Fundamental Question Asked Stakeholder consensus Do stakeholders agree with your strategy? Proven architecture Can you actually build this? Project viability Does the project 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? © Scott Ambler + Associates

DAD 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 © Scott Ambler + Associates

© Scott Ambler + Associates 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 © Scott Ambler + Associates

© Scott Ambler + Associates 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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

WHAT DO YOU NEED TO DO TO SUCCEED? © Scott Ambler + Associates

© Scott Ambler + Associates Why Change is Hard © Scott Ambler + Associates

Impediments You May Encounter People may resist: Collocation Transparency Accountability Sustained pace of agile Collaborative work Common cultural challenges: Perfectionist behavior (gold platers) Resistance to building without a detailed specification Over specialization of roles Preference for a traditional/serial process Different cultures within teams © Scott Ambler + Associates

Adoption Primary Challenge 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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

© Scott Ambler + Associates 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 © Scott Ambler + Associates

General Adoption Advice for Team Members 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 © Scott Ambler + Associates

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 © Scott Ambler + Associates © 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 © Scott Ambler + Associates

WE CAN HELP! A SELECTION OF COURSES AND SERVICES © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

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 © Scott Ambler + Associates

Disciplined Agile Certification Module 2 - Agile Foundations Disciplined Agile Certification www.DisciplinedAgileConsortium.org Disciplined Agile Yellow Belt Indication that the person is new to disciplined agile but eager to learn Beginner certification Credit for existing certifications such as CSM, SAFe Disciplined Agile Green Belt Indication that the person is striving to be a professional Potential to be a junior coach Intermediate certification Disciplined Agile Black Belt Indication that the person is an expert Often a senior coach, instructor, or agile transformation lead Expert certification Active in the DAD community © Scott Ambler + Associates © Scott Ambler + Associates

Got Discipline? Context Counts DisciplinedAgileConsortium.org DisciplinedAgileDelivery.com ScottAmbler.com Context Counts

Recommended Resources © Scott Ambler + Associates