Disciplined Agile Delivery: Extending Scrum to the Enterprise

�

MK PM�HalfͲday�Tutorial�11/11/2013�1:00�PM�

��

"Disciplined Agile Delivery: Extending Scrum to the

Enterprise" ��

Presented by:

Scott Ambler Scott Ambler + Associates

��

Brought�to�you�by:��

��

340�Corporate�Way,�Suite�300,�Orange�Park,�FL�32073�888Ͳ268Ͳ8770�ͼ�904Ͳ278Ͳ0524�ͼ�[email protected]�ͼ�www.sqe.com

Scott Ambler Scott W. Ambler + Associates

Scott Ambler works with organizations worldwide to help them improve their software processes. Scott is the founder of the Agile Modeling, Agile Data, Disciplined Agile Delivery, and Enterprise Unified Process methodologies, and creator of the Agile Scaling Model. A senior contributing editor with Dr. Dobb’s Journal, Scott is the coauthor of twenty-one books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, The Enterprise Unified Process, and Disciplined Agile Delivery. Visit his home page ScottAmbler.com and blog.

Scott W. AmblerSenior Consulting Partner

scott [at] scottambler.com

@scottwambler

© Scott Ambler + Associates 1

Disciplined Agile Delivery: Extending Scrum to the Enterprise


We’re going to cover a lot of ground

Ask questions at any time!



Agenda

• Disciplined Agile Delivery (DAD)• You Have Choices• What it Means to Scale Agile Delivery• Governing Agile Teams• Agile People at Scale• Agile Practices at Scale• Enterprise Agile• Parting Thoughts

Disciplined Agile Delivery


Group Exercise: Sharing Agile Experiences

• Organize into teams of 4-6 people• Take a few minutes to introduce yourselves to one another• For 5 minutes, discuss within the team:

– Practical experiences on agile teams– What types of activities you do to initiate the project? (e.g. Did you do any

initial modeling or planning? Did you need to get provide estimates go get funding? Other activities?) How long did it take?

– What activities did you do during construction? (e.g. How did you approach documentation? Planning? Testing? Architecture?)

– What did you need to do to deploy/release your solution into production? How long did it take?

• Someone needs to be a spokesperson for your team• A spokesperson will share a few key learnings with the larger group


Important, Empirical Observations


Solutions, not just software

Stakeholders, not just customers

The organizational ecosystem, not just development teams

8

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

© Scott Ambler + Associates

Scrum

Extreme Programming

LeanKanban

DAD is a Hybrid Framework


Unified Process Agile Modeling

Agile Data“Traditional”Outside In Dev.

DevOps …and more

DAD leverages proven strategies from several sources,providing a decision framework to guide your adoption and

tailoring of them in a context-driven manner.

SAFe

A High Level Lifecycle


Scrum Construction Lifecycle


A good start…

A Scrum Delivery Lifecycle


…but this is how agile teams actually work…

Unbranded Agile Delivery Lifecycle


…and it’s time to abandon the branding.

Governed Delivery Lifecycle


Disciplined agile teams are guided by senior management…

Disciplined Agile Delivery: Basic Lifecycle


…and realize they work in an organizational ecosystem.

Disciplined Agile Delivery: Lean Lifecycle


DAD doesn’t prescribe a single lifecycle…

The Phases Disappear Over Time


First release: Inception Construction Transition

Second release: I Construction T

Third release: I Construction T

Nth+ releases: C CT C C TT T

.

.

.

…and promotes continuous learning and improvement.

Disciplined Agile Delivery: Lean Continuous Delivery Lifecycle


A goodend goal

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

19© Scott Ambler + Associates


Governance is Built Into DAD

• Governance strategies built into DAD:– Risk-value lifecycle– Light-weight milestone reviews– “Standard” opportunities for increased visibility and to steer the team

provided by agile– Enterprise awareness– Robust stakeholder definition

DevOps Through the DAD Lifecycle


Inception Construction Transition

O&S = Operations & Support

Initial release planning includes

deployment

O&S staff stakeholders throughout

construction

Transition planning

throughout construction

O&S staff key decision makers

regarding production readiness

Support staff observes

stakeholder satisfaction levels

Deployment into production

Dev team implements O&S

oriented requirements

O&S staff stakeholders in initial modeling

sessions

DAD Teams Are Enterprise Aware

• DAD teams strive to leverage and enhance the existing organizational eco system wherever possible

• Implications:– Work closely with

enterprise groups– Follow existing roadmap(s)

where appropriate– Leverage existing assets– Enhance existing assets


What Does it Mean to Be Disciplined?

• In general, it requires discipline to follow many agile practices and philosophies

• But, it also requires discipline to:– Reduce the feedback cycle– Learn continuously– Deliver solutions incrementally– Be goal driven– Enterprise aware– Streamline Inception and

Transition efforts– Adopt agile governance strategies



You Have Choices

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


Strategies for Funding Projects


Fixed price/cost

Stage-gatefunding

Time andmaterials (T&M)

Continuous/Drip

Low T&Mplus delivery

bonuses

Group Exercise: Exploring Project Funding

• Choose one of the funding strategies from the previous slide


For five minutes, discuss the implications of the strategy:• How will the team behave regarding changing

requirements?• How will the team behave regarding schedule slippage?• How will quality of the end product potentially be

affected?• What risks are being placed on IT?• What risks are being placed on the business?

Disciplined Agilists Take a Goal Driven Approach


Goal IssueAdvantagesDisadvantagesConsiderations

* OptionDefault Option

*

Explore the Initial Scope

Form theInitial Team

Address Changing Stakeholder Needs

SourceTeam sizeTeam structureTeam membersGeographic distributionSupporting the teamAvailability

Co-locatedPartially dispersedFully dispersedDistributed subteams

Indicates a preference for the options towards the top

Goal: Secure Funding


Goal – Secure Funding


Goal – Secure Funding (cont.)


Strategies for Capturing Requirements Detail

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


Strategies for Functional Requirements


Goal: Explore the Initial Scope


Strategies for Change Management


Formal Change Management

Goal: Address Changing Stakeholder Needs


DAD is Process Goal-Driven


Scaling Agile© Scott Ambler + Associates 38

What Does it Mean to Scale Agile?


http://disciplinedagiledelivery.wordpress.com/2013/03/15/sdcf/

Team SizeTwo Hundreds

Geographic DistributionCo-located Global

Organizational DistributionSingle division Outsourcing

ComplianceNone Life critical

Domain ComplexityStraightforward Very complex

Technical ComplexityStraightforward Very complex

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


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



Governing Disciplined Agile Teams

Some Bold Claims Regarding Governance

Claim #1: Agile teams are being governed today

Claim #2: In many organizations the governance strategy is badly misaligned with agile

Claim #3: You deserve to be governed effectively

Claim #4: When you provide a coherent governance strategy to senior management you are much more likely to be governed

effectively


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


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: 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


Principles of Agile Governance

Collaboration over conformance

Enablement over inspection

Continuous monitoring over quality gates

Transparency over management reporting


DAD Milestones

Milestone Fundamental Question Asked

Stakeholder vision 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


Agile People at Scale


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


Large Teams


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.

Leadership Teams


• For large teams there are several coordination subteams:– Architecture Owners – Responsible for technical coordination– Product Owners – Responsible for requirements coordination– Project Management – Responsible for team coordination and management

• How it works:– Early in the project the respective visions are agreed to by key members of each

coordination team (plus others)– Throughout the project these teams coordinate their respective issues on a regular basis

with one another

Geographically Distributed/Dispersed Teams


Group Exercise: Enterprise Teams

• Get back together into your groups

• Take 5 minutes to discuss:– How do your agile delivery teams interact with

enterprise teams that provide cross-team services?– Consider enterprise teams such as:

• Enterprise Architecture• Portfolio management• Reuse/asset management• Infrastructure/operations and support• Data management


Pattern: Enterprise Team

• Individuals are members of both a delivery team and an enterprise team

• Common examples include:– Architecture Ownership Team (Enterprise

Architecture) – Product Ownership Team (Product Management)– Product Delivery Office (Portfolio Management)

• The delivery teams determine who will be in the enterprise role for them

• Potential scheduling challenges for the people in the enterprise roles due to multi-team commitments

• The leaders of each enterprise team may be a full time position


Enterprise Team

DeliveryTeam

Enterprise Team Example: Enterprise Architecture


• Responsible for developing the architecture/technology roadmap for your organization

• Delivery teams will determine who the architecture owner (AO) is, and that person becomes part of the AO team

• The AO team meets regularly to evolve the roadmap based on the hands-on learnings from the AOs

• Often called the enterprise architecture team

Pattern: Specialized Services Team

• Specialized services teams fulfill requests from delivery teams

• Common examples of specialized services:– Infrastructure/network– Database administration– Security– Facilities

• The specialized services team will often have a service level agreement (SLA) that the work to

• Potential for the services team to become a bottleneck

• They may supply specialists on a short term basis to some delivery teams


DeliveryTeam

Specialized ServiceTeam

Service Request

Service

Services Team Example: Database Administration (DBA) Team


• Responsible for supporting database development and database operation in production

• The delivery team submits a request, the DBA Team prioritizes it and then fulfills it

Communities of Excellence (CoE)

• A CoE focuses on sharing and enhancing skills within a group of like-minded people organized on a volunteer basis

• Individuals will choose to join zero or more CoEs

• Potential CoEs:– Agile– Architecture– Testing– Leadership– Security

• CoEs may adopt common strategies include internal discussion forums, training sessions, “brownbag lunches”, and even certification.


“Scaling” Practices


Consumable solutions

Development intelligence

Requirements envisioning

Architecture envisioning

API first

Test suite API

Parallel independent testing

IT intelligence

Active stakeholder participationContinuous deployment

Release train Multiple “backlogs”

Work item lists

Continuous documentation

Continuous architecture

Work item pools

“Common” Agile Practices that Support Scaling

• Continuous Coordination– Coordination meetings – e.g. “Daily stand ups”– Development intelligence– Demos

• Short iterations/sprints• Regularly producing a potentially consumable solution – e.g. Potentially shippable

software in Scrum• Continuous integration

– Better yet continuous deployment• Agile planning

– Initial high-level release planning– Just in time (JIT) detailed planning – e.g. Iteration/sprint planning– Look-ahead planning



Agile Modeling’s Best Practices

API First/Test Suite API• When there are many people developing a shared set of components you should

invest time at the beginning of the project to identify the components and define the interfaces to those components– “Component” is used to indicate any shared technical resource such as a set of

web services, a shared data source, a programming library, a framework, and so on

– Many teams will choose to write the interface stubs and tests at this time so that they have something to integrate

• Effectively a rigorous application of Agile Model’s Architecture Envisioning and Just Barely Good Enough practices

• API First is a practice of The Eclipse Way

• Also known as Contract Model in Agile Modeling


Continuous Deployment (CD)


Parallel Independent Testing


Multiple Backlogs


• There are dependencies between work items (including requirements)

• When large teams are separated into subteams, and if each subteam has its own work items, then these dependencies need to be managed

• Product Owners are responsible for the work items, therefore they need to coordinate dependencies with one another

IT is More than Solution Delivery


Operations and SupportSolution Delivery People

Management

Portfolio Management

Enterprise Architecture

ProgrammeManagement

Information Management

Asset Management

IT Governance

Your Organization

Your Organization is More Than IT


Information Technology Department

Agile/Scrum is a Good Starting Point


• Construction focus• Value driven lifecycle• Self-organizing teams• Prescriptive• Project team aware

DAD Solidifies the Foundation


• Delivery focus• Risk-value driven lifecycle• Self-organization with appropriate governance• Goal driven• Enterprise aware

Agility at Scale


• Large teams• Geographically distributed teams• Compliance• Domain or technical complexity• Cultural issues• Organizational distribution

Individuals Become Agile


Individuals to be able to become a truly agile practitioner within the evolving context of the situation that they face

They will require training, education and coaching

Teams Build Solutions


Teams will self organize their work strategy, their structure, and their collaboration paths to reflect the context of the situation that they find themselves in

They will require guidance to do so effectively

IT Departments Become Agile


IT departments are often sophisticated entities with teams addressing a wide range of situations and a wide range of goals

Agile delivery teams are just part of the overall mix, as are operations teams, architecture teams, portfolio management teams, and many more

IT organizations will need to adopt a wide range of strategies that reflect the challenges that they face

The Agile Enterprise


An agile enterprise has two key characteristics*:• Response ability – The physical ability to act

is derived from two sources, an organizational structure that enables change and an organizational culture that facilitates change

• Knowledge management – The intellectual ability to find appropriate things to act on and encompasses both top-down knowledge portfolio management (KPM) and bottom-up collaborative learning

* Response Ability by Rick Dove, 2001.

What Does it Mean to Be Disciplined?

• In general, it requires discipline to follow many agile practices and philosophies

• But, it also requires discipline to:– Reduce the feedback cycle– Learn continuously– Deliver solutions incrementally– Be goal driven– Enterprise aware– Streamline Inception and

Transition efforts– Adopt agile governance strategies


Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery:The Foundation for Scaling Agile


Scrum LeanKanban

XP Agile Modeling

And more…SAFeOutside In Dev.

Team SizeGeographicDistribution

Compliance Domain Complexity TechnicalComplexity

OrganizationalDistribution

DAD leverages proven strategies from several sources,providing a decision framework to guide your adoption and

tailoring of them in a context-driven manner.

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


Got Discipline?


DisciplinedAgileConsortium.orgDisciplinedAgileDelivery.com

ScottAmbler.com

Thank You!scott [at] scottambler.com

@scottwambler

AgileModeling.comAgileData.orgAmbysoft.com

DisciplinedAgileConsortium.orgDisciplinedAgileDelivery.com

ScottAmbler.com

Disciplined Agile DeliveryDisciplined Agile Delivery


DAD Certification: DisciplinedAgileConsortium.org

Disciplined Agile Yellow Belt – Indication that the person is new to disciplined agile but eager to

learn– Validate basic knowledge via a test

Disciplined Agile Green Belt– Indication that the person is striving to be a professional– Potential to be a junior coach– Difficult test and several years of proven experience

Disciplined Agile Black Belt– Indication that the person is an expert– Often a senior coach, instructor, or agile transformation lead– Board-level certification


Recommended Resources


Backup Slides


Agile Experiences with Team Size


On your (un)successful agile projects, how many IT team members were there?

89

Source: 2012 Agile Scaling Surveywww.ambysoft.com/surveys/

Agile Experiences with Geographic Distribution


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

90


Agile Experiences with Compliance


On your (un)successful agile projects, was compliance applicable?

Note: Self imposed = CMMI, ISO, …

91


Agile Experiences with Domain Complexity

0% 10% 20% 30% 40% 50% 60% 70% 80%

High Risk

Complex

Medium complexity

Straightforward

Pilot Projects

Had Successes Had Failures


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)

92


Agile Experiences with Technical Complexity

0% 10% 20% 30% 40% 50% 60% 70% 80%

Multi-platform

Single platform

Fix legacy data

Access legacy data

Fix legacy systems

System integration

Package/COTS

Stand-alone

Greenfield



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

93


Agile Experiences with Organizational Distribution

0% 10% 20% 30% 40% 50% 60% 70% 80%

Outsourcing

Partner organizations

Contractors/consultants

Several countries

Several divisions

Same division



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

94


Disciplined Agile Delivery: Extending Scrum to the Enterprise

Technology

Transcript of Disciplined Agile Delivery: Extending Scrum to the Enterprise