Craig Larman - Opening Keynote Part 2

It's non-stop geeking around here and no mistake.
We're in the conference halls from 9am to 7:30pm. I hoped to be able to get more typed up between talks, but the generous-looking half hour between keynotes and tracks and presentations turns out to be little more than enough to grab coffee. So, sorry for the interruptions to the posts. I guess it helps to keep them shorter.

So, when we left Craig, he was introducing us the design pattern for scaling Scrum teams.
Several ground rules. Number one - co-location.
Steven Elop has certainly identified a Nokian anti-pattern (if you will) for Scrum teams where team members are spread over thousands of miles and several timezones. At Nokia, it will be stopping from about RIGHT NOW and never happening again. Craig Larman would be proud of him. Absolute number one no no.
Like I said, Craig has mastered the art of reminding you of the simple stuff in a sensible way. Simple should never be neglected and never taken for granted.

So, scaling Scrum teams.
Product Owners have a product. They present their wish list to all their scrum teams and the teams pick them off the top. Important, but subtle thing here - the PO does not decide which team gets to do what. They are all multifunctional, self organising, learning enabled teams.
So far, so Scrum. But it's nested.
Add a layer above it. Take three or four POs and their Scrum Masters and let them have a meeting with a PO responsible for all of their products and let them get their stories here.
The SuperPO presents her wishlist and the POs do exactly what the Developers will do one iteration down the stack. They agree to take on stories to take home to their devs.
And that has to be pretty much infinitely scalable, giving the ability to build massively complicated applications where every step has been signed up to, agreed and delivered.
Which is why Craig Larman deals with CEOs and CTOs. A methodology change of this size requires organisational change from the top down.

Politics must not decide architecture.

How do you design in a structure like this?

If you are already familiar with the concept of Communities of Practice, you already know the solution.
The Communities of practice idea taken to it's logical extreme is that everyone is a member of a scrum team and a "Community of Practice".
These are single-interest groups - UX / Database / Creative / Scrum Masters - wherever people feel they belong. You could consider our Tech Talks almost as Communities of Practice, if they were to involve more scrum teams.

From these, through pair programming and team workshops, the actions taken from the Communites make it into the development teams.
And that there was the biggest shock for me. Didacticism must die. I am horribly guilty of this.
I like chalk and talk. I used to teach English Grammar, for goodness sake. And computer programming. In separate, previous lives. Chalk and talk (teacher standing up at the front of class imparting their hard won wisdom by drawing, writing and talking. All at the same time :) ) has worked for hundreds of years. I also like being the student. I learn well in a classroom situation.
But it presents a barrier. Those learning are generally seated and attentive, the one teaching; standing and authoritative. And that's not the point here. It's not about distributing what is in one head and putting it in another, it's about a common approach to finding the best solution.