That’s a cool idea. I like the thumbs-up/thumbs-down/thumbs-“meh” idea as a simple “scoring” mechanism to judge each individual architecture because I want people to get a kind of “final tally” of how well the architecture held up—I’d worry that “investing” might go more towards the “cool” ideas than the “yeah, you really addressed the problem” ideas, but I can see the value in this approach, too.
Often, I leave things out of the Kata descriptions because I want to teach the teams the lesson that they need to go dig those requirements out—that architecture is sometimes about trying to figure out how to get to the things that the users don’t think to mention. That’s why all the Katas don’t have mention of budget or deadline, either, both of which should be almost the absolute FIRST question the teams should ask. (You’d be surprised how many times they never actually do get around to asking that question.)
The best lessons are sometimes those that are learned “the hard way”, where they realize (ruefully) that a significant portion of their architecture addresses a point the business never wanted, and/or failed to address a point that the business REALLY REALLY REALLY wanted.
While I’ve done the “split iterations” thing as part of multi-day workshops, I generally only do that for groups where it’s more of a mentoring relationship than at a conference. I’ve got plans in place for doing a week-long “Architectural Class”, where we spend half the day talking about some principle of architecture, then break into teams and do a round of Katas, but have never had the chance (or the client) to execute on it.
Author, Speaker, Mentor