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."

The problem I've had using the term "prescriptive" is people forget the second part of the statement - they remember prescriptive and forget the "start" part. A prescriptive start is exactly what is needed and Scrum gives you the keys to getting started. There are specifics that make Scrum, Scrum. However, Scrum is a framework that allows for much variation in many of the practices used within the framework.

If you've read the The Scrum Guide you know that Scrum is a lightweight framework that is applied to complex adaptive projects using the empirical process. From the Scrum Guide, it's:

• Lightweight
• Simple to Understand
• Difficult to master

The simple part, and the part I'm calling prescriptive, is the basic Scrum Definition. There's very little in the framework that is difficult to read or understand. And frankly it's not that hard to get started. The catch is that high performing teams, which we all want, are very disciplined in there delivery. They always do unit tests first. They check in their code frequently, not allowing the code to sit waiting for that integration and merge disaster waiting around the corner.

Disciplined teams are consistent, reliable, trustworthy, knowledgeable, ... In the case of Scrum teams, the best adhere to the Scrum Framework, augmenting the framework with things like: user stories, TDD, Continuous Integration, ...

That's where we all want to be. You have to start with something simple, master it and augment, adapting as you go

Hope you enjoyed this rant.