Before you write your case study

• We expect real deep involvement in a case study. Visiting once a month or a 3-month adoption are unlikely to be good enough. Trainers must train from experience, the case study should demonstrate that experience
• LeSS adoptions are about organizational change. When there is just two teams, it is still a LeSS adoption, but it doesn’t lead to enough experience for teaching people about the expected change. It ought to be larger than a 2-team case study.
• Read through the existing case studies. They are far from perfect but give an idea of what is expected. Improve on them, please :)
• We expect the case study to be thorough. A 1-2 page description won’t do.

Miscellaneous

• Although these are tagged as “case studies”, in fact they are “experience reports” if one is to be accurate. We are sticking with the former term as that is how these kinda things are colloquially known to a lay audience.

Tool

• share it as a native google doc… the cloud happened ;)
• when ready to share, share it with edit rights

Content & Style

• Although early Scrum adoption is important, do not forget that the case study should be about LeSS and thus the LeSS part should cover the majority of the case study. Please limit any pre-LeSS part of the story to a “small percentage” of the content.
• Try to share experiments you’d recommend by using Try/Avoid.
• Include the messy reality; we don’t want white-washed stories. Explore the reasons behind the messes, and resolutions (or not).
• At many/most possible points, make connections in your story to the LeSS rules & guides (book 3), and experiments (in books 1 & 2). Name the rule/guide/experient, reference the book it is from, and show the connections to your case. Explain why the rule/guide/experiment is what is, connecting that to your story.
• Be specific, tell a detailed and concrete story. Names, places, dates, meetings, specific decisions and actions and information. Do not write something that feels like a generic LeSS summary with some vague and minor intersection with your case; rather, tell an in-depth story.
• Photos are appreciated, they make things more real.

Structure

• More or less, the first section should be some background context, including
  • The nature of the product
  • Customers & market
  • Prior state org structure: groups, managers, roles, sites, etc
  • Names and roles of key figures (or anonymize if need be)
  • Why
• After that, there is no special structure guidance… creativity supported