Agile Model Driven Development (AMDD)
One of the sessions I attended at SD West was ‘Agile Model Driven Development (AMDD) by Scott Ambler. Scott started the session by having us form groups of 4-5 people, and then gave us 3 assignments to work on – one each in the Traditional, Mini-Waterfall and Agile methodologies. At the end of the 3 assignments we compared the team ‘scores’, and most teams did best in the Agile assignment. We then had a mini retrospective of what went well and not so well in all 3 approaches. One of the important revelations was that each team interpreted the same assignment a little differently.
Agile Modeling (AM)
Types of Agile Models: The type of modeling is not important. We can use any tool that works for us. The model can be represented in UI sketch or sticky notes on a whiteboard, as Acceptance Tests or a Domain Model or a UML Sequence Diagram.
- 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!
Scott presented some comparisons between the Traditional, Waterfall, Iterative and Agile approaches. The data, slide decks, and original questions can be downloaded from www.ambysoft.com/surveys/. One interesting slide provides data that shows Agile teams do quite a bit of planning, which dispels the misconception that Agile teams don’t plan! Most Agile teams plan using sketches on a whiteboard or similar; some teams capture this information (usually digitally).
The session also included some information on Agile Documentation:
How CRUFTy Are Your Documents?
Calculating the effectiveness of a document: Effectiveness = C * R * U * F * T
C = % of the document that is Correct
R = Chance that the document will be Read
U = Chance that the material will Understood
F = Chance that the material will be Followed
T = Chance that the document will be Trusted
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
Some other useful resources on this topic are:
By: Veena Mankidy