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 ∙ sqeinfo@sqe.com ∙ 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

Agile Model Driven Development:
Best Practices for Scaling Agile
Scott W. Ambler
Senior Consulting Partner
scott [at] scottambler.com
@scottwambler

Feel Free to
Ask Questions
at Any Time

© Scott Ambler + Associates

Twitter: @scottwambler

2

1

02/05/2013

Discussion: Defining Done
•

What are you hoping to get from this tutorial?


3

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



4

2

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.

5

This is what I found under the tree.

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



6

3

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.


7

This is what I found under the tree.



8

4

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…


9

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?



10

5

02/05/2013


11

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



12

6

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?


13

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/



14

7

02/05/2013

Comparing Communication Strategies
(4.2, 3.5)
(4.3, 4.1)

How effective are
communication
techniques on actual
agile projects?

(1.3, 1.6)
Rating of -5 (very
ineffective) to +5 (very
effective)

(1.4, 1.5)
(2.1, 0.2)
(1.1, 1.4)

Format: (within team,
with external
stakeholders)

(1.9, 1.9)

(-0.3, 0.2)
Source: Ambysoft Inc.
2008 Agile Principles
and Practices Survey

15

Primary Strategy for Modeling

SBMT = Software Based Modeling Tool
Source: Dr Dobb’s 2008 Modeling and Documentation Survey


16

8

02/05/2013

Project Inception Activities

90%

Initial Requirements Modeling

89%

Initial Architecture Modeling

81%

Justify Project

92%

Initial Estimate

77%

High-Level Release Schedule

Source: Ambysoft 2009 Agile Project Initiation Survey

17

Test Driven Development (TDD) Adoption Rates

Design TDD

Acceptance TDD
Fully Adopted
Partially
Adopted
Not Adopted

0%

20%

40%

60%

80%

100%

Source: Ambysoft 2012 Testing Survey


18

9

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

19

The Value of Modeling



20

10

02/05/2013

Agile Modeling


21

Why Model?

To communicate

To think things through

To specify


22

11

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

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



24

12

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


25

Agile Modeling (AM)
•

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

•

AM is a collection of practices
based 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)

•

Principles

Practices

Values

AM is built right into Disciplined
Agile Delivery (DAD)


26

13

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

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

Agile models are just barely
sufficient!


27

Agile Modeling’s “Best” Practices



28

14

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


29


30

Agile Model
Driven
Development
(AMDD)


15

02/05/2013

Agile Model Driven Development (AMDD):
Project Level


31

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



32

16

02/05/2013

DAD Lifecycle: Advanced/Lean


33

DAD Lifecycle: Continuous Delivery



34

17

02/05/2013

Continuous
Modeling
and
Documentation


35

Continuous Modeling and Documentation
•

In agile,
–
–
–
–

•

This occurs because:
–
–
–
–

•

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

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



36

18

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


37

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



38

19

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


39

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)



40

20

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




41

42

21

02/05/2013

The Inception Phase


43

Inception Artifacts Evolve in Parallel

Team
Environment

Cost and Schedule

Scope

Architecture

These artifacts are often summarized in a Project Vision/Charter



44

22

02/05/2013

Agile Modeling Best Practices: Inception


45

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?



46

23

02/05/2013

Level of Initial Scope Detail
•
•
•
•

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


47

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



48

24

02/05/2013

Functional Requirements: Potential Model Types


49

Non-Functional Requirements:
Potential Views and Concerns



50

25

02/05/2013

Initial Architecture:
Potential Model Types


51

Requirements Change Management



52

26

02/05/2013

Disciplined Agilists Take a Goal-Driven Approach

Goal

Explore the Initial
Scope
Form the
Initial Team
Address
Changing
Stakeholder
Needs

*

Issue

*

Source
Team size
Team structure
Team members
Geographic distribution
Supporting the team
Availability


Advantages
Option
Disadvantages
Default Option
Considerations

Co-located
Partially dispersed
Fully dispersed
Distributed subteams

53

Goal: Explore the Initial Scope



54

27

02/05/2013

Goal: Identify Initial Technical Strategy


Modeling During
Construction


55

56

28

02/05/2013

Agile Modeling Best Practices: Construction


57

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?



58

29

02/05/2013

Goal: Produce
a Potentially
Consumable
Solution


59

Goal: Address Changing Stakeholder Needs



60

30

02/05/2013

Agile Modeling and
Test Driven Development
(TDD)

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



62

31

02/05/2013

Acceptance
and
Developer
TDD
Together


63

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
– …


64

32

02/05/2013

Agility at
Scale


65

What Does it Mean to Scale Agile?

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


66

33

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.


67

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



68

34

02/05/2013

Geographically Distributed/Dispersed Teams


69

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


70

35

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


71

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


72

36

02/05/2013


73

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



74

37

02/05/2013

AMDD at the Enterprise/Program Level


75

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?



76

38

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


77

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



78

39

02/05/2013

Thank You!
scott [at] scottambler.com
@scottwambler
AgileModeling.com
AgileData.org
Ambysoft.com
DisciplinedAgileConsortium.org
DisciplinedAgileDelivery.com
ScottAmbler.com
Disciplined Agile Delivery
Disciplined Agile Delivery

79

Recommended Resources

80


40

Agile Model-Driven Development

More Related Content

What's hot

Viewers also liked

Similar to Agile Model-Driven Development

More from TechWell

Recently uploaded

Agile Model-Driven Development