Reading through “Software Engineering Essentialized”, Part II-IV

Notes whilst reading

Part II

It will be important to revisit the beginning where the objective are.
“Serious games” appears to be the theme. Playing games to produce serious results. (Collaboration, not competition.)
I’m going to give this a chance. It seems sincere.
So first off, I think I see what is going on here. The cards contain Essence and the “games” force the team to discuss the elements of what Essence contains. It looks like useful stuff. But again, how is this a theory of anything? It’s not.
And why is a game required? (Progress Poker? Ugh.)
It’s kind of fascinating that the game went from only one deck for the team to one deck for each participant.
- Or does “original poker does not involve a deck of cards for each participant” mean the actual game of poker?
Progress Poker is basically Planning Poker.
Smith is back!
Oh lord, how can this be considered a serious attempt at defining an “essence” of software engineering. This is clearly a methodology.
I almost can’t believe what I’m reading.
This is really feeling like something from Agile. I’m wondering when/if it will differentiate.
It seems as though the authors are begging the question. Sort of?
I am not seeing how Essence is remarkably different from any other methodology I have seen/used.
This is not compelling at at all.
Why are the games necessary? Couldn’t you just have the discussion?
Dialogue? Holy shit…
Digressed and went and looked at a presentation (http://semat.org/documents/20181/27952/Intro-to-EssenceBerlin-Ivar.pdf/bb11abbf-4a1c-431b-88b9-d6161957a440)
- Can’t help but notince there isn’t anyone from the Manifesto on the signatory list.
The kernel is seemingly arbitrary, but what gets all the attention is how to use the cards to do things.
I think I’m starting to see what the point is. It seems as though it’s sane, but it’s still more marketing than anything else.
- The key seems to be the alphas and their states. It’s a large state diagram but with lots of different ways to move through it. The team decides on the current state. It then figures out how to get to the next state. The team also has to determine a checkpoint to verify progress is being made.
This part is wayyyy too wordy.
It talks like it does work, but absolutely no evidence is presented.
To be fair, what this outlines seems reasonable.
This is not garbage, but it is not the basis of software engineering.