Agile Model Driven Development: Techniques for Scaling Agile Delivery Scott W. Ambler Senior Consulting Partner scott [at] scottwambler.com twitter.com/scottwambler

Feel free to ask questions at any time © Scott W. Ambler + Associates2

3 Agenda What puzzles you? Traditional versus agile development A specification parable What is modeling? Agile Modeling Agile models and documents Agile Model Driven Development (AMDD) Agile modeling and documentation practices Modeling through the lifecycle AMDD and scaling agile Parting thoughts

Exercise: What Puzzles You? Organize into teams of 4-6 people Take a minute to introduce yourselves to one another For 5 minutes, discuss: –What have you heard about modeling and documentation on agile projects? –What actual experiences do you have on agile project teams, if any? –What puzzles you about agile modeling and documentation? A spokesperson from the team should be prepared to share one or two things that puzzle you about agile modeling with the larger group © Scott W. Ambler + Associates4

Exercise: Traditional Versus Agile Greeting Cards Organize into teams of 4-6 people –Smaller is better, but you need at least 4 people If possible: –Work with people you have never met before –Work with people from different organizations –Have fun, but stay focused on the assignments The overall strategy: 1.Get organized 2.Create a greeting card in a traditional manner 3.Create a greeting card in an agile manner 4.Discuss what happened

Step 1: Get Organized Choose roles: –1 stakeholder –1 analyst –1 tester –Everyone else is a developer The stakeholder from each group must come to the front of the room for instructions. Everyone else: –Read the next slide © Scott W. Ambler + Associates6

Step 2: A Birthday Card for Grandma Analyst interviews stakeholder, producing requirements document. Everyone else may listen but not speak. Analyst hands over requirements document to development team. Analyst and Stakeholder now quiet. Model 3 min Code 3 min Test 45 sec Fix 45 sec Rate Developers “fix” card. Developers provide card to the stakeholder. Developers create card. Tester watches. Developers provide card and original requirements document to the tester. Tester inspects card and suggests improvements. Stakeholder rates the end product.

Step 3: A Wedding Card for Friends You are in the same roles as before Organize the project into three short iterations Each iteration: –Development (60 seconds): Anyone can ask the stakeholder questions. Anyone can work on the card Anyone can suggest improvements –Retrospective (30 seconds): At the end of each iteration identify how you can together more effectively Choose one or two ideas to help improve your approach next iteration Develop 60 sec Improve 30 sec Develop 60 sec Improve 30 sec Develop 60 sec Rate

Step 4: Review What are your scores? –Instructor will record on a flip chart As a team, take 5 minutes to discuss –What worked best for you? Why? –What are the risks with each approach? –What are the trade-offs with each approach? –Was there overhead between hand-offs? Why? –How efficient was each approach? –What can you apply to “the real world”? A spokesperson from the team should be prepared to share some key learnings with the larger group

A Specification Parable © Scott W. Ambler + Associates10 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 W. Ambler + Associates11 It’s sort of fun, but it’s not what I wanted.

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 W. Ambler + Associates12

This is what I found under the tree. © Scott W. Ambler + Associates13

This year I really want a pony. So in my letter to Santa Claus this year I am going to be very clear that I want a real, live pony. Not a toy pony. The pony should be white and between 7 and 9 feet tall. I will even include this photo of the type of pony that I would like with my letter. There will be no mistakes… © Scott W. Ambler + Associates14

Exercise: Specification Get back into your teams For 10 minutes, discuss within the team: Why didn’t he get the trampoline? How does this relate to what you’ve seen in the workplace? Why didn’t he get the car he wanted? How does this relate to what you’ve seen in the workplace? Assume that he gets the pony that he asked for. How will this actually work out in practice? How does this relate to what you’ve seen in the workplace? What approaches have you seen for eliciting requirements from stakeholders? What were the advantages and disadvantages in the long run? Someone needs to be a spokesperson for your team to share a few key learnings with the rest of the group © Scott W. Ambler + Associates15

Exercise: What is a Model? © Scott W. Ambler + Associates16 Ummm... not in our context Get back into your teams Goal: Define what a model is Capture your definition on an index card For 5 minutes, discuss within the team: What are models used for? Are sketches models? Are text-based artifacts (e.g. user stories and use cases) models? Are tests models? Do you need tools to model? If so, what? Why do you model? A spokesperson should be prepared to share your definition with the larger group

What is a Model? © Scott W. Ambler + Associates17 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

Why Model? © Scott W. Ambler + Associates18 To think things through To communicate To specify

© Scott W. Ambler + Associates19 Primary Strategy for Modeling Source: Dr Dobb’s 2008 Modeling and Documentation Survey

Exercise: Modeling in “non-Agile” Environments Get back into your smaller teams For 10 minutes, discuss: –What are your experiences with modeling on “non-agile” projects? –When did you model during the project? –How much modeling did you do? –What types of models did you create? –Who was involved with the modeling? –How were the models used? –What were the advantages and disadvantages of the approach? A spokesperson should be prepared to share a few key learnings with the rest of the group © Scott W. Ambler + Associates20

Exercise: Modeling in “Agile” Environments Get back into your smaller teams For 10 minutes, discuss: –What are your experiences with modeling on “agile” projects? –When did you model during the project? –How much modeling did you do? –What types of models did you create? –Who was involved with the modeling? –How were the models used? –What were the advantages and disadvantages of the approach? A spokesperson should be prepared to share a few key learnings with the rest of the group © Scott W. Ambler + Associates21

© Scott W. Ambler + Associates22 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) AM is built right into Disciplined Agile Delivery (DAD) Values Principles Practices

© Scott W. Ambler + Associates23 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

Copyright 2012 Ambysoft Inc.24 What are Agile Documents? Focus on stable, not speculative concepts Are executable first, static only if you have to Maximize stakeholder ROI Are concise Fulfill a purpose Describe information that is less likely to change Describe “good things to know” Have a specific customer and facilitate the work efforts of that customer Are sufficiently accurate, consistent, and detailed

© Scott W. Ambler + Associates25 Agile Model Driven Development (AMDD): Project Level

Exercise: Agile Requirements Envisioning Get back into your smaller teams Goal:  Create a project profile focused on initial requirements envisioning Take 10 minutes to discuss:  Identify the team member(s) who have been involved with an agile team where some initial requirements envisioning occurred. If there are several, quickly discuss each project and choose the one most interesting to you  Describe how the team approached initial requirements envisioning – How much effort was it? What artifacts were created? Who was involved? How was the output used by the team? How was the architecture validated?  Describe the project: How large was the team? Were you distributed? What organizational challenges did you face?  What are the advantages and disadvantages of what the team did? Think short term and long term. A spokesperson will share a few key learnings with the larger group © Scott W. Ambler + Associates26

Exercise: Agile Architecture Envisioning Get back into your smaller teams Goal:  Create a project profile focused on initial architecture envisioning Take 10 minutes to discuss:  Identify the team member(s) who have been involved with an agile team where some initial architecture envisioning occurred. If there are several, quickly discuss each project and choose the one most interesting to you  Describe how the team approached initial architecture envisioning – How much effort was it? What artifacts were created? Who was involved? How was the output used by the team? How was the architecture validated?  Describe the project: How large was the team? Were you distributed? What organizational challenges did you face?  What are the advantages and disadvantages of what the team did? Think short term and long term. A spokesperson will share a few key learnings with the larger group © Scott W. Ambler + Associates27

© Scott W. Ambler + Associates28 Agile Modeling’s Best Practices

Test-Driven Development (TDD) © 2012 Scott W. Ambler + Associates29 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

Acceptance and Developer TDD Together © 2012 Scott W. Ambler + Associates30

Some Industry Stats 2009 Agile Project Initiation Survey: –89% of agile teams do some sort of up-front requirements modeling –86% of agile teams do some sort of up-front architecture modeling –56% create a project vision/chart document 2008 Test-Driven Development Survey –When it came to requirements capture, 85% of respondents wrote some documentation, 53% did some modeling, and 45% wrote acceptance tests –When it came to design capture, 80% wrote documentation, 67% modeled, and 57% wrote developer tests Survey details can be obtained free of charge at Ambysoft.com/surveys/ © Scott W. Ambler + Associates31

Exercise: Adopting Test Driven Development (TDD) Get back into your smaller teams For 10 minutes, discuss: –Has your team adopted acceptance TDD (ATDD)? Is it considering it? –Has your team adopted developer TDD? Is it considering it? –What are the challenges associated with adoption of each form of TDD? –What are the benefits of each form of TDD? Think short term and long term. –What are the disadvantages? Think short term and long term. Someone needs to be a spokesperson for your team Be prepared to share with the larger group: –Your adoption stats of ATDD and developer TDD (for each of ATTD and developer TDD – Number doing it, thinking about it, Neither). –A few key learnings from your discussion © Scott W. Ambler + Associates32

© Scott W. Ambler + Associates33 The Basic/Agile Lifecycle of Disciplined Agile Delivery (DAD)

DAD Lifecycle: Advanced/Lean © Scott W. Ambler + Associates34

Exercise: Modeling and Documentation on an Agile Project Get back into your teams Choose a type of project (described on following slides) that you will take an disciplined agile approach with: –Data warehouse –Web site –Pacemaker monitoring software For 10 minutes, discuss: –How you would go about initial modeling. What are the primary models that you would choose? –What documents would you create and maintain throughout the project? –How much detailed modeling you would need to do throughout this sort of project? A spokesperson should be prepared to share key learnings with the class © Scott W. Ambler + Associates35

Project Type: Data Warehouse Scenario: –Your organization is in the process of developing a data warehouse (DW) to support your business intelligence (BI) efforts. –There are 17 sources of legacy data. Challenges: –This is the third attempt at a DW. The previous two efforts took a traditional, data-driven approach. –The second project team was supported by a parallel Meta-Data Management (MDM) project which was declared a success. –The second version of the DW was deployed but few business stakeholders found it useful. –The data in the second DW was of good quality but didn’t support the actual reporting needs of the stakeholders. –The source data has the usual inconsistencies (semantic differences, time differences,…) © Scott W. Ambler + Associates36

Project Type: Web Site Scenario: –Your organization needs to redevelop its website. –You want to add social media features, such as the ability to add comments on some pages and the ability to vote on the usefulness of pages, to the site. –You want to allow customers to update their customer records via the site. These records are currently stored in an internal CRM system. Challenges: –All but two of the original development team have left your organization to become agile coaches. –The original team followed Scrum and believed they didn’t need to create any sort of supporting technical documentation. –The existing user interface (UI) design looks nice but usability of the site is very poor due to poor flow between pages and poorly designed pages in general. –The existing solution uses technologies that aren’t on your enterprise architecture road map © Scott W. Ambler + Associates37

Project Type: Pacemaker Monitoring Software Scenario: –The latest generation of pacemakers are Bluetooth enabled. –The goal is for someone to put their phone close to their chest so that the pacemaker can either report its recent history to the person’s doctor or if the pacemaker detects a serious problem it can call for help. –You are building the system that responds to the call made by the pacemakers. –The data upload packet from the pacemaker is in a well defined, industry-standard format. Challenges: –You are working in a life-critical environment. –Your main competitor in the marketplace is already running beta trials of a similar solution. © Scott W. Ambler + Associates38

© 2012 Scott W. Ambler + Associates39 Architecture Throughout the Lifecycle Architectural vision guides development efforts Initial architectural envisioning Architecture owner facilitates architectural decisions throughout the project Architecture handbook and models updated as required Architecture spikes to explore a technical issue Reduce risk early by proving the architecture works

Analysis Throughout the Lifecycle © Scott W. Ambler + Associates40 Discuss requirements during iteration planning/modeling Identify new needs during demos Active stakeholder participation throughout the project Look-ahead modeling for upcoming complex work items Analyze incoming requests from production Initial requirements envisioning Pre-project problem exploration

Design Throughout Construction © Scott W. Ambler + Associates41 Discuss design implications during iteration planning/modeling Test-Driven Design (TDD) throughout Construction Look-ahead modeling for upcoming complex work items Consider design issues of incoming requests from production

DAD is Goal-Driven, Not Prescriptive There are various goals that a team needs to address throughout the lifecycle For each goal there are several issues to consider For each issue there are different techniques to address it Each technique has its advantages and disadvantages Your choices depend on the context of the situation faced by a team Some “modeling-oriented” goals: –Explore the initial scope –Identify the initial technical strategy –Address changing stakeholder needs –Regularly produce a potentially consumable solution © Scott W. Ambler + Associates42

Goal: Explore the Initial Scope 43© Scott W. Ambler + Associates

Goal: Identify Initial Technical Strategy © Scott W. Ambler + Associates44

Goal: Address Changing Stakeholder Needs © Scott W. Ambler + Associates45

Goal: Produce a Potentially Consumable Solution © Scott W. Ambler + Associates46

Goal: Move Closer to a Deployable Release © Scott W. Ambler + Associates47

Scaling/Tailoring Complexity Factors © Scott W. Ambler + Associates48 motivates affects varies by motivates affects Geographic Distribution Co-located Global Organizational Distribution Single Outsourcing Team Size s Domain Complexity Straightforward Very complex Technical Complexity Straightforward Very complex Compliance None Life critical Team Culture Agile Rigid Organizational Culture Agile Rigid

Organizing Large Teams 49 © Scott W. 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.

Exercise: AMDD and Team Size Get back into your teams Instructions: –Take 15 minutes to discuss how you would approach modeling and documentation for an agile team of 10 co-located people, a team of 30 people on the same floor, and a team of 100 people in the same building –Focus on how it would affect goals such as Explore the Initial Scope, Identify Initial Technical Strategy, and Move Closer to a Deployable Release A spokesperson will share with the larger group a few key learnings © Scott W. Ambler + Associates50

Geographically Distributed/Dispersed Teams 51 © Scott W. Ambler + Associates

Exercise: AMDD and Geographic Distribution Get back into your teams Instructions: –Take 15 minutes to discuss how you would approach modeling and documentation for an agile team of 10 co-located people, a team of 10 people fully dispersed, and three teams of 10 people on three different continents –Focus on how it would affect goals such as Explore the Initial Scope, Identify Initial Technical Strategy, and Address Changing Stakeholder Needs A spokesperson will share with the larger group a few key learnings © Scott W. Ambler + Associates52

Copyright 2012 Scott W. Ambler + Associates53

Challenges Adopting AMDD © Scott W. Ambler + Associates54

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 W. Ambler + Associates55

© Scott W. Ambler + Associates56 AMDD at the Enterprise/Program Level

© Scott W. Ambler + Associates57 The Value of Modeling

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 W. Ambler + Associates58

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 W. Ambler + Associates59

Thank You! scott [at] scottwambler.com Twitter: scottwambler AgileModeling.com AgileData.org Ambysoft.com DisciplinedAgileDelivery.com EnterpriseUnifiedProcess.com ScottWAmbler.com © Scott W. Ambler + Associates60

Recommended Resources © Scott W. Ambler + Associates 61

Backup Slides © Scott W. Ambler + Associates62

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 W. Ambler + Associates63

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 W. Ambler + Associates64

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 W. Ambler + Associates65