Quality requirements incorporated in the Katas

[Mario Ek Aparicio]

Love the idea of Archkatas-site. I have both attended and hosted a few katas at several occasions, but not katas from this site.

There's one really important thing me and some of my colleagues agree on; Quality requirements greatly affect the chosen architecture. Therefore we have tried to emphasize this in some of the Kata sessions we've done. Some of the example Katas on the Archkatas-site have quality requirements incorporated such as (thousands of users, near-real-time sync, etc.) but not all of them. I belive all the katas should have some form of quality requirement that drive the architectural choices. It's even better if katas have more than one, possibly even competing, quality requirement requirements. Our experience is that the customer always has some very important quality requirements, but they are very bad at specifying them explicitly. These requirements affect the architecture deeply and you may end up designing a totally useless solution if you lack the most important quality requirements.

Example: you design a case handling system to handle 200 000 users while in reality it will only have 200 users but it is crucial to be able to do changes in business rules quickly.

[Martín Salías]

Hi Mario.

After running several arch. katas I think this is the main role of the facilitator. Something I start doing a long time ago is to break the design time in at least two sprints, so that teams can have some feedback on their approach. During the first review I let the teams present their solution so far, and others to ask questions, but I also take the chance to act as the product owner and I make a point of setting specific quality attributes.

It is interesting to see how most of the time, even as I explicitly tell all teams that I will act as the customer and they can ask whatever they want (my only rule is that my answers are a minute long at max), most of them don't ask and instead tend to "assume" lots of requisites. Thus the first review is usually hard for many teams because some of the QA I make clear tend to hit hard their designs...  :)

Regards,

---
Martín Salías

--
You received this message because you are subscribed to the Google Groups "ArchitecturalKatas" group.
To unsubscribe from this group and stop receiving emails from it, send an email to architecturalka...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mario Ek Aparicio]

I agree, doing a Kata in several iterations is a good idea. I've done something of the like in one occasion where iteration 2 was about what you would have done differently if you knew the quality requirements up front. We even hinted about the quality requirements in the case-handouts (disguised as architectural principles) but no one really looked much at them :)

However if you don't have time to do several iterations it's a good idea to at least vaguely express your quality requirements in the kata. This has an educating effect since the participants were given important information that they took into account or (more commonly) ignored when they designed the solution.

-Mario

---
Martín Salías

To unsubscribe from this group and stop receiving emails from it, send an email to architecturalkatas+unsub...@googlegroups.com.

[Martín Salías]

Agree. I usually run at least two iterations of 30 minutes each. This leaves me about a 5 minute review per team on each review round.

Something else I do regularly is using some sort of currency distributed among the attendees for the final voting. I've used my own business cards, or sugar packets, or pens (it can be great if you have Monopoly money handy). I distribute the currency evenly between attendees, and then let them go and "invest" their funds giving them as they please to another team's representative. This is funnier than just hands-up. :)

---
Martín Salías

To unsubscribe from this group and stop receiving emails from it, send an email to architecturalka...@googlegroups.com.

[Ted Neward]

Martin—

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.

Mario--

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.

Ted Neward

Author, Speaker, Mentor

http://www.newardassociates.com

t: @tedneward | m: (425) 647-4526

[Martín Salías]

Hi Ted.

I agree about the "investor" mindset. As my goal is usually lead them to the importance of a well justified and thorough architecture, I ask them to use their budgets as CIOs or CTOs, rather than VCs. Sometimes I ask them to think they will be in charge of put their chosen solution in production and maintaining it.  :)

After a few runs, I got to a good rhythm doing two sprints in about 2 hours. On conference slots of an hour I keep all in a single shot. I tried once or twice in 45 minutes slots but it was to tight.

Regards,

---
Martín Salías

[Ted Neward]

Yeah, I started at conferences doing this in a single one-hour conference slot, but I actually found that too tight, myself, and decided to go to no shorter than a half-day tutorial/workshop—I wanted to give people time to flesh out ideas more fully.