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

Agile Requirements - System Sequence Diagram (SSD)

In the Previous Post I talked about the System Context Diagram. It provides a high level view of a system and it's interfaces that make up the overall ecosystem for the product under development. The system context diagram is a static model, meaning it doesn't show interactions/changes over time. From a context diagram, we can create another model, the System Sequence Diagram (SSD) that will show interactions over time.

Context Switching - so you think this is a good thing?

Last post we talked about Agile Clowns multi-tasking and that research has shown that we can't actually multi-task except for repetitive, memorized types of activities. You can't truly multi-task (do 2 or more things at one time) for cognitive activities. Since we can't multi-task, the real issue is context switching. How many projects are you working concurrently? Are you dedicated to one project? Great. Keep it up. Do you have 2 or more projects? 3 or more? Then you're not going to be very efficient.

Appreciation in Agile teams - "Shout Outs"

Here's a simple idea that provides great benefits for teams. I was working with a team that started giving "shout-outs" at their retrospectives. Any team member could take a minute to recognize other team members for anything they did - whether it was to help someone, take on a task to help out, take on a role even if it's not their primary role.... how do you think this worked out?