Based on agile modeling book by #Scott_Ambler

1. Agile Companies Models and
Implementation
Amir Moghimi

2. One of the greatest pains to
human nature is the pain of a
new idea
Walter Bagehot
2

3. successful agile programs
can
Increase productivity per developer by 27%
Reduce launch delays by 30%
Decrease defects in production by a factor of
3x
3

4. The three levels of successful
agile implementation
4

5. To deploy agile development at scale,
companies will need to alter their operating
models and organizational structures
5

6. 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 XP and RUP
6

7. The Core of AM You Need to
Adopt at Least the Core
•
•
•
•
•
•
•
•
•
•
•
Core Principles
Assume Simplicity
Embrace Change
Enabling the Next Effort is Your
Secondary Goal
Incremental Change
Model With a Purpose
Multiple Models
Maximize Stakeholder Investment
Quality Work
Rapid Feedback
Software Is Your Primary Goal
Travel Light
•
•
•
•
•
•
•
•
•
•
•
•
•
Core Practices
Active Stakeholder Participation
Apply the Right Artifact(s)
Collective Ownership
Create Several Models in Parallel
Create Simple Content
Depict Models Simply
Display Models Publicly
Iterate to Another Artifact
Model in Small Increments
Model With Others
Prove it With Code
Single Source Information
Use the Simplest Tools
7

8. How the AM Practices Fit
Together?
AM’s core practices are organized into four
categories:
1. Teamwork
2. Iterative and Incremental
3. Simplicity
4. Validation
8

9. How AM’s practices relate to one another
9

10. 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 enough!
10

11. Agile Models
11

12. Modeling is similar to planning
most of the value is in the act of
modeling, not the model itself
12

13. Feedback
The only way that you can determine whether your
work is correct is to obtain feedback, and that
includes feedback regarding your models.
Develop the model as a team
Review the model with your target audience
Implement the model
Acceptance testing
13

14. Tests as Primary Artifacts
Reduce Documentation by Single Sourcing Information
14

15. Agile Documentation
Travel light – You need far less documentation than you think
Agile documents:
Maximize stakeholder investment
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
Are sufficiently indexed
Valid reasons to document:
Your project stakeholders require it
To define a contract model
To support communication with an external group
To think something through
15

16. Agile Modeling Values
Communication
Simplicity
Feedback
Courage
Humility
16

17. Communication Modes
Always Strive to Use the Most Effective Approach
17

18. Communication and Agile Modeling
18

19. Nurturing an Agile Culture
Overcome the misconceptions that surround
modeling
Think small
Loosen up a bit
Rigidly support project stakeholder rights and
responsibilities
Rethink presentations to stakeholders
19

20. The Cons and Pros of Simple Tools
Simple tools are inclusive
Simple tools provide tactile feedback
Simple tools are inexpensive
Simple tools are non-threatening to users
Simple tools are quick to use
Simple tools are portable
Simple tools can be used in combination with more complex ones
Simple tools promote iterative and incremental development
Simple tools aren’t acceptable to many people
Simple tools are limited
Simple tools do not support distributed teams easily
20

21. Rigidly Support Rights and
Responsibilities
Minimize the number of presentations that you give
Try to find an alternative
Turn the presentation into a working session
Make project stakeholders aware of the costs
Project stakeholders decide whether they wish to have a
presentation
Keep it simple
Minimize the number of people involved in preparation
Minimize the number of people that attend the presentation
21

22. Agile Documentation
Why do people document?
When does a model become a document?
What are the trade-offs associated with documentation?
What does it mean to travel light?
When is a document agile?
What type of documents do you need?
Effective hand-offs
Strategies for increasing the agility of documentation
22

23. UML state chart that depicts the lifecycle of an agile model
23

24. Strategies for Increasing the
Agility of Documentation
Focus on the customer(s)
Keep it just simple enough, but not too simple
The customer determines sufficiency
Document with a purpose
Prefer other forms of communication to documentation
Put the documentation in the most appropriate place
Wait for what you are documenting to stabilize
Display models publicly
Start with models you actually keep current
Require people to justify documentation requests
Write the fewest documents with least overlap
24

25. Critical Points regarding Agile
Documentation
1. The fundamental issue is effective communication, not documentation.
2. Documentation should be ”lean and mean.”
3. Travel as light as you possibly can.
4. Documentation should be just good enough.
5. Models are not necessarily documents, and documents are not necessarily
models.
6. Documentation is as much a part of the system as the source code.
7. Your team’s primary goal is to develop software; its secondary goal is to
enable your next effort.
8. The benefit of having documentation must be greater than the cost of
creating and maintaining it.
25

26. Critical Points Regarding Agile
Documentation
9. Never trust the documentation.
10. Each system has its own unique documentation needs; one
size does not fit all.
11. Ask whether you NEED the documentation, and why you
believe you NEED the documentation, not whether you want it.
12. The investment in system documentation is a business
decision, not a technical one.
13. Create documentation only when you need it—Don’t create
documentation for the sake of documentation.
14. Update documentation only when it hurts.
15. The customer, not the developer, determines whether
documentation is sufficient.
26

27. Agile Modeling Throughout
the XP Lifecycle
27

28. Typical XP developer’s day
28

29. The Modeling Disciplines
1. Business Modeling
2. Requirements
3. Analysis and Design
4. Infrastructure Management
29

30. Non-Modeling Disciplines
Implementation
Test
Project Management
Configuration and Change Management
Environment
Deployment
Operations and Support
30

31. Agile Analysis and Design
1.
2.
3.
4.
5.
Architectural Modeling
Logical view
Process view
Development view
Physical view
Scenario (use case) view
31

32. Infrastructure Models
1- Enterprise requirements model. This model
reflects your organization’s high level requirements
(Jacobson, Griss, and Jonsson 1997)
2- Domain architecture model. This model depicts
the high-level business structure of your systems
that depicts the shared components or services
available to your organization’s business systems
3- Technical architecture model. This model
depicts the high-level technical infrastructure that
supports your business
32

33. Scaling AM with Core
Architecture Teams




Recognize that it is very difficult to make
this discipline work effectively
Don’t blur roles between enterprise teams
and development teams
Educate, educate, educate
Recognize that you likely need to change
33

34. How to overcome Organizational
and Cultural Challenges?
Skeptical developers
Overzealous process police
Paper pushers with power
Cookbook philosophy
Inability to accept blame
Excessive documentation due to fear of
losing everyone
34

35. Agile Software Requirements Management
Changing Requirements Are a Competitive Advantage if You Can Act
on Them
35

36. Model With Others
The modeling equivalent of pair
programming
You are fundamentally at risk
whenever someone works on
something by themselves
Several heads are better than one
36

37. Effectiveness of Requirements
Gathering Techniques
37

38. Relative Effectiveness of User
Representatives
A c tu a l S ta k e h o ld e r
P ro d u c t M a n a g e r
B u s in e s s A n a ly s t a s U s e r
P e rs o n a s
Effectiveness
C o p yr ig h t 2 0 0 5 S co tt W . A m b le r
38

39. Factors to Determine If You’re Not
Engaged in Agile Modeling
39

40. Glossary of Definitions and Abbreviations
Agile model A model that is just barely good enough. This
means that it fulfills its 'purpose and no more; is
understandable to its intended audience; is simple,
sufficiently accurate, consistent, and detailed; and
investment in its creation and maintenance provides positive
value to your project.
Agile Modeling (AM) A chaordic, practice-based methodology
for effectively modeling software-based systems.
Analyst A developer responsible for working directly with
project stakeholders to potentially gather/elicit information
from them, document that information, and/or validate that
information.
Artifact A deliverable or work product
CASE Computer-aided system engineering
Chaordic The behavior of a self-governing organism,
organization, or system that harmoniously blends chaos and
order
40

41. Glossary of Definitions and Abbreviations
Class Responsibility Collaborator (CRC) card A standard index card
that has been divided into three sections, one indicating the name of
the class that the card represents, one listing the responsibilities of
the class, and the third listing the names of the other classes that this
one collaborates with to fulfill its responsibilities.
Documentation handoff This occurs when one group or person
provides documentation to another group or person
IDE Integrated Development Environment
Model An abstraction that describes one or more aspects of a
problem or a potential solution to that problem. Traditionally, models
are thought of as zero or more diagrams plus any corresponding
documentation. However, non-visual artifacts such as collections of
CRC cards, a textual description of one or more business rules, or the
structured English description of a business process are also
considered to be models.
41

42. Agile Modeling Resources
The Agile Modeling Web site
www.agilemodeling.com
The Agile Modeling mailing list
www.agilemodeling.com/feedback.htm
The Agile Modeling Workshop
www.ronin-intl.com/services/agileModeling.htm
42

43. References
Ambler, S.W. (2002). Agile Modeling: Effective Practices for XP and the UP. New York:
John Wiley & Sons.
Ambler, S.W. (2003). Agile Database Techniques. New York: John Wiley & Sons.
Ambler, S.W. (2004). The Object Primer 3rd Edition: AMDD with UML 2. New York:
Cambridge University Press.
Ambler, S.W. (2005). The Elements of UML 2.0 Style. New York: Cambridge University
Press.
Beck, K. (2000). Extreme Programming Explained – Embrace Change. Reading, MA:
Addison Wesley Longman, Inc.
Beck, K. & Fowler, M. (2001). Planning Extreme Programming. Reading, MA: Addison
Wesley Longman, Inc.
Constantine, L.L. & Lockwood, L.A.D. (1999). Software For Use: A Practical Guide to the
Models and Methods of Usage-Centered Design. New York: ACM Press.
Digital McKinsey, Agile Compendium, August 2016.
Fowler, M. (1997). Analysis Patterns: Reusable Object Models. Menlo Park, California:
Addison Wesley Longman, Inc.
Larman, C. (2004). Agile and Iterative Development: A Manager’s Guide. Reading, MA:
Addison Wesley Longman, Inc.
Palmer, S.R. & Felsing, J.M. (2002). A Practical Guide to Feature Driven Development.
Upper Saddle River, NJ: Prentice Hall PTR. 43

44. Online Resources
www.agilemodeling.com
www.agilealliance.org
www.controlchaos.com
www.ambysoft.com
www.agiledata.org
www.enterpriseunifiedprocess.com
www.mckinsey.com
44