Wardley Doctrine sequencing

“Fix doctrine first.” – Simon Wardley

I am interested in what would be a recommended sequence for implementing Wardley Doctrine in an organization. While I’ve read Doctrine is not a checklist to follow and A different view on @swardley's Doctrine, I think I can reframe the question a bit.

In what order should one learn Wardley Doctrine?

Do remember, those operating principles that make up doctrine are all linked, so build the foundations first. Even within the foundations (phase I) there is an order … – https://twitter.com/swardley/status/1335561120380293120

Per the tweet above, Phase I looks like:

phase I1920×1080 165 KB

Take the cue from the above, (and assuming it is valid to put things in some sort of sequence) here are my guesses at Phases II, III, and IV.

Phase II:

Screen Shot 2020-12-12 at 1.46.12 PM734×1048 78.1 KB

Phase III:

Screen Shot 2020-12-12 at 2.12.06 PM736×1048 50.6 KB

Phase IV:

Screen Shot 2020-12-12 at 2.17.55 PM728×1048 33.8 KB

What do y’all think? Does this sequence make sense? Since this is my attempt from talking to myself about it. I’m sure I missed tons of nuance and made a bunch of mistakes.

Hi @tristan.slominski,

I think this video attached below may be interesting, if you have not watched it already. Steve Purkis describes the Glasswall journey through adopting doctrine.

I wonder whether it would make sense to get a little more specific in terms of what f.e. Know Your Users means, how to evaluate it in the perspective of doctrine, and how to introduce specific practices (or practices driving specific outputs). On the other hand, I am not sure whether this is possible at all, as those practices may vary from one company to the other. Perhaps, there is a way to say that a particular doctrine piece is not covered well enough?

I think it’ll vary from company to company.

Speaking of “introducing specific practices,” an interesting exercise/project (for me, any others?) would be to see what elements of Doctrine are encouraged and in what sequence they’re adopted in those fascinating books like “The Phoenix Project” or Goldratt’s “The Goal.”

It’s in Goldratt’s next book, “It’s not Luck,” that they get into detail about “knowing your users” and “knowing user needs.” Yet, in “The Goal,” there’s plenty of “challenging assumptions,” of “being humble,” of “optimizing flow.”

If anyone’s interesting in getting into these, let me know

I do believe it is beneficial to provide more specificity to the existing principles.

I’m currently thinking through a proposal to share with the community. My belief is that we doctrine today is very much in “custom” and in order for it to get to “product” we need some sort of way to structure the doctrine data. Skimming through the video, there is no way I can do any of that without Steve. Which, to me, really highlights the “custom” nature of doctrine.

Consider structuring all the doctrine content by “category”, “principle”, and “practice”. Taking your elaboration as an example:

Category: Development
Principle: Know your users
Practice: Know who are your users

Look at transactions over last x years. Pareto filter it and group into recognisable buckets of users

Category: Development
Principle: Know your users
Practice: Know what they are trying to achieve

• what is their “official” purpose (f.e. reduce unemployment, help their customers)?
• what drives them (bonuses, return on investment, challenge, inertia )?
• if they are driven by other users (f.e. the board put under pressure by investors), you have to understand both groups, and their options

Each one of these snippets can be a categorized piece of doctrine. If I come up with something useful in my area of expertise and I allocate Category, Principle, and Practice to it, then it becomes useful for others as a snippet. I imagine being able to search doctrine for Category:Development AND Principle:Know Your Users and all the practices with their associated content being avialable.

Having that little bit of structure would go a long way in not needing a guide/consultant to learn and apply doctrine little by little. I do realize the audience however and Blockbuster/Netflix analogy comes to mind.

As to varying from company to other company. With the snippet structure, that’s fine, mix and match the practices you want for your principle, skip what doesn’t apply and keep what does. It allows for tayloring to specific user needs without having everything being custom made each time. I can imagine Steve having a set of snippets, LEF having a set of snippets, HiredThought having a set of snippets, and people being able to mix and match those. I belive that would begin to shove doctrine into the product phase of evolution.

edit: I realize I gave examples of short snippets. But these don’t need to be short. It can be a whole book, for example:

Category: Development
Principle: Focus on user needs
Practice: Conduct user needs research

See A Beginner’s Guide to Finding User Needs

or a video… etc etc.

edit 2: … taking a hint from “microdata” format… this can be called “microdoctrine”

edit 3: Given a sequence (the phases I proposed, updated as needed) and a repository of microdoctrine, it seems that I could discover for myself what practice to try and what practice to skip, and overall start my crawl toward adopting more doctrine principles, with more practices.

In my response to @chris.daniel I outlined a snippet structure for doctrine. I think the excercise you propose would be an interesting test whether practice snippets makes sense as a way to package doctrine into small reusable units.