Disciplined Agile Delivery: Workshop Overview © Scott Ambler +

Disciplined Agile Delivery: Workshop Overview

Advanced Disciplined Agile Delivery Workshop Overview

Mark Lines Scott W. Ambler [email protected] [email protected] Mark_Lines scottwambler

Objectives of this Workshop

• To learn what the Disciplined Agile Delivery (DAD) process framework is and how it compares to other agile methods • To learn how common development activities are addressed throughout a disciplined agile project • To discover how a goal-driven approach provides a non-prescriptive, scalable foundation for agile solution delivery • To learn what it means to scale agile approaches • To learn how to adopt disciplined agile strategies

How we will learn…

• This is a workshop, not a lecture

• Ask questions – Lots of discussion time is built into the schedule

• Many labs are built into the workshop, to learn by doing

• You are going to have fun, we promise!

Introductions

• Your name and current role • Your current and/or recent project • Your experience with agile • One thing that you believe to be true about agile development • One question about agile that still puzzles you

Audience

Anyone willing to learn with an open mind Agile knowledge is necessary Agile development experience is not necessary, although very useful

Agenda

• Day 1: – Introduction to DAD – DAD Roles: A Deeper Look – Activities throughout the lifecycle – Governing DAD teams • Day 2: – DAD as a foundation from which to scale agile – Scaling DAD – Transitioning to DAD

Disciplined Agile Delivery Introduction to DAD

Learning Objectives for this Module

• Understand what DAD is and why we need it

• Discover why DAD is called a “process decision framework”

• Understand the basic and advanced DAD Lifecycles

• Learn how DAD is goal-driven

• To be introduced to the three phases of the DAD lifecycle

Agenda

• Disciplined Agile Delivery (DAD) • Characteristics of Good Teams • A Hybrid Framework • Potential DAD Lifecycles • Comparing Terminology • Enterprise Awareness • Goal-Driven, Not Prescriptive • How it Works in Practice • Tailoring and Scaling Agile

Discussion: What Are You Doing on Agile Projects?

• What agile projects have you been on? • What was different compared with non-agile ones? • What was the same? • What types of activities you do to initiate the project and how long did it take? (e.g. Did you do any initial modeling or planning? Did you need to get provide estimates go get funding? Other activities?) • What activities did you do during construction? (e.g. How did you approach documentation? Planning? Testing?) • What did you need to do to deploy/release your solution into production? How long did it take?

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

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

Characteristics of Good Teams

• The majority of team members should be “generalizing specialists” – Also known as “T-Skilled” people

• DAD teams and team members should be: – Self-disciplined , in that they commit only to the work which they can accomplish and then perform that work as effectively as possible. – Self-organizing , in that they will estimate and plan their own work and then proceed to collaborate iteratively to do so. – Self-aware , in that they strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.

DAD is a Hybrid Framework

DevOps …and more Extreme Outside In Dev. Agile Data 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.

Full Delivery Lifecycle: A High-Level View

DAD Lifecycle: Basic/Agile

DAD Lifecycle: Advanced/Lean

The Phases Disappear Over Time

First release: Inception Construction Transition

Second release: I Construction T

Third release: I Construction T . . . Nth + releases: C T C T C T C T

DAD Lifecycle: Continuous Delivery

Comparing DAD and Scrum Terminology

DAD Term Scrum Term Iteration Sprint Team lead ScrumMaster * Coordination meeting (Daily) Scrum meeting Retrospective Sprint retrospective Demo Sprint demo

* These roles aren’t completely the same, but close

Discussion: Enterprise Awareness

• What other teams might an agile team need to interact with in your organization? • Do these teams work in an agile manner? If not, what are you doing to address this? • What information do your agile teams need to provide to senior management for governance purposes? Why? • Are your agile teams expected to conform to an existing technical architecture? Organizational business vision? If so, how is this supported? • Do you have coding guidelines to follow? Data guidelines? Usability? Security? Other? How are they supported or enforced? • If you were CEO for a day, what would you do to address these issues more effectively?

DAD is Goal-Driven

Disciplined Agilists Take a Goal Driven Approach

Advantages Option Goal * Issue * Disadvantages Default Option Considerations

Explore the Initial Source Scope Team size Team structure Form the Co-located Team members Initial Team Partially dispersed Geographic distribution Fully dispersed Supporting the team Address Changing Distributed subteams Availability Stakeholder Needs

Goal: Develop Common Vision

Exercise: Goal Driven

• Get into small teams of 5-8 people • For 10 minutes, discuss: – Are the goals for Inception reasonable? Why or why not? – What factors will affect the amount of work and time required to address the goals of the Inception phase? – Are the goals of Construction reasonable? Why or why not? – Assuming that you need to meet those goals every iteration, what factors will affect the length of a construction iteration? – What do you think the differences are in the way that teams work when they have a four week iteration compared to a two week iteration? Compared to a one week iteration? – Are the goals for Transition reasonable? Why or why not? – How long do teams in your organization take to deploy into production today? What would they need to do to be able to deploy a new release once a month? Once a week? Once a day?

The Agile 3C (Coordinate-Collaborate-Conclude) Rhythm

Release rhythm Inception Construction Transition

Day to weeks Several iterations Hours to weeks

Iteration rhythm Iteration Iteration wrap Development planning up A few hours Several days A few hours

Coordination Daily rhythm Daily Work Stabilize Meeting A few minutes Several hours Varies

Coordinate Collaborate Conclude

The Inception phase

The Construction phase

A Construction Iteration

A Typical Day of Construction

The Transition phase

Context Counts – Tailoring and Scaling Agile

Disciplined agile delivery with one or more complexity factors: ° Large teams Agility ° Geographically distributed teams at ° Compliance Scale ° Domain or technical complexity ° Cultural/organizational issues ° Organizational distribution

• Delivery focus Disciplined • Risk-value driven lifecycle Agile • Self-organization with appropriate governance Delivery • Goal driven • Enterprise aware • Construction focus Agile • Value driven lifecycle • Self-organizing teams • Prescriptive • Project team aware

Group Exercise: What Have You Learned?

• Get back into your teams

• Take 10 minutes to answer the following questions: – What three new things have you learned about agile delivery? – What three new things have “freaked you out”? – What three impediments does your organization face when adopting these new techniques? – What three new ideas still puzzle you?

Module Summary

• DAD adds value to existing mainstream agile methods in these ways: – Full lifecycle coverage of practices – Recognition of project phases and lightweight milestones – Removal of proprietary terminology – Addresses enterprise concerns such as governance, enterprise authorities – Foundation for scaling agile beyond small co-located teams

Disciplined Agile Delivery “Traditional Activities” Through the Lifecycle

Learning Objectives for this Module

• Identify common challenges with communicating agile strategies to traditionalists

• Understand how traditional activities are still addressed via a disciplined agile approach

• Give you a flavor of potential agile practices/strategies used to address traditional activities in a more effective manner

Agenda

• Traditional software development • This activity is so important… • Traditional activities and DAD

Traditional Software Development © Scott Ambler + Associates 4

The Traditional “V” Lifecycle

Traditional activities are explicitly called out Traditional roles are defined around these activities

Where Do Traditional Activities Occur?

Exercise: Does This Actually Work?

• This is a group exercise

• Instructions – You have five minutes – The traditional lifecycle makes it clear when activities such as analysis, architecture, design, and testing occur – The agile lifecycles do not make it very clear – Choose one of the activities (analysis, …) listed above and discuss how that activity potentially occurs, and to what extent, through the agile lifecycle – What are the advantages and disadvantages when compared with the traditional approach?

This Activity is So Important…

Continuous Activities

• In agile, – Analysis is so important we do it every day. – Design is so important we do it every day. – Testing is so important we do it every day. – and so on

• This occurs because: – Our stakeholder’s understanding of what they want evolves over time – Our understanding of the solution evolves over time – The technology, including tools, evolves over time – The business environment evolves over time

• We can no longer afford to risk treating important activities such as architecture, design, testing, and more as mere phases

Generalizing Specialists

Specialists have deep skills in a single specialty

Generalists have broad skills in a range of specialties

Generalizing specialists have broad skills in a range of disciplines PLUS deep skills in one or more specialities – these are also called “T-skilled” people

True experts have deep skills in many specialties

Becoming a Generalizing Specialist

Ideally, agile teams are staffed mostly with generalizing specialists because that enables collaboration Many traditional IT professionals are specialists (business analysts, testers, programmers, …) With training, coaching, and non-solo development today’s specialists can become tomorrow’s generalizing specialists

Exercise: My Role is So Important…

• Pair up

• Instructions: – This is a role playing exercise – One person will play the role of a traditional: • Business Analyst • Solution/Application Architect • Technical Writer – The traditionalist doesn’t believe the agile approach will work, and they have twenty years of “successful” traditional experience that backs up this assertion – The other person will play the role of an agile coach – For five minutes, have a back and forth discussion with your pair – At the end, identify three solid points that favor the adoption of an agile approach and three solid points against it

Traditional Activities and DAD

Project Initiation: The Inception Phase

Analysis Throughout Construction

Active stakeholder Look-ahead modeling participation throughout for upcoming complex Discuss requirements Construction during iteration work items planning/modeling Identify new needs during demos

Analyze incoming requests from production

Agile Analysis Strategies

• Initial requirements envisioning • Look-ahead modeling • Active stakeholder participation • Inclusive modeling • Just in time (JIT) model storming • Work in priority order • Executable specifications • Smaller is better • Adopt stakeholder terminology • Question traceability • Travel light

Architecture Throughout Construction Architecture Architecture owner facilitates handbook and models architectural decisions updated as required throughout Construction Architecture spikes Architectural to explore a vision guides technical issue development efforts

Reduce risk early by proving the architecture works

Agile Architecture Strategies

Look beyond technology Initial requirements envisioning Initial architecture envisioning Prove the architecture with working code Architecture spikes Think about the future, but wait to act Architects also code Architecture owners, not architects Travel light Take a multi-view approach © Scott Ambler + Associates 18

Design Throughout Construction Test-Driven Design (TDD) throughout Construction Discuss design implications during iteration Look-ahead modeling planning/modeling for upcoming complex work items

Consider design issues of incoming requests from production

Agile Design Strategies

• Travel light • Agile designs emerge • Keep it as simple as possible • Executable specifications • Prove it with code • Inclusive modeling • Just in time (JIT) model storming • Take a multi-view approach • Designers should also code (and coders also design)

Project Management Throughout Construction

Look-ahead planning for upcoming iteration(s) Team lead facilitates detailed planning

Update task board to visualize project status

Share updated release plan and estimates Explicit milestone with stakeholders reviews © Scott Ambler + Associates 21

Agile Project Management Strategies

• Be prepared to abandon many of the project management artifacts of yesteryear and streamline the rest • Adopt key philosophies: – Lead over manage – Motivate over command – Enable over control • Help teams to self organize • Protect your team • Get teams the resources that they need • Planning is important, plans not so much

Technical Writing Throughout Construction

Deliverable documentation updated via Continuous Documentation practice Deliverable documentation available as part of solution

Agile Documentation Strategies

• Document continuously • Work closely with the actual audience of the document • Document as a last resort • Distinguish between deliverable documentation and disposable project • Active stakeholder participation • Describe good things to know • Keep documents concise • Invest in documentation only if you intend to invest in maintaining it

Testing Throughout Construction

Whole team testing throughout Construction Parallel independent testing as needed

Acceptance and usability feedback from stakeholders

Agile Testing and Quality Strategies

• Whole team testing • Test often and early • Independent testing • Executable specifications • Test-driven development (TDD) • Acceptance TDD/Behaviour Driven Development (BDD) • Continuous integration (CI) • Iteration demos • All-hands demos • Light weight reviews • Common development guidance • Refactoring (code, database, UI, …)

User Experience (UX) Throughout Construction Active stakeholder participation throughout Look-ahead modeling Discuss usability Construction for upcoming complex during iteration work items planning/modeling Usability testing

Concrete feedback from demos

The Transition Phase

Discussion: Transitioning Traditional Professionals

• What challenges do you see with transitioning traditional IT professionals to a more agile way of working? • How can you address those challenges? • Is everyone going to be able to make this transition? • Does everyone need to make the transition?

Module Summary

• Traditional activities such as analysis, design, testing and others are so important that agilists do them every single day • Any given activity may be performed for a few minutes each day • Agile teams don’t require someone in a specialized role to perform a given activity • Most agilists are generalizing specialists • Agile teams address activities such as analysis, architecture… with different, and often better, techniques than traditional teams once did

Disciplined Agile Delivery Roles in DAD

Learning Objectives for this Module

• Understand the primary DAD roles and their responsibilities

• Understand the secondary DAD roles

Agenda

• Scrum roles • Primary DAD roles • Secondary DAD roles

Exercise: Are the Scrum Roles Sufficient?

• This is a group exercise

• Instructions: – You have 5 minutes Scr um – Consider the roles of Scrum Master, Product Owner, and Team Master Member promoted by Scrum – Do these roles cover the entire gambit of what an agile team may need to do? – Who is responsible for technical decisions when the team doesn’t agree? Product Owner – Where do you get domain information when the Product Owner doesn’t know it? – Who helps you when you need outside assistance with installing or tuning an unfamiliar technology? – How have you organized agile teams in actual practice? Team Member

DAD Roles in a Nutshell

Primary DAD Roles

Team Lead Product Team Stakeholder Architecture Owner Member Owner

• Team Lead replaces Scrum Master • Stakeholder introduced because the Product Owner can’t possibly know everything about the domain • Architecture Owner is introduced because someone needs to facilitate key technical decisions

Stakeholder

• Stakeholder is more than a customer • Anyone impacted by the outcome of the system • Types of stakeholders – End users: Users of the system – Principals: Decision makers that pay for and put the system to use – Partners: People who make the system work in production – Insiders: Members of the development team and people who provide business and technical services to the team

Product Owner

• The Stakeholder “proxy” • Go-to person for information on the solution requirements • Prioritizes all work for the team • Participant in modeling and acceptance testing • Has access to expert stakeholders • Facilitates requirements envisioning and modeling • Educates team in business domain • May demonstrate solution to key stakeholders • Monitors and communicates status to stakeholders • Negotiates priorities, scope, funding, and schedule

Team Member

• Is a cross-functional, generalizing specialist • On small teams every team member is typically a developer, but on larger teams non-developers may appear • Volunteers to do any work that allows the team to most efficiently delivery the work committed to for the iteration • Seeks to both learn about other specialties as well as coach others on their own specialty • Goes to the product owner for domain information and decisions • Works with the architecture owner to evolve the architecture • Follows enterprise conventions and leverage and enhance the existing infrastructure

Team Lead

• Responsible for the effectiveness and continuous improvement of the team’s process • Facilitates close collaboration between team members • Keeps the team focused on the project vision and goals • Removes impediments for the team and escalates organizational impediments • Protects the team from interruptions and external interferences • Maintains honest communication between everyone on the project • Coaches others in the use of agile practices • Prompts the team to discuss and think through issues when they are identified • Facilitates decision making (but does not make decisions or mandate internal team activity)

Additional Project Manager related Team Lead Responsibilities

• Assessing team members • Managing the project budget • Producing project status related metrics – E.g. Iteration burndowns, defect trend charts, taskboards

Architecture Owner

• Guides the creation and evolution of the solution’s architecture • Mentors and coaches team members in architecture practices and issues • Understands the architectural direction and standards of your organization and ensures that the team adheres to them • Ensures the system will be easy to support by encouraging appropriate design and refactoring • Ensures that the system is integrated and tested frequently • Has the final decision regarding technical decisions, but doesn’t dictate them • Leads the initial architecture envisioning effort

Exercise: Exploring the Architecture Owner Role

• This is a group assignment

• Instructions: – You have five minutes for Part 1 and five for Part 2 – Part 1: • Organize into the following roles: Architecture Owner, Developers 1-2 and everyone else • Work through the following scenario: The team needs a garden shed. Developer 1 wants to buy a shed at the local hardware store. It’s a bit too small but it’s fast and cheap. Developer 2 wants to build a shed using wood that would fully meet the team needs. Both Dev1 and Dev2 are adamant they are correct, everyone else wants to get on with things. The Architecture Owner needs to help the team resolve the dispute. – Part 2: • Discuss actual experiences on IT projects where similar situations occurred. How were they resolved?

Secondary DAD Roles

Independent Specialist Domain Technical Integrator Tester Expert Expert

These secondary roles occur for scaling purposes

The are needed when the situation becomes too complex for people in the primary roles to address effectively

Independent Tester

• Some DAD teams are supported by an independent test team working in parallel that validates their work throughout the lifecycle. • This independent test team is typically needed for teams working in complex domains, using complex technology, or addressing regulatory compliance issues.

Specialists and Experts

Specialists, such as Program Managers or Business Analysts, may be needed at scale. This occurs when the situation is sufficiently complex to require someone focused on that specialty. Specialist

Domain experts, such as a Tax Accountant or Air Traffic Controller, will often support a Product Owner to work through the detailed nuances of the domain. Domain Expert

Technical experts, such as a Security Engineer or Senior Database Administrator, will often support a team on a limited or ongoing part-time basis so that the team can leverage their technical skills. Technical Expert

Integrator

• Some solutions are complex: – Several platform technologies – Many subsystems, services, or data sources – New hosting technologies such as clouds and SAAS • For larger agile teams, many if not all of these solution components will evolve in parallel • The end result is that the build becomes very complex • A tiered build, with builds for sub-components and an overall solution build, may be required • Keeping the overall solution build may require one or more people actively working in the role of integrator

Discussion: What Have You Seen?

• Have you already observed agile teams with people in these roles? • If so: – In what situations were they needed? – Was it difficult to get people to accept the need for them? – What worked well? What didn’t?

Module Summary

• The DAD process decision framework takes a much wider scope than agile methods such as Scrum or Extreme Programming and as a result promotes a wider range or roles

• The five primary roles are typically sufficient for disciplined agile teams that do not face too many scaling complexities

• The five secondary roles are typically applied on disciplined agile teams working at scale

Disciplined Agile Delivery Governing Disciplined Agile Delivery Teams

Learning Objectives for this Module

• Learn what governance should address

• Review governance aspects built into DAD

• Recognize potential problems with traditional approaches to governance

• Learn how to govern a DAD project

• Discover why disciplined agile teams are easier to govern than traditional teams

Agenda

• What should governance address? • Scoping governance • Why governance? • Traditional governance • Governing agile teams • Governance and DAD

Exercise: Exploring Governance

• Get back into your teams

• For 10 minutes, discuss: – What does it mean to govern a team effectively? – Who are the stakeholders of your governance program? – How effective are your existing governance approaches? Really? – What are the three most important considerations when governing a development team?

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

Potential Scope of Governance

Corporate

Information Technology

Delivery/ Operations IT Investment Development

Infrastructure Data Security (Services, Cloud…)

Why is Governance Important?

• Sustain and extend your IT strategies and objectives, which in turn should reflect your corporate strategies and objectives • Determine how the company will execute its strategy by selecting and prioritizing the most valuable initiatives to undertake • Empower teams to carry out their work • Help to ensure that delivery teams: – Regularly and consistently create real business value – Provide appropriate return on investment (ROI) – Deliver consumable solutions in a timely and relevant manner – Work effectively with their project stakeholders – Work effectively with their IT colleagues – Adopt processes and organizational structures that encourage successful IT solution delivery – Present accurate and timely information to project stakeholders – Mitigate the risks associated with the project

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

Exercise: Examining Traditional Governance

• Get back into your teams

• For 10 minutes, discuss the traditional assumptions that conflict with agile (see previous slide). For each assumption: – Identify three reasons for why the assumption is clearly true – Identify three reasons for why the assumption is clearly false – If necessary, please take any fisticuffs outside ;-)

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

DAD Lifecycle: Basic/Agile

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?

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

Exercise: I Don’t Want to Be Governed

• This is a role playing exercise • Pair up • One person is an agile developer who doesn’t believe that governance is necessary • The other person is a senior manager who will argue for the need for agile governance • For five minutes, have a back and forth discussion with your pair • At the end, identify three solid points that favor governing agile teams and three solid points against doing so

Discussion: Aligning Delivery Governance

• What challenges exist aligning the governance approach promoted by DAD with: – Operations governance – Security governance – Data governance – Quality assurance (QA) governance – Technology governance – IT investment governance

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

Goal Question Metric (GQM)

The GQM process: 1. Develop a set of corporate, division and project business goals for productivity and quality 2. Generate questions that define those goals as completely as possible in a quantifiable way 3. Specify the measures needed to be collected to answer those questions and track process and product conformance to the goals 4. Develop mechanisms for data collection 5. Collect, validate and analyze the data in real time to provide feedback to projects for corrective action 6. Analyze the data to assess conformance to the goals and to make recommendations for future improvements

Exercise: Applying GQM to DAD

• Get back into your teams

• Pick three of the following potential goals: – Deploy in a timely manner – Spend IT investment wisely – Provide business value – Produce a quality solution – Reduce technical debt – Provide a healthy working environment – Regulatory compliance

• For each goal, identify: – At least 3 potential questions – At least 2 potential metrics to address each question

• You have five minutes

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

Discussion: Let’s Review!

• What are the key takeaways from this module? • What are potential improvements for your environment? • What concepts still puzzle you?

Module Summary

• Effective governance in knowledge-based endeavors is based on motivation and enablement, not command and control. • Agile project teams must be governed in an agile manner; a traditional strategy only increases project risk. • Agile teams are significantly easier to govern than traditional teams, but only if the people doing the governance are willing to act appropriately. • Effective metrics strategies focus on automated gathering supplemented with a few manually gathered measures as needed.

Disciplined Agile Delivery A Foundation for Scaling Agile

Learning Objectives for this Module

• Why mainstream methods need to be extended to support scaling

• What features of DAD provide a foundation for scaling

• Why context counts

Agenda

• A foundation for scaling agile • Full delivery lifecycle • Embracing a goal-driven approach • Enterprise awareness

A Foundation for Scaling Agile

The History of Disciplined Agile Delivery

• 2006: – Scott Ambler joined IBM Rational to help them to understand and scale agile software development techniques – Scott and his colleagues, including business partners, worked with customers around the world to help them adopt and scale agile strategies • 2007: – Scott begins his “agility@scale” blog on IBM DeveloperWorks to share his learnings • 2009: – Work begins on the DAD framework – IBM introduces the Agile Scaling Model (ASM) to explain what it means to scale agile • 2010: – IBM Whitepaper overviewing DAD published • 2011: – DisciplinedAgileDelivery.com • 2012: – Disciplined Agile Delivery book published in June • 2013: – DisciplinedAgileConsortium.org

Context Counts – Tailoring and Scaling Agile

A Full Delivery Lifecycle

The Scrum Construction Lifecyle

Full Delivery Lifecycle: A High-Level View

DAD Supports Multiple Lifecycles

Exercise: Compare and Contrast

• Pair up

• Instructions: – This is a role playing exercise – One person will play the role of a “Scrum true believer” who knows that the Scrum construction lifecycle provides a sufficient foundation from which to scale – The other person will play the role of “DAD true believer” who knows that a more robust delivery lifecycle is needed – For five minutes, have a back and forth discussion with your pair – At the end, identify three solid points that favor a full delivery lifecycle and three solid points against it

Embracing a Goal -Driven Approach

DAD is Goal-Driven

Disciplined Agilists Take a Goal Driven Approach

Advantages Option Goal * Issue * Disadvantages Default Option Considerations

Level of Initial Scope Detail

• BRUF (detailed specifications) • Requirements envisioning (lightweight specifications) • Goals driven • No modeling at all

Functional Requirements: Potential Model Types

Requirements Change Management

Exercise: Comparing Requirements Change Management Strategies

• Get back together in your groups

• Instructions: – You have 10 minutes – There are different wants to sort work items: • By business value • By risk • By dependency • Just in time (JIT) – For each strategy discuss: • Where you have used it in practice (if you have) • The advantages and disadvantages • When the strategy is applicable

Strategies for Initial Estimating

• Formal point counting • Planning poker (wide-band delphi) • Similar sized items • Educated guess by the team • Educated guess by an experienced individual • Cost/schedule set by the stakeholders

Exercise: Comparing Estimation Strategies

• Get back together in your groups

• Instructions: – You have 10 minutes – Share your experiences with any of the strategies listed on the previous slide – For each one, identify the what worked well, what didn’t work out so well, and why – Put the strategies in order of effectiveness

Enterprise Awareness

Disciplined Agile Teams Work Closely with Enterprise Professionals

• They consult with enterprise architecture (EA), portfolio management, data administration, … staff for guidance • The Architecture Owner may be part of your EA team • The Product Owner may be part of your business strategy team

Exercise: Agile Enterprise Architecture

• Get back together in your groups

• Instructions: – You have ten minutes – You’ve been tasked with developing a strategy for enterprise architects (EAs) to support agile development teams – How will this work? – What do the EAs need to do to support agile teams? – What do agile teams need to do to work with EAs effectively?

Share Your Learnings

• Retrospectives are a common strategy for agile teams to identify potential improvements • Measured improvement, tracking the effectiveness of a change, is an even better way • BUT, these are team-based strategies

• Disciplined agile teams share their learnings via: – Internal discussion forums – Shared wikis – Training sessions – Working closely with process improvement groups – And other strategies

Goal: Align With Enterprise Direction

Following Organizational Standards

• Agile “self-organizing” practices promotes team owning their process and being empowered to improving their practices themselves • However, organizational standards cannot be ignored • Standards can improve quality, consistency, supportability, and consumability of solutions across the organization • Examples of standards: – Development, database, user interface, and coding guidelines – Testing guidelines (eg unit test coverage) – Governance guidelines – Architecture guidelines – Asset reuse guidelines – Documentation guidelines

Goal: Leverage and Enhance Existing Infrastructure

Exercise: Follow My Standards

• Get back together in your groups

• Instructions: – You have five minutes – The operational database administration group wants to improve overall data quality within your organization. One aspect of this effort is to ensure that data sources follow a common set of guidelines. – How can the data administration group make this work with agile delivery teams?

Agile Governance

Module Summary

Agility • DAD provides a foundation from which to effectively scale at agile Scale

• A full delivery lifecycle provides end-to-end guidance for successful delivery

• A goals-driven approach enables you to tailor your approach Disciplined to meet the situation you find yourself in Agile Delivery • Enterprise awareness enables disciplined agile teams to take advantage of the existing organizational ecosystem Agile

Disciplined Agile Delivery Scaling DAD

Learning Objectives for this Module

• Explore what it means to scale in practice

• Learn why you may need to adopt a few “new” roles at scale

• Learn about “new” practices you may need to consider adopting at scale

• Explore how various scaling factors will affect your process strategy

Agenda

• What does it mean to scale? • Roles that support scaling • Practices that support scaling • Team size • Geographic distribution • Organizational distribution • Compliance • Domain complexity • Technical complexity • Some final thoughts

Context Counts – Tailoring and Scaling Agile

Scaling Factors

Exercise: Are You Applying Agile at Scale?

• This is a group exercise

• Instructions: – You have 10 minutes – Discuss your experiences, including both successes and failures, with applying agile strategies at scale – What fears do you have? Does your organization have? – What lessons have you learned? – From an “agile purist” point of view, what compromises have you made?

Scaling Requires…

• A disciplined approach – Full delivery lifecycle – Enterprise awareness – Goal-driven approach • A bit more up-front thinking – Explore the initial scope a bit deeper – Identify the initial technical strategy in a bit more detail • More sophisticated coordination – Individuals and interactions • More sophisticated governance – The greater the risk, the greater the need for effective governance • More sophisticated validation – Teams at scale are typically tackling harder problems • More sophisticated tooling

Other Tailoring Factors

People

People – Secondary DAD Roles

• “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

Leadership Teams

• Large teams are formed to tackle complex problems, and as a result coordination within large teams becomes complex • A “scrum of scrums” starts to fall about when there’s more than five subteams • Coordination typically needs to occur for: – Release coordination – Requirements dependencies – Technical dependencies

Practices

Keep Iterations Short

The average construction iteration length is 2.3 weeks*

1 week or less 15%

2 weeks 51%

3 weeks 15%

4 weeks 10%

> 4 weeks 2%

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

Development Intelligence

• Tools should be instrumented to automatically log important activities and thereby facilitate generate of metrics • Metrics are displayed in (near) real-time on a project dashboard • Should be non-intrusive to the team • Benefits – Transparency to all stakeholders, increasing trust – Increased team effectiveness with visibility into what team members are working on, status of builds – Information that can be used to assess effectiveness and justify process changes – Keeps team focused on delivering on their commitments to the stakeholders

IT Intelligence

• Automated dashboard that summarizes the status for all of IT • Shows the entire portfolio: – Potential/suggested endeavors – Ongoing development endeavors – Operational solutions • Drill down into: – Project details – Operational details – Support details

As a Customer I want to Initial Requirements Envisioning withdraw funds from an ATM so that I can go shopping • Your goals are to: 1. Identify and agree to the initial scope of your project 5 2. Develop the initial stack of requirements 3. Gather enough information to address initial scheduling and estimating concerns • Critical models for business application development: – Some sort of usage model (use cases, user stories, …) – Conceptual/domain model – Some UI sketches

Managing Multiple Backlogs/Work Item Lists

• There are always dependencies between requirements • Larger teams will be organized into smaller subteams • When individual backlogs are maintained for each team, the dependencies between requirements need to be managed by the respective Product Owners in a collaborative manner (hence the Product Owner team) • When a single backlog is maintained dependency management becomes easier but a more complicated requirements management tool will likely be required

Managing a Portfolio/Programme Backlog

• The DAD lifecycles explicitly show that “pre-delivery” work occurs in the form of identifying and prioritizing work • Part of portfolio/programme management is managing this backlog • Items on the backlog are potential (sub)projects or (sub)products • For the overall IT portfolio, a portfolio management team, typically made up of business architects and senior IT managers, are responsible for prioritizing this work • For a programme, the Product Owner team is responsible for prioritizing this work • Strategies for managing project-level work item lists can be applied at the portfolio/programme level

Initial Architectural Envisioning

• Your goals are to: 1. Identify and agree to a potential initial architecture of your system 2. Provide sufficient technical vision for estimating and scheduling concerns

• Critical models for business application development: – Some form of deployment diagram – A free-form “technology stack” diagram

API First

• To support a component team approach a clean architecture is identified early in a project • The interface of the components/services/… are defined in detail • This enables the component teams to proceed to safely develop the internals of the components in parallel • When interface changes are needed the Architecture Owners need to negotiate • This is called Contract Model in Agile Modeling

Test Suite API

• An extension to API first where the API is described as a collection of executable tests • Each component team publishes and maintains a black-box test suite for their components/services/… • Changes to the interfaces will still need to be negotiated

Parallel Independent Testing

Continuous Integration (CI)

• Continuous integration (CI) is reasonably common at the project level • To support CI at the programme level you very likely need to support it with someone(s) in the role of integrator and with parallel independent testing • CI at the portfolio level should be a goal of any IT organization that wants to truly transform itself

Continuous Deployment (CD)

IT Release Planning

• Your project/product release plan is constrained by your organization’s release process • IT release planning strategies include: – Release window/slot: A pre-defined period of time during which one or more teams may release into production. – Release train: A pre-defined release schedule which is effectively a collection of release windows. Commonly used on programmes to simplify release dependency management. – Release blackout periods: Times where teams are prevented from releasing into production due to increased risk within the business environment (e.g. busy times of year) • Teams will aim for a specific release window based on: – Availability of a release slot – Their release cadence – Dependencies with other teams

Team Size

Agile Experiences with Team Size On your (un)successful agile projects, how many IT team members were there?

IT Project Success Rates by Team Size

80% Iterative 68% 55% 83% Agile 70% 55% 74% Ad-Hoc 58% 40% 69% Traditional 61% 50%

Small Medium Large

Source: DDJ State of the IT Union Survey, July 2010

Small Teams (2 to 15 People)

Medium-Sized Teams (10 to 40 people)

Large Teams (30 or More People)

Organizational options: • Feature teams: A subteam works on a feature from end to end. • Component teams: A subteam does all the work for a specific component. • Internal open source: A component is developed via open source techniques.

Exercise: Process Tailoring

• Get back into your teams

• Instructions: – You have 15 minutes – Read the scaling scenario on the following slide – What is your general strategy for approaching this effort? – Consider how you would tailor the following four goals: • Explore initial scope • Identify initial technical strategy • Move closer to a deployable release • Coordinate activities – What “scaling” practices would you adopt? – What additional secondary roles may be required? – What potential risks concern you?

Large Team Scenario

• Your organization is initiating an agile team that is estimated to be close to 90 people during the construction effort. • This project will extend existing functionality to a mobile platform and your organization has successfully done this sort of work on smaller projects. • The team will be in the same building although spread out between two floors. • Each floor has space for about 50 to 60 people, but neither floor has space for the entire effort. • There are other people on both of these floors who cannot be moved. • In addition to the team, there are another 15 to 20 primary stakeholders. These stakeholders are also in the same building, although none are currently on the two floors allocated to your team. • The problem domain is reasonably well understood, although your stakeholders do not completely agree on priorities. • There are some existing data sources and system assets that your team may able to leverage as well as some reasonably well-written development guidelines. • One goal of this project is to put an infrastructure in place that can support future mobile application development. The existing infrastructure is not perceived as adequate for this goal.

Geographic Distribution

Agile Experiences with Geographic Distribution

On your (un)successful agile projects, how distributed were team members?

Success Rates for Geographically Distributed Development

71% Iterative 80% 74% 59%

70% Agile 79% 73% Average 55% Co-located

66% Near Located Traditional 73% Far Located 69% 55%

62% Ad Hoc 72% 65% 48%

Source: Dr Dobb’s 2008 Project Success Survey

Geographically Distributed/Dispersed Teams

Be Prepared to Invest in Travel

• Observation: – There are critical times that you need to get people together physically to work through important issues. This includes initial scoping, architecture envisioning, and planning as well as any strategy pivot points.

• Advice: – At least get senior team members together at the beginning to build rapport and to get going in the right direction – The developers need to understand the situation on the ground for their primary end users – The least expensive way to pay for travel is to actually pay for travel

• Potential challenges: – It is very easy to measure travel expenses – It is very difficult to measure the benefits of face-to-face communication

Organizational Distribution

Agile Experiences with Organizational Distribution Question: In which of the following situations has the organization (un)successfully applied agile techniques? (Please check all that apply)

Same division

Several divisions

Several countries

Contractors/consultants

Partner organizations

Outsourcing

0% 10% 20% 30% 40% 50% 60% 70% 80% Had Successes Had Failures Source: 2012 Agile Scaling Survey

Exercise: Process Tailoring

• Get back into your teams

Distribution Scenario

• Some people in senior management weren’t comfortable with your large agile team strategy that you recently pitched. They believe a smaller, distributed team is more appropriate. • The suggestion is to start with 7 people on the team at three different locations (Toronto, Atlanta, San Francisco) but then the team will grow to 35 for construction . • The construction team will have some people working from home (all based in North America) and some working at the three sites listed above. • Some of the development work will be outsourced to an India-based vendor. This vendor has deep experience in Agile development, although your organization has only worked with their traditional teams in the past. • You have the option to use another India-based vendor for testing. You have also worked with this vendor in the past in a traditional manner but do not know what their agile experience is. • The price per person on the Indian teams is between one-third to one-half that of people on the North American teams. • Your business stakeholders are located in Toronto and Los Angeles. IT stakeholders are located mostly in San Francisco, although some are in Toronto and Atlanta.

Compliance

• A team may be working in an environment with regulatory or self-imposed compliancy requirements • Examples of regulatory compliance include Sarbane Oxley (SoX), Dodd-Frank, and Food and Drug Administration (FDA) regulations • Self imposed compliancy may include CMMi, ISO, and ITIL • Any given team may need to comply to zero or more regimes • Compliancy regimes are not created equal • Read the regulations! • Compliancy generally entails: – A bit more documentation (but not much) – A defined process – Proof that you followed the process you said you would follow

Agile Experiences with Compliance On your (un)successful agile projects, was compliance applicable?

Note: Self imposed = CMMI, ISO, … Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 44

Domain Complexity

Agile Experiences with Domain Complexity Question: From the point of view of the problem/business domain, at what level(s) of complexity has the organization (un)successfully applied agile techniques? (Please check all that apply)

Pilot Projects

Straightforward

Medium complexity

Complex

High Risk

0% 10% 20% 30% 40% 50% 60% 70% 80% Had Successes Had Failures Source: 2012 Agile Scaling Survey www.ambysoft.com/surveys/ © Scott Ambler + Associates 46

Technical Complexity

Agile Experiences with Technical Complexity Question: In which technical situations has the organization (un)successfully applied agile approaches? (Please check all that apply)

Greenfield Stand-alone Package/COTS System integration Fix legacy systems Access legacy data Fix legacy data Single platform Multi-platform

0% 10% 20% 30% 40% 50% 60% 70% 80% Had Successes Had Failures

Exercise: Process Tailoring

• Get back into your teams

Complex Situation Scenario

• You’ve accepted a position at a new company and have been asked to lead a twenty-person agile team. This team is located in a single large room that has been used for agile projects in the past. Three walls are completely covered in whiteboards and another wall has both corkboard and whiteboard space. Your stakeholders are located in the same building as your team although are spread across three floors (one of which your team is on). • Your team has been asked to redevelop your existing customer service help desk. Today your help desk runs on several platforms (a mainframe COBOL application with an IMS database; a Visual Basic client/server solution with a SQL Server back end; a browser-based application running on Websphere with an Oracle database; a SAAS-based help desk) due to the fact that your company has acquired several competing companies in the past few years. There is no common data model and the same customer will appear in several systems right now. • Senior management at this organization wants to move away from SAAS-based implementations after their existing SAAS vendor had a near-death experience before being bought by a large computer services vendor wanting to grow in the SAAS space. • The solution must be both browser based as well as support several common mobile platforms.

Some final thoughts

Scaling From a Solid Foundation is Easier

• With a DAD-based approach, scaling becomes straightforward because a handful of process goals take the brunt of the tailoring: – Explore initial scope – Identify initial technical strategy – Move closer to a deployable release – Coordinate activities

Anti-patterns

• People challenges: – Agile purism – Agile doesn’t scale – Small scale coaching – We can’t do this

• Process problems: – Water-Scrum-Fall – Over specification

• Tooling challenges: – Small scale tooling – Documentation tools posing as scaling tools – Reduced collaboration due to reliance on tools

Disciplined Agile Delivery: The Foundation for Scaling Agile

Technical Compliance Domain Complexity Complexity Geographic Organizational Team Size Distribution Distribution

Outside In Dev. Unified Process And more… XP Agile Modeling Scrum Kanban Lean

Disciplined Agile Delivery (DAD)

DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner.

Context Counts: The Software Development Context Framework

The selection factors and scaling factors combined will affect how you tailor your process, team structure, and tooling

Module Summary

• We saw that there is more to scaling than dealing with large teams • DAD’s secondary roles start to appear at scale • There are agile practices that support scaling which typically are only adopted by teams that are dealing with scaling issues • The various scaling factors affect your process strategy and team structure differently – context counts!

Disciplined Agile Delivery What You’ve Learned

Agenda

• Summarizing DAD • What Still Puzzles You? • What You’ve Learned

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

DAD Lifecycle: Basic/Agile

DAD Lifecycle: Advanced/Lean

DAD Lifecycle: Continuous Delivery

DAD is Goal-Driven

Disciplined Agile Delivery: The Foundation for Scaling Agile

Organizational Organizational Domain Team Culture Distribution Culture Complexity Geographic Technical Team Size Compliance Distribution Complexity Extreme Outside In Dev. And more… Programming Unified Process Agile Modeling Scrum Kanban Lean

Disciplined Agile Delivery (DAD)

DAD leverages proven strategies from several sources, providing a decision framework to guide your adoption and tailoring of them in a context-driven manner.

Mapping Traditional Roles to Potential DAD Roles

Discussion: What Still Puzzles You?

• This workshop has potentially presented you with a lot of new ideas • It can be incredibly difficult to take in all of this material at once • So… is there anything that still puzzles you about Disciplined Agile Delivery (DAD)?

Exercise: What Have You Learned?

• Individually, on a sheet of paper, answer the following questions: – What three new things have you learned about agile delivery in general? – What three new things have you learned about scaling agile approaches? – What improvements in the way you approach agile project will you try to adopt when you’re back at work? – What still puzzles you?

A Disciplined Ending….

Please… – Take the opportunity to thank your teammates – we all learned together – Fill out the workshop evaluation form(s) – Turn in the evaluation(s) to the instructor

Thank You!

[email protected] [email protected] @scottwambler, @mark_lines

DisciplinedAgileDelivery.com ScottWAmbler.com AgileModeling.com AgileData.org Ambysoft.com EnterpriseUnifiedProcess.com

Recommended Resources

Initial Architectural Iteration Vision Iteration review & retrospective: Demo to Potentially stakeholders, Highest-Priority Release Operate and Consumable determine strategy for Working Identify, prioritize, Work Items solution into support solution solution next iteration, and Solution and select Iteration production in production Tasks learn from your projects Backlog Initial Initial experiences Iteration planning session to modeling, Requirements and Release select work items and identify Funding Initial vision planning, and Plan work tasks for current iteration and funding organization Feedback Enhancement Requests and Defect Reports Work Items

Inception Construction Transition One or more One or more short iterations Many short iterations producing a potentially consumable solution each iteration short iterations

Stakeholder consensus Project viability Sufficient functionality Production ready Proven architecture (several) Delighted stakeholders Initial New Architectural features Vision

Retrospective Replenishment Identify, prioritize, modeling session and select Business Value Learnings projects Initial vision Initial Operate and and funding modeling, Initial Release Fixed Delivery Date Daily work support solution planning, and Requirements solution into in production organization Work items are production pulled when Strategy Expedite capacity is available Feedback to address them Coordination Meeting Intangible Demo Options New features Enhancement Requests and Defect Reports

Inception Construction Transition Continuous stream of development Stakeholder consensus Sufficient functionality

Production ready Delighted stakeholders New Features

Retrospective Replenishment modeling session Business Value Learnings

Release Operate and Fixed Delivery Date Daily work solution support solution Work items are in production pulled when Strategy Expedite capacity is available Feedback to address them Coordination Meeting Intangible Demo Options New Work Enhancement Requests and Defect Reports

Construction T Continuous stream of development Sufficient functionality

Production ready Delighted stakeholders Goals for the Inception Phase Goals for Construction Phase Iterations Goals for the Transition Phase

- Form initial team - Produce a potentially consumable solution - Ensure the solution is - Develop common project vision - Address changing stakeholder needs consumable - Align with enterprise direction - Move closer to deployable release - Deploy the solution - Explore initial scope - Improve quality - Identify initial technical strategy - Prove architecture early - Develop initial release plan - Form work environment - Secure funding - Identify risks

Ongoing Goals

- Fulfill the project mission - Improve team process and environment - Grow team members - Leverage and enhance existing infrastructure - Address risk