Prescriptive agile?

When working with new teams there's always a "learning curve" we all have to climb. So I tend to use the phrase "prescriptive start" when working with new teams. It's my way of letting a team know we're going to start with a small set of things the team must do. It's the basics and it will get us started. We can't learn a hundred new things, so let's start small. Let's get going and not try to boil the ocean.

Is it ok to call any form of agile prescriptive?

Definition: Prescriptive - giving exact rules, directions or instructions about how you should do something - from Merriam-Webster dictionary

Scrum lays out a specific set roles, events, artifacts and rules that bind them together. The Scrum Guide is only 16 pages, as compared to some other approaches. I know, I know:

• We do Scrum, but we don't find much use in having a retrospective... 
• We do Scrum, but we don't meet daily instead we meet on Tuesday and Thursday.
• We do Scrum, but...

You can find the full description in the The Scrum Guide.

If you are doing Scrum and not some variation of Scrum, but, then you know there are set of specifics that are part of Scrum. If you're not doing the basics you're doing "Scrum, but."

Domain modeling

A while back I posted a few modeling examples. Today's post is going back to that. This is the domain model. Again this model is for a simple library system which shows how concepts in a domain are related to one another. A box in the diagram is a term or concept. The lines represent connections and the labels on the lines show "how many" for the various relationships.

Cardinality illustrates business rules. As an example a Patron has one and only one account. And an account is associated with only one Patron. An account may have 0 to many fines on an account.


I've found that when using this model it helps to establish clear definitions of the key relationships in your domain. Some of the benefits of a domain model:

• Helps in understanding the problem space
• Creates a common vocabulary 
• Developers can understand the terms and relationships
• Shows what's in and what's out of the domain
• Allows the team to share with other teams when working together

I've used the term Visual Glossary for a long time - long enough I don't remember who said it. I've used it for a while. Either way - it's a visual glossary of the terms in the domain. Give it a try and see if it helps out.