agile model-driven development
DESCRIPTION
In this interactive session, Scott Ambler explores a vitally important, nitty-gritty, down-in-the-weeds aspect of agile—how to take an agile model-driven development (AMDD) approach to enhance and scale your software delivery capabilities. Correctly applied, AMDD enhances your modeling and documentation efforts, streamlines agile development, and reduces false starts and rework. Scott addresses critical modeling issues that pertain to all agile projects—how to successfully model the complexities of modern-day software without getting bogged-down in mountains of paperwork, how to document systems in an agile manner, how to scale agile development methods with an agile approach to modeling and documentation, how to take an evolutionary approach to user interface and database design, and how modeling extends and supports test-driven development to address the full exploration of requirements, architecture, and design. Join Scott to dig into this vital—yet often ignored—aspect of agile development.TRANSCRIPT
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
Twitter: @scottwambler 2
Discussion: Defining Done
• What are you hoping to get from this tutorial?
© Scott Ambler + Associates 3
© Scott Ambler + Associates 4
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
Twitter: @scottwambler 3
A specification parable
© Scott Ambler + Associates 5
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.
© Scott Ambler + Associates 6
It’s sort of fun, but it’s not what I wanted.
02/05/2013
Twitter: @scottwambler 4
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.
© Scott Ambler + Associates 7
This is what I found under the tree.
© Scott Ambler + Associates 8
02/05/2013
Twitter: @scottwambler 5
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…
© Scott Ambler + Associates 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?
© Scott Ambler + Associates 10
02/05/2013
Twitter: @scottwambler 6
© Scott Ambler + Associates 11
What is a Model?
© Scott Ambler + Associates 12
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
Twitter: @scottwambler 7
A Quick Survey
Please answer from the point of view of the agile team you are most familiar with:
© Scott Ambler + Associates 13
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/
© Scott Ambler + Associates 14
02/05/2013
Twitter: @scottwambler 8
© Scott Ambler + Associates 15
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)
© Scott Ambler + Associates 16
Primary Strategy for Modeling
SBMT = Software Based Modeling Tool
Source: Dr Dobb’s 2008 Modeling and Documentation Survey
02/05/2013
Twitter: @scottwambler 9
Project Inception Activities
High-Level Release Schedule
Initial Estimate
Justify Project
Initial Architecture Modeling
Initial Requirements Modeling
77%
92%
81%
89%
90%
© Scott Ambler + Associates 17
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
Twitter: @scottwambler 10
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
© Scott Ambler + Associates 19
© Scott Ambler + Associates 20
The Value of Modeling
02/05/2013
Twitter: @scottwambler 11
Agile Modeling
© Scott Ambler + Associates 21
Why Model?
© Scott Ambler + Associates 22
To think things through
To communicate
To specify
02/05/2013
Twitter: @scottwambler 12
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
24© Scott Ambler + Associates
02/05/2013
Twitter: @scottwambler 13
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© Scott Ambler + Associates
© Scott Ambler + Associates 26
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
Twitter: @scottwambler 14
© Scott Ambler + Associates 27
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
© Scott Ambler + Associates 28
Agile Modeling’s “Best” Practices
02/05/2013
Twitter: @scottwambler 15
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
© Scott Ambler + Associates 29
Agile Model Driven Development (AMDD)
© Scott Ambler + Associates 30
02/05/2013
Twitter: @scottwambler 16
© Scott Ambler + Associates 31
Agile Model Driven Development (AMDD):Project Level
© Scott Ambler + Associates 32
The Basic/Agile Lifecycle of Disciplined Agile Delivery (DAD)
02/05/2013
Twitter: @scottwambler 17
DAD Lifecycle: Advanced/Lean
© Scott Ambler + Associates 33
DAD Lifecycle: Continuous Delivery
© Scott Ambler + Associates 34
02/05/2013
Twitter: @scottwambler 18
ContinuousModelingandDocumentation
© Scott Ambler + Associates 35
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
© Scott Ambler + Associates 36
02/05/2013
Twitter: @scottwambler 19
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
© Scott Ambler + Associates 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
© Scott Ambler + Associates 38
02/05/2013
Twitter: @scottwambler 20
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 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)
© Scott Ambler + Associates 40
02/05/2013
Twitter: @scottwambler 21
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
© Scott Ambler + Associates 41
© Scott Ambler + Associates 42
02/05/2013
Twitter: @scottwambler 22
The Inception Phase
© Scott Ambler + Associates 43
Inception Artifacts Evolve in Parallel
© Scott Ambler + Associates 44
Team Environment
Cost and Schedule
Scope Architecture
These artifacts are often summarized in a Project Vision/Charter
02/05/2013
Twitter: @scottwambler 23
© Scott Ambler + Associates 45
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?
© Scott Ambler + Associates 46
02/05/2013
Twitter: @scottwambler 24
Level of Initial Scope Detail
• BRUF (detailed specifications)
• Requirements envisioning (lightweight specifications)
• Goals driven
• No modeling at all
© Scott Ambler + Associates 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
© Scott Ambler + Associates 48
02/05/2013
Twitter: @scottwambler 25
Functional Requirements: Potential Model Types
© Scott Ambler + Associates 49
Non-Functional Requirements:Potential Views and Concerns
© Scott Ambler + Associates 50
02/05/2013
Twitter: @scottwambler 26
Initial Architecture: Potential Model Types
© Scott Ambler + Associates 51
Requirements Change Management
© Scott Ambler + Associates 52
02/05/2013
Twitter: @scottwambler 27
Disciplined Agilists Take a Goal-Driven Approach
© Scott Ambler + Associates 53
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
© Scott Ambler + Associates 54
02/05/2013
Twitter: @scottwambler 28
Goal: Identify Initial Technical Strategy
© Scott Ambler + Associates 55
© Scott Ambler + Associates 56
Modeling During Construction
02/05/2013
Twitter: @scottwambler 29
© Scott Ambler + Associates 57
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?
© Scott Ambler + Associates 58
02/05/2013
Twitter: @scottwambler 30
Goal: Produce a Potentially Consumable Solution
59© Scott Ambler + Associates
Goal: Address Changing Stakeholder Needs
© Scott Ambler + Associates 60
02/05/2013
Twitter: @scottwambler 31
Agile Modeling andTest Driven Development
(TDD)© Scott Ambler + Associates 61
Test-Driven Development (TDD)
© Scott Ambler + Associates 62
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
Twitter: @scottwambler 32
Acceptance and Developer TDD Together
© Scott Ambler + Associates 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– …
© Scott Ambler + Associates 64
02/05/2013
Twitter: @scottwambler 33
Agility at Scale
© Scott Ambler + Associates 65
What Does it Mean to Scale Agile?
© Scott Ambler + Associates 66
http://disciplinedagiledelivery.wordpress.com/2013/03/15/sdcf/
02/05/2013
Twitter: @scottwambler 34
Large Teams
67© Scott Ambler + Associates
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
© Scott Ambler + Associates 68
02/05/2013
Twitter: @scottwambler 35
Geographically Distributed/Dispersed Teams
69© Scott Ambler + Associates
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
© Scott Ambler + Associates 70
02/05/2013
Twitter: @scottwambler 36
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
© Scott Ambler + Associates 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
© Scott Ambler + Associates 72
02/05/2013
Twitter: @scottwambler 37
© Scott Ambler + Associates 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
© Scott Ambler + Associates 74
02/05/2013
Twitter: @scottwambler 38
© Scott Ambler + Associates 75
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?
© Scott Ambler + Associates 76
02/05/2013
Twitter: @scottwambler 39
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
© Scott Ambler + Associates 77
Got Discipline?
© Scott Ambler + Associates 78
DisciplinedAgileConsortium.orgDisciplinedAgileDelivery.com
ScottAmbler.com
02/05/2013
Twitter: @scottwambler 40
Thank You!scott [at] scottambler.com
@scottwambler
AgileModeling.comAgileData.orgAmbysoft.com
DisciplinedAgileConsortium.orgDisciplinedAgileDelivery.com
ScottAmbler.com
Disciplined Agile DeliveryDisciplined Agile Delivery
© Scott Ambler + Associates 79
Recommended Resources
© Scott Ambler + Associates80