Agile Model-Driven Development

MK Half‐day Tutorial 6/3/2013 1:00 PM

"Agile Model-Driven Development"

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 (AM), Agile Data (AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies and creator of the Agile Scaling Model (ASM). He 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. Scott is a senior contributing editor with Dr. Dobb’s Journal. Visit his home page ScottAmbler.com and his Agility@Scale blog.

02/05/2013

Twitter: @scottwambler 1

Agile Model Driven Development:Best Practices for Scaling Agile

Scott W. AmblerSenior Consulting Partner

scott [at] scottambler.com

@scottwambler

Feel Free to Ask Questions

at Any Time

© Scott Ambler + Associates 2

02/05/2013


Discussion: Defining Done

• What are you hoping to get from this tutorial?



Agenda

• A specification parable

• Thinking outside of the modeling box

• Agile Modeling

• Agile Model Driven Development (AMDD)

• Continuous modeling and documentation

• Project initiation strategies

• Construction strategies

• AMDD and scaling agile

• Parting thoughts

02/05/2013


A specification parable


Two years ago I asked for a toy like the one my friends had. I didn’t know what it was called so I described it to

Santa, hoping that he would know what I was talking about.

My description:It is a toy for kids. You get on it and you bounce up and down. It is lots of fun.

This is what I found under the tree.


It’s sort of fun, but it’s not what I wanted.

02/05/2013


Last year I asked Santa Claus for a sports car. It should be bright red with some white detailing. It should have big racing tires so that it can

hug the road on sharp turns.


This is what I found under the tree.


02/05/2013


This year I really want a penguin. So in my letter to Santa Claus this year I am going to be very clear that I want a real, live penguin. Not a toy penguin. Not a penguin game. Not a penguin picture. A real, live penguin. I will even include this photo of the type of penguin that I would like with my letter.

There will be no mistakes…


Exercise: Comparing Specification Strategies

• Organize into teams of 5-8 people

• Take a minute to introduce yourselves to one another

• For 10 minutes, discuss within the team:• Why didn’t he get the trampoline? • Why didn’t he get the car he wanted? • Assume that he gets the penguin that he asked for. How will this

actually work out in practice• How do these observations relate to what you’ve seen in the workplace

on software development projects?• What approaches have you seen for eliciting requirements from

stakeholders? What were the advantages and disadvantages in the long run?


02/05/2013



What is a Model?


A model is an abstraction that describes one or more aspects of a problem or a potential solution addressing a problem

• Commonly one or more diagrams plus any corresponding documentation

• How the abstraction is captured, if at all, shouldn’t matter• Sketches should be considered models• Non-visual artifacts can also be models

02/05/2013


A Quick Survey

Please answer from the point of view of the agile team you are most familiar with:


1. Did the team do any up-front requirements modeling (or “backlog population”) or have the initial requirements provided to them?

2. Did the team do any up-front architecture modeling or have the architecture provided to them?

3. During iteration/sprint planning do they ever create sketches or identify acceptance criteria to help identify tasks?

4. During an iteration/sprint, do people ever do any modeling/sketching to explore or discuss some work they are performing?

The Survey Results Shared in this Tutorial

• All surveys were performed in an open manner

• The questions as they were asked, the source data, and a summary slide deck can be downloaded free of charge from Ambysoft.com/surveys/


02/05/2013



Comparing Communication Strategies

How effective are communication techniques on actual agile projects?

Rating of -5 (very ineffective) to +5 (very effective)

Format: (within team, with external stakeholders)

Source: Ambysoft Inc. 2008 Agile Principles and Practices Survey

(4.3, 4.1)

(4.2, 3.5)

(2.1, 0.2)

(1.4, 1.5)

(1.9, 1.9)

(1.1, 1.4)

(-0.3, 0.2)

(1.3, 1.6)


Primary Strategy for Modeling

SBMT = Software Based Modeling Tool

Source: Dr Dobb’s 2008 Modeling and Documentation Survey

02/05/2013


Project Inception Activities

High-Level Release Schedule

Initial Estimate

Justify Project

Initial Architecture Modeling

Initial Requirements Modeling

77%

92%

81%

89%

90%


Source: Ambysoft 2009 Agile Project Initiation Survey

0% 20% 40% 60% 80% 100%

Acceptance TDD

Design TDD

Fully Adopted

PartiallyAdoptedNot Adopted

Test Driven Development (TDD) Adoption Rates

© Scott Ambler + Associates

Source: Ambysoft 2012 Testing Survey

18

02/05/2013


Some “Radical” Agile Modeling Ideas

• Defer commitment to requirements details to the last responsible moment

• Defer commitment to design details to the last responsible moment

• Modeling and documentation is an important part of disciplined agile approaches

• Reduce the feedback cycle as much as you can• Modeling a great way to think through high level

concepts• Test-first approaches are a great way to think

through the details in a just-in-time (JIT) manner• Effective agilists take a multi-view, multi-model

approach• Prove it with code, not with good intentions• Keep things as simple as you possibly can, but no

simpler



The Value of Modeling

02/05/2013


Agile Modeling


Why Model?


To think things through

To communicate

To specify

02/05/2013


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

23© Scott Ambler + Associates

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


02/05/2013


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



Agile Modeling (AM)

• AM is a chaordic, practices-based process for modeling and documentation

• AM is a collection of practicesbased on several values and proven software engineering principles

• AM is a light-weight approach for enhancing modeling and documentation efforts for other software processes such as Extreme Programming (XP), Scrum, and Unified Process (UP)

• AM is built right into Disciplined Agile Delivery (DAD)

Values

Principles

Practices

02/05/2013



What Are Agile Models?

• Agile models:– Fulfill their purpose– Are understandable– Are sufficiently accurate– Are sufficiently consistent– Are sufficiently detailed– Provide positive value– Are as simple as possible

• Agile models are just barely sufficient!

As a student I want to enroll in a course so that I can complete my degree


Agile Modeling’s “Best” Practices

02/05/2013


Exercise: We Can’t Do That!• 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


Agile Model Driven Development (AMDD)


02/05/2013



Agile Model Driven Development (AMDD):Project Level


The Basic/Agile Lifecycle of Disciplined Agile Delivery (DAD)

02/05/2013


DAD Lifecycle: Advanced/Lean


DAD Lifecycle: Continuous Delivery


02/05/2013


ContinuousModelingandDocumentation


Continuous Modeling and Documentation

• 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


02/05/2013


Exercise: Continuous Modeling and Documentation?

• Get back together in your groups

• Choose one of the following activities:– Architecture– Analysis– Design– Technical writing

• Given the AMDD and DAD lifecycles, how do you think that activity will be addressed throughout development? Consider:– Project initiation/Inception– Construction– Transition

• You have 5 minutes to discuss


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


02/05/2013


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


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)


02/05/2013


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



02/05/2013


The Inception Phase


Inception Artifacts Evolve in Parallel


Team Environment

Cost and Schedule

Scope Architecture

These artifacts are often summarized in a Project Vision/Charter

02/05/2013



Agile Modeling Best Practices: Inception

Exercise: Modeling at Project Initiation

• This is a group assignment

• As a group take 10 minutes to discuss:– What modeling activities, if any, did your team perform early in the

project?– How much detail did you go into?– What types of models did you create?– Did anyone have to review, accept, or even sign off, on the work?


02/05/2013


Level of Initial Scope Detail

• BRUF (detailed specifications)

• Requirements envisioning (lightweight specifications)

• Goals driven

• No modeling at all


Trade-offs with Early Details

• Benefits:– The more detail you gather the greater your ability to

estimate the work required– Culturally comfortable for organizations new to agile

• Dangers:– Details will evolve over time– Some requirements will never be implemented– You increase the time required to get to Construction– Chance of “analysis paralysis” increases

• Consider:– Exploring only the details of high-priority stories at first


02/05/2013


Functional Requirements: Potential Model Types


Non-Functional Requirements:Potential Views and Concerns


02/05/2013


Initial Architecture: Potential Model Types


Requirements Change Management


02/05/2013


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

Goal: Explore the Initial Scope


02/05/2013


Goal: Identify Initial Technical Strategy



Modeling During Construction

02/05/2013



Agile Modeling Best Practices: Construction

Exercise: Modeling and Documentation During Construction

• This is a group assignment

• As a group, take 10 minutes to discuss what your current agile team(s) are doing:– When you are iteration/sprint planning, are you doing any modeling?– Do you model throughout an iteration? If so, what are you doing?– What is your approach to producing deliverable documentation?– Is the team taking a TDD approach?


02/05/2013


Goal: Produce a Potentially Consumable Solution


Goal: Address Changing Stakeholder Needs


02/05/2013


Agile Modeling andTest Driven Development

(TDD)© Scott Ambler + Associates 61

Test-Driven Development (TDD)


Test-First Development (TFD) is a technique where you write a single test and then you write just enough production code to fulfill that test.

Refactoring is a technique where you make a simple change to your code/schema to improve its quality without changing its semantics.

TDD = TFD + refactoring

02/05/2013


Acceptance and Developer TDD Together


TDD Example

• Story: – As a Student I want to order my official transcript online so that I can

provide it to potential employers

• Acceptance tests:– Ensure the person is or has been a student– Ensure that the student are in good standing (all fees have been paid)– Ensure that the student has finished at least one course– Ensure that at least one valid ship to address is provided– …

• Unit tests for: Ensure the person is or has been a student– The student ID should be a nine-digit number– The last digit should be modulo 11 of the sum of the first 8 digits– One and only one student record should exist for the provided student

ID– …


02/05/2013


Agility at Scale


What Does it Mean to Scale Agile?


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

02/05/2013


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.

AMDD and Large Teams

• Larger teams are often a response to greater domain complexity, technical complexity, or cultural challenges

• Inception:– You will likely need to invest a bit more time exploring the initial

requirements – You may need to take an “API First” or “Contract Model” approach to

the architecture where you define the interface to components in detail early in the project

– There will likely be a bit more initial specification

• Construction:– Product Owners will need to coordinate requirement dependencies– Architecture Owners will need to coordinate technical dependencies– TDD may need to be enhanced with parallel independent testing


02/05/2013


Geographically Distributed/Dispersed Teams


AMDD and Geographic Distribution

• Geographically distributed/dispersed teams are usually the result of large teams or organizational culture

• Inception:– You will likely need to invest a bit more time exploring the initial

requirements – You will likely need to take an “API First” or “Contract Model” approach to

the architecture where you define the interface to components in detail early in the project

– There will likely be a bit more initial specification– Get key players together physically for Inception

• Construction:– Dispersed members will need to coordinate with their co-workers regularly– Product Owners will need to coordinate requirement dependencies– Architecture Owners will need to coordinate technical dependencies– TDD will likely need to be enhanced with parallel independent testing– Get key players together for critical milestones


02/05/2013


Thoughts on Compliance

• Not all regulations are the same– Read and understand them

• Distinguish between– Regulatory compliance which is legally required– Internal audit compliance (e.g. CMMI) which is self imposed

• Compliance will be driven by the interpretation of the guidelines– If you leave interpretation to bureaucrats don’t be surprised if you end

up with a bureaucratic strategy


AMDD and Compliance

• Inception:– Invest time to understand the true implications of the regulations

regarding specification, documentation, and traceability– The regulations MAY require more detailed requirements and

architecture specification, some traceability, and some level of formality of validation of the specifications

• Construction:– You may need to adopt more formal modeling and documentation

tooling– You may need to keep all artifacts in sync throughout construction– You may need to invest in traceability activities, or better yet in activities

and tooling that automatically result in sufficient traceability– TDD may need to be enhanced with parallel independent testing

• Transition:– You may need to hold final reviews and sign-offs of key artifacts– You may need to generate final artifact manifests, traceability trees, and

so on


02/05/2013



Modeling is an Important Aspect of Disciplined Agile Delivery

• Disciplined agilists:– Invest some up-front time exploring the initial scope– Invest some up-front time identifying a viable technical strategy– Work closely with enterprise professionals, including enterprise

architects and operations professionals, to ensure that what they’re producing is enterprise compliant

– Tailor their approach to meet the context of the situation that they face– Model throughout construction in a just-in-time (JIT) manner– Document throughout construction because they realize that

documentation is part of their overall deliverable– Work closely with their stakeholders whenever they can, not just with

stakeholder proxies such as product owners


02/05/2013



AMDD at the Enterprise/Program Level

Exercise: What Have You Learned?

• Individually, on a sheet of paper, answer the following questions:– What three new things have you learned about modeling in general?– What three new things have you learned about how modeling occurs on

an agile project?– What improvements in the way you approach modeling and

documentation can you make on your current project team?– What still puzzles you?


02/05/2013


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

02/05/2013


Thank You!scott [at] scottambler.com

@scottwambler

AgileModeling.comAgileData.orgAmbysoft.com

DisciplinedAgileConsortium.orgDisciplinedAgileDelivery.com

ScottAmbler.com

Disciplined Agile DeliveryDisciplined Agile Delivery


Recommended Resources

© Scott Ambler + Associates80

Agile Model-Driven Development

Technology

Transcript of Agile Model-Driven Development