Hopefully you're here to talk about getting rid of Agile manifesto principle number 11. Everybody's on board with that Let's get rid of it So I'm Ken France with C prime I've met some of you this week. This is my first time to India. I I feel like I fit in already. I've been here about a week and a half I've adopted the local cultures. I can cross the street without a local with me now I can actually get across the street on my own. I Even drove a rickshaw myself for the first time last night Not true. Not true I'm not I don't fit in that well yet It's just a little bit about me. I've been a Agile software development for a lot of years originally as a practitioner and now as a coach So it kind of came up through that worked on large air traffic control systems initially and then I've helped clients across a variety of Industries as you see up there So we're gonna go through a little introduction of the problem. We're gonna talk about today I'll actually go through a case study of one of our clients that went through this journey as well And then I'll just talk about some of the best practices not only that that cop client applied But some other best practices you might want to think about yourself And then in the conclusion we'll decide whether or not principle 11 should really go away Okay, so the agile manifesto. I'm sure you've all heard of it. Hopefully Principle number 11 of the manifesto says the best architecture of requirements and designs emerged in self-organizing teams All right, so by the end of the session we're going to decide if that's really true can that happen at scale That was that what the manifesto was created for individual teams in mind really an individual team They should be able to emerge their own architecture. Well, what happens when you have 200 teams a thousand teams Should we just let it be a free-for-all? Everybody go ahead and figure out what their architecture should be go ahead and build it If you've attended some of Jez's talks today He talked about the goal is eventually you want to get to the point where individual teams are empowered to make decisions They have some control over how they deploy how they consume services How they emerge their design But can we just let teams go and do that on their own? Or do we have to give them a little bit of guidance for how to do that? So we'll go through this discussion talking about can we actually scale up architecture and design to large enterprises I've started a petition outside that will send to the agile manifesto sign ease That if at the end of the session we feel like the majority feels like we should get rid of principle 11 I'll have you all sign it Okay, and we'll send it to the authors and see what they say deal Let me jump right into the case study So there is a large retail organization with about 18 million customers About 2,200 stores 68 billion dollars of revenue and about 300,000 employees Sight spread across the United States and in here So a very complex environment The scope of the engagement was across their IT strategy security Operations enterprise architecture a very broad set of technologies and you can see some of the sample technologies that were involved there They had been applying some lean agile concept at a team level for a lot of years But now they were trying to scale it They were trying to take some of the success they had had on a small scale and scale it across the employees and the Systems that you see up at the top. And so obviously having been in business for a while There was a lot of legacy applications. There was a lot of legacy processes There was a lot of dysfunction in the way that organization operated And so the job was to take them from where they were instead of challenges that they had Projects versus products, right? You've probably heard about a lot of these challenges throughout the day How resources were assigned to those projects? How information was shared between them? How they deployed software slowly with errors Decisions were not data-driven so they were made largely by whoever had the most power or ever had the most authority to make those decisions And as we'll focus on in this discussion the last bullet Their architecture was centralized Right a very few people made a lot of the decisions and so the teams were not empowered to make decisions They had to go back to a centralized group So their architecture looked like this They had a few enterprise architects That put out some best practices You know define what the architecture was going to be and then establish review boards basically to ensure compliance with those rules So the solution teams that were out there trying to get software off the door fast in order for them to do pretty much anything They had to go to the architecture review board and get it approved So how fast do you think that was? Not very fast very slow right not empowered lots of interrupts lots of Decisions by people that maybe didn't have the local context completely to understand what needed to happen So it was a very inefficient process How does work come into the process? Well at the bottom you have all these different engineering and operations groups that would get possibly Production support items coming in new requests coming in And then you have the solution teams that were responsible for building it and what you ended up having was a lot of different point-to-point communications and discussions happening But there was not a centralized prioritization mechanism There was not a way to For the teams and solution teams to really understand who they needed to talk to within the engineering and operations group So it was sort of chaotic that everybody was talking to everybody And it got to the point where the solution teams would pretty much just say just just give us what you want us to do And we'll figure it out because they just couldn't deal with you know dealing with all those different folks at the bottom Then going back to the previous example when they finally did decide how they wanted to do it How they thought was the right thing to do it They had to go to the architecture review board to get approval before that I could actually head down that path on their solution So the very slow very error prone. So what do we start to move them towards? The the desired target state was a more decentralized architecture function Where you had a product owner a product manager somebody Centralizing the requests coming in and I'll go into more detail in that second a Principal architect responsible for longer-term architectural strategy, but then they coordinated with Domain architects that would work closer down to where the work is happening So you're starting to see the architectural decisions get distributed out They in turn would work with no architects possibly even embedded on solution teams But if not working very closely with the solution teams That again were aligned to the architect or architectural concepts and principles coming from the architects above yet they were now empowered more to take action make decisions and You'll see some of the other things that were put in place to really start to Ensure there was compliance to the architectural standards because they were offered as services as opposed to just standards So what intake started to look like is work would come into a centralized function Some of that work that was ready to be worked on from a solution perspective would go to the solution team Other work that needed maybe some architecture or runway some additional work before the teams are ready for it Would go to what was called a system team to start to work on centralizing some of that work there And I'll talk about how they started working with this engineering team So basically you started to have more coordination and distribution of responsibility Happening between the system team and the architecture team that would then feed services to the solution teams that would consume them And how did that start to happen a service catalog was created so basically a set of services that would have strapped these engineering services and What they would offer the solution teams to the point where if some of you attended jesus jesus converse presentation a few moments ago He would talk about this concept of if you have to ensure a compliant if you have to assure alignment to architecture Embedded in the services you're creating and then the people consuming those services in the service catalog can know that it Corresponds to the architectural standards because it was already validated that it does you no longer had to go to Centralized review board to say is it okay to head down this path because it was already approved tested vetted and the service catalog So those engineering service engineering services started to operate in a more templatized way So what there would be they would take and codify not only how to build infrastructure, but the services in templates They would create reusable components that those solution teams could then just plug together to satisfy to build the solutions they were building and And they basically would be able to get work out much more quickly and high quality by consuming these services As opposed to having to build them all as they had in the past the system team If you look at this system team think about it as a way to start to enable the teams over time to become more and more Self-sufficient and the early times because teams didn't have the skill set yet to build these services to do test Automation to do some of the things that would really lead to continuous integration and delivery So initially the system team had to stand up those capabilities for them and then teach the teams how to use them Okay The goal was not for the system team to do these things for the teams forever. It was to enable the teams So stand up a continuous integration server teach the teams how to use it Stand up a continuous delivery capability teach the teams how to use it Build a test automation framework that tests various layers in the architecture and teach the teams how to use it So that over time the teams become more and more empowered to take that work on themselves And not having to centralize it within that that system team that was supporting them So you can see build automation infrastructure as code test automation all these different capabilities The system team help enable the teams with to allow them to take more and more responsibility for the work themselves And so ultimately and they're still on this journey So it's not completely done yet moving to a multi-cloud and a microservices architecture That initially was centralized in its and its conception and in the initial creation of some of the services But then decentralized as those standards and services were created and validated so the teams now had the ability to Take some of that responsibility on themselves without having to go back to the architecture board over and over again KPIs and metrics started to emerge to really judge the health of is this team producing value on a regular basis Are they seeing the throughput? There's a lot of talk today about how do you measure teams and we don't want to measure on velocity? Right, so let's measure on how how frequently are we releasing? What is the throughput of features going through those teams? How quickly are we producing value? Let's let's measure those things So the whole goal was to upskill the teams make them more self-sufficient More capable of building a lot of this themselves So that's the client journey that they went on Now what we're gonna do is we're gonna talk about some of the best practices some of which I covered in there But we're gonna talk about a little more formally a lot of the best practices I'm sure many of you have implemented some of these yourself what I'm gonna focus on in this and the rest of this the talk here today is Agile architecture concepts and how some of those concepts scale Built into this to save the scaled agile framework And so safe talks about agile architecture as being a set of values and practices that support active evolution of design and architecture of a system While implementing new system capabilities So the whole concept of agile architecture as you want it to evolve over time while you're still supporting existing users You can't stop all development say we're gonna rearchitect and then start development again You've got to continue you've got to rearchitect While you're building new capability and supporting the current capability and it's all about continuous delivery and continuous flow If you're not an expert in safe just an overview There's four levels in safe a team level a program level a large solution level and a portfolio level And you can see there's architect roles embedded on each one And there may even be architects embedded on teams Enterprise solution system architect at each of these levels So going back to the concept I talked before You can't just let every solution team out there go to find their own architecture You've got to have some guardrails Some things in place that people will conform to So there's this concept of intentional architecture, which says here's the guardrails Here's what we're going to put in place to make sure we're all operating on a common set of architectures Some of you may that are familiar with safe You may know that one of the constructs that we'll mention here is something called an agile release train Which is a team of teams construct So you can almost think of the our attentional architecture and the architecture runway That's created from that as the tracks that the train runs across Then in order for the train to move forward there must be train tracks in place Well, who's going to decide what those train tracks looks like that's going to be some of the jobs of the architects at those layers Within that intentional architecture within that architecture runway teams then have the autonomy to emerge their design against that architecture So that they can start to operate more autonomously and still have flexibility to have, you know Local knowledge applied to what they're doing But they're doing it within the guidance of keeping everybody on the same page and make sure you can interoperate interoperate with each other So the balance between these two is the key You don't want to do too much upfront because then you're back to you know big upfront design But you also can't defer too much for the teams to figure out because then you don't can't interoperate and there's two Then you can't can ensure standardization So I'm not going to go into great detail, but each of those architects has a set of responsibilities There's certain things that they are responsible for That their job is to not only make those decisions But then rely on excuse me then take ownership of communicating that and staying aligned with the architects at the next level So that they can in turn continue to move that to the teams And you may not need all these levels in your implementation. This is the The scenario we're using all four levels So you may be using different versions of this and your enterprise depending on your complexity Those architects then operate across many different domains You may have business architecture information architecture application architecture technical architecture Each one of them is responsible each one of those domains has a different set of concerns and The architects may take different actions and use different tools based on those The enterprise architect is going to cut across many value streams They're looking at the big picture across many value streams within the organization Whereas the solution architect is going to focus across many systems within that and then a system architect may be looking at a single system Or a much smaller number Okay, so it's all about the span of responsibilities. They have so then there's a collaboration that takes place Notice I use the word collaboration not review board, right? It's not a it's not a Governance or compliance. It's a collaboration so that everybody understands what we've defined What their role is in it and ultimately for the teams how to implement it? So it's the collaborative aspect of These architects working together with each other and then in turn them working with the teams To make sure all of this is working well together architects role in DevOps Ultimately our goal is to get software out the door Okay What kind of things generally tend to hold us up and getting software out the door? How many folks have to go to architecture review board still today? How many folks have to wait for some other testing group to test your code first? All right, and I'm sure you could all come up with other examples of things that That you have to go and get approval for some sort before you can actually deploy So the goal in DevOps obviously we want to have this continuous delivery pipeline where we can get out the door very quickly So the architects role is really to help facilitate that at the end of the day making the solutions easy and obvious You know building components pre-built components together already defining standards Platform as a service and infrastructure as a service When it talks about the epic owner it means be the champion to establish those capabilities Right build those platforms that can then be consumed by the rest of the teams to really accelerate everybody's delivery out the door I like one of the One of the things just said earlier today that one of the biggest inhibitors is is change management Which basically makes sure that you don't change anything right Change review board is another big source of slowing down flow So how do we really make sure you know we get through that process? So really architects become the champions for DevOps to make sure that we're architected in a way that's going to allow us to do that So really at the end of the day architects really focus on enabling the teams And so a lot of what they do could be categorized as what safe calls enablers Enablers are really those things the infrastructure as a service those things those Prebuilt components a service catalog those are all things that in and of themselves in of themselves They're not directly delivering the business value that the end user wants But they're enabling us to do that faster because as a solution team my whole focus should be to get that business value out to the end user So the more that I can go to pre-built components and pull them and integrate them together and test them The better I'm going to be in that and so ultimately I lead to a model where I have Architects focused on how best to get this business value out the door that I see in my roadmap And the best way to ensure that we're getting the business value out quickly is to make sure that we're doing enablers Just in time for the teams to use and consume them Again, we're not too far out in front But we're getting there just in time that the teams have what they need to deploy the business value that they have So you you're able to incrementally look at and deploy enablement work through that architectural collaboration Just like you're able to incrementally deploy your business value And those two stay in lockstep So we have some architectural patterns in place We've had collaboration We're starting to put some infrastructures and service or infrastructures services in place Now when we're talking about executing day-to-day we have our plans We're executing day-to-day now what do architects do as the teams are actively coding and building? Well, they're helping remove those technical blockers So teams run into challenges. They're not fully enabled on a technology. They need help Architects stepped in and enable They help facilitate, you know, point-to-point communications between teams that need to collaborate Again, that could be done either by being embedded on teams Or but just by helping coordinate outside of that Some of the individual teams may actually be working on building some of those enablers Right, it's not necessarily the architects themselves that are writing the code for those enablers Some of those are actually going to some of those teams that have the capacity and the skills to work on those So those architects could be working with those teams to help them implement code and test them quickly Even by pairing with them on them So by enabling the teams to build some of those architectural components They'll be able to build more in the future easier to again continue to Allow everyone to be taking advantage of what those teams are building and this is something that For a long time was missing inside of the scaled agile framework There was a lot of collaboration happening around The scrum master and the RTE roles and the teams and the product owners and product managers But there wasn't a place for architects and and technical people to come together and synchronize on a regular basis So there's a new concept called an architect sink that basically allows it's a time and place on cadence for architects technical sneeze to come together Collaborate and align on strategy notice. It is not a review and approval board. You're not bringing your design for approval Okay, you're coming to learn about that intentional architecture You're coming to learn about what new services are being built You're coming to learn about or help contribute to what should the road map be for that enabler work So that we're building it properly and building it just in time for the teams to consume it So it's it's a more formalized way to facilitate that technical dialogue and communication That oftentimes happens in a very haphazard or non coordinated manner but the ultimate Sign that we're coming together is to be able to demonstrate value Okay, we want to get off the door as quickly as we can but as we're building these large complex systems Let's make sure we're demonstrating that on a regular basis You all familiar with the iteration review that happens in a sprint The system demo happens at the next level up the program level where you have multiple the output of multiple teams coming together Right drive to a demo On a very regular basis Same thing happens at the next level as you have multiple release trains So architects working with the system team can really help make sure we're driving to these milestones facilitated by that architect sync And allowing the teams to have that collaboration and demonstrate the value and get feedback and be able to adjust quickly to that Feedback as they move along So in conclusion How many people think principle 11 has to go you're going to sign my My petition out here anyone One person still think it has to go. Okay. He's a plant. I planted him So obviously principle 11 does not have to go right Conceptually the principle still makes sense, but you have to evolve it at scale Right, you can't let the teams all do their own architecture. So you have to figure out the proper balance between upfront centralized intentional architecture And decentralized emergent design based on the standards the guidelines the services produced by that That collaboration don't just assume it's going to happen set a cadence Right to find when those architects are going to come together with the technical smears from the teams to maintain alignment Don't make that just a firefighting meeting I've seen lots of organizations that they have what they call a tech triage or uh, you know The technical folks are coming together to put out fires Right make this a strategic meeting not a tactical firefighting meeting. Okay And then at the end of the day, you don't have to get it perfect up front Great is the enemy of good get started make some incremental progress and hopefully you'll improve your continuous delivery pipeline We have a few minutes for a question or two Five minutes any questions Yes, correct The the uh observation was the architect sink was not part of safe 4.6. That's correct. I am giving you a preview here I got it. I got special permission from scaled agile to give you a preview of something that's coming This content you might have seen a newly released safer architects course So these are this is some content from the safer architects course that's going to be in the course Before it officially makes it in the framework. So yeah, you're getting a little preview here. I meant to mention that earlier. Thank you This is a preview. Yes Yes Yes Yeah, I think a lot of the challenges that you had to overcome were just cultural, right that um the The architects that that traditionally would make those those centralized decisions had a hard time giving up some of those That decision-making criteria to the other architects. So I think it was just realizing that um In order to be able to leverage some of the more local information in the different domains And as you got closer to the teams the enterprise of the principal architects, you know Couldn't be the decision maker for all of those things that they had to allow some of those decisions to be made locally with some Guidelines from the higher levels. So I think the culture was a big part of it And then just really you know a little bit more formalizing when that interaction and collaboration occurs and really defining the boundaries for each Of those roles was a key part of that Yeah, so the the comment or the question was that that architect sink If not done well could look just like an architecture review board that you're used to having so what are the best practices around that So the so the first is is literally in the name itself, right as an architect sink You know so changing the name Um and obviously I only showed you a highlight of it But there's much more detail on on how you run the meeting and what it looks like So I think at the end of the day, it's it's understanding the context of the purpose of that meeting is to You emerge and evolve the architecture not to ensure compliance to the architecture That's correct. Just like the rte and st e facilitate improvement. Same thing you need there Absolutely. I think we have to cut it off. I will be outside for more questions. Thank you for coming


Welcome to Spotlight. I'm Anne Muir. And I'm Liz Wade. Spotlight uses a special English method of broadcasting. It is easier for people to understand, no matter where in the world they live. A woman in the United States is making a meal. She chooses a recipe from a recipe book. She will follow this recipe, adding each different food at the right time to make a good tasting meal. The recipe begins with common foods. First, she adds some juice from a sour lemon. Then she puts in some olive oil and a small amount of sweet honey. She adds some salt and pepper spice. Finally, she is ready to add the protein or meat into the meal. Does the recipe use chicken, fish, pork? No, the final ingredient in this recipe is katydids, a kind of insect. For many people in the United States, insects would be a very surprising ingredient. There, eating insects is not common. But this recipe book is trying to change the way people in the United States and other Western countries think about eating insects. This book contains recipes for people to make food from insects. It is called the Eat a Bug Cookbook. The writer of this book is David George Gordon. In his book, he tells about the reasons that people should eat more insects. Eating insects is good for the environment, public health and also the economy. Today's spotlight is on eating insects. Experts estimate that by 2050, there will be 9 billion people in the world. Almost a billion people already suffer from hunger every day. Our Earth has a limited amount of resources like land and water. If we do not have enough food for the people on our Earth now, how will we have enough for another 2 billion people in 2050? These are the questions that experts around the world are struggling with. The Food and Agriculture Organization of the United Nations released a report in 2013. It explained... The problem will be worse in the future. We need to think about what we eat and how we produce it. We need to find new ways of growing food. The report suggested that raising and eating insects was one way people could solve this problem. There are over 1,900 different kinds of insects that people can eat. The most common are beetles and caterpillars.  In fact, insects are part of the traditional diet of over 2 billion people. For example, in China, some people cook insects over a fire. They put the insects on a stick. The cooked insects are served on the street as street food. They are also served in restaurants where food costs a lot of money. In the country of Ghana, people collect the termite insect in the springtime. They grind the termites into a kind of powder similar to grain. They use the ground termites to make bread. Insects are a part of traditional diets because they are a very healthy food. They contain almost as much protein as a serving of meat from a pig or cow.  Insects are high in vitamins and minerals. And insects are also low in fat and cholesterol. Substances that are necessary for the body but only in small amounts. Eating insects is also very good for the environment. Insects need fewer resources like land and water than larger animals. 90% of the fresh water people use goes to farming and raising animals. Marcel Dicke studies insects. In a TED talk, he explained how insects also produce more meat from the food they eat. For example, imagine a farmer. Imagine the farmer feeds a cow 10 pounds of food. Those 10 pounds of food produce about 1 pound of cow meat for people to eat. However, imagine the farmer gives cricket insects 10 pounds of food. Those 10 pounds of food produce 9 pounds of cricket meat for people to eat. Eating more insects can also help people in poorer communities. Many people can raise and sell insects. Raising and selling insects is a job and food. But insects will not replace livestock meat very quickly. First, people in some countries would have to change how they think about eating insects. Many people in North America and Europe eat a lot of livestock meat like pigs and pigs. But they do not traditionally eat insects. They do eat some products of insects like sweet honey from bees. But it is not normal to eat a whole insect in any form. In fact, for many people eating insects sounds insane. They believe insects are dirty and dangerous. Insects make people feel uncomfortable. Some people are trying to solve this problem. For example, we talked about David George Gordon's recipe book at the beginning of the book. His recipe book tries to show people that eating insects can be delicious and easy. Other insect experts travel and tell people about the great effects of eating insects. But they still have a lot of work to do. Another challenge is creating rules and laws for insect producers to follow. There should be rules about how to raise insects safely to eat as food. People also need to decide how to eat insects. Will they be whole? Will they be ground into powder like a grain? Or will food scientists discover a way to take all of the great food substances from insects and serve them in a very different form? These are all questions that people can answer in the near future. But there are people who want to answer those questions now. Jose Andres is a master chef in the United States. He has won important awards for his cooking. He serves insects in his restaurant. He believes that finding new forms of food is important for the future. He told the New Yorker magazine We need to feed people in a sustainable way. In the future, the people who know how to produce protein will have an advantage for everyone else. Will insects become the world's main source of protein in the future?  If you do, what insects are your favorite? And how do you prepare them? If you do not eat insects, let us know what you think. Leave your comments on the script page of this program or find us on Facebook. Just search for Spotlight Radio. The writer of this program was Liz Wade. The producer was Michio Osaki. The voices you heard were from England, the United States and England. All quotes were adapted for this program and voiced by Spotlight. You can listen to this program again and read it on the internet at www.radioenglish.net This program is called Eat Insects. Save the World. We hope you can join us again for the next Spotlight program. Goodbye.


One of your blocks is people who have self-portraits of themselves as artwork in their homes That is very funny.  I'm not yourself to your family Yeah, I've never talked with anybody that that had that on the wall and like asked them what that was I think it's started I first of all it's always guys a hundred percent of the time it is guys Also while we're on the subject of things only guys do that what there are no female juniors There are none Alice June it's all male ego like when people think of him They think me that he's came from me. It's like alright, dude. Let the kid have a life


At their annual auction in November, Painting for a Purpose sells painted furniture and the proceeds are used to support students in Portland Public Schools. Tom taught with co-founder Tina Clark Edwards about the organization's work. Tina, thanks for joining us. Thanks, Tom. Glad to be here. Painting for a Purpose has a big auction coming up, but before we get into that, can you just describe briefly what Painting for a Purpose is all about? Painting for a Purpose is a group of people who really care about education in Portland and also really like to paint. So we started in 2009, a group of, there's really women, but we've expanded a little bit, who meet weekly to paint sort of whimsical furniture and then we have an auction in November 8th and we sell all that furniture and then that money goes into a grant fund for kids in the Portland Public Schools to write grants to us about how they're going to make a difference. So we call that Youth-Led Service Learning Grants. And how did the idea come about to create an organization like this and actually have kids solve their own problems in the schools? Part of it came about because the two of us who founded it, Jane Ellis and myself, both had been involved in youth grant making and were really excited by sort of the power that we saw when kids were given money for their ideas and just the excitement and the sort of creativity. And so we also discovered that we had this mutual love of painting and we were walking on the beach one day and said, I had also been a part of a painting group that I had gotten acquainted with in Cape Cod and I said, I really want to do a painting group in Portland. And so we were talking about that and we said, we want our painting to be for a purpose. We really love doing fanciful furniture and painting, but we wanted to go for something else and then we just sort of looked at each other and it was like, hey, it's a painting for a purpose. And so we wanted it to be for this youth led service learning. Now you have some amazing stories about some of the problems children have come up with and their solutions. Can you talk about those? Yeah. I mean, when I say youth led service learning, that really is where students, young people in Portland identify issues or problems that are important to them and they have to research them just like an adult would and they have to document that so it might be through interviews, surveys, things like that. And then once they understand the issue, then they come up with a solution. And then they are then responsible for writing a grant to us and making their case. So some of the projects that we funded, last year we funded at Presumskit School, the fifth grade had done a survey of wanting to know what were sort of the issues in the school and what was identified as a top issue was that the cafeteria was a stressful place for students and that oftentimes teachers would take kids back to their classrooms to eat for lunch rather than be at the cafeteria. So one particular young woman wrote a grant about creating an outdoor space where a teacher could take a classroom of kids at lunchtime. So they have a boulder garden now, which is a safe, calm space for kids to eat lunch. Another one is at Lyman Moore School, they decided that their school was unwelcoming. So there was a club of students that decided that they wanted to create a mural and so they worked with an artist. So we funded the artist to come in and the beautiful mural there now. We funded two places at Lyseth and at Casco Bay High School. They identified that they wanted healthier choices for eating, so they both created school gardens. They also wanted to show students where their food came from. So those, that's- What a great, what a great opportunity for learning about the community, about being involved about their own empowerment. Now just, I'm sure people would be motivated to support something like this. Can you talk a little bit about the auction? We have some examples right here. I can talk about the auction. Yes, this year we've changed it up a little bit and we decided we wanted a little bit more of a theme. So one of our members designed lobster boats and so, and then another member and her husband cut them out. So these are made with love and then we had, we asked local artists to actually partner with some young people from Portland Public Schools art classes to paint boats. So these, some of these are a collaboration between students and adult artists and others are just artists, but they're all going to be sold at our November 8th auction at Grace Restaurant. There are other items also for our children? There are other items. These students also painted dories. Oh wow. And so they're, so some of them go along together and then group of us who meet weekly the core painting for a purpose group and others have painted all sorts of fanciful furniture. So that'll be in the silent auction. Great. What would be the starting bid for something like this? $10,000. Good. Well, I'm sure somebody will bid that. People want more information. Where can they go?  Yeah, we definitely would like to have people there. Great. Well, thank you for joining us. Keep your eye out for the boats and dories which will be on display throughout the city during the month of October.


Another week, another round at the top of the table and another episode of Bay 46. I'm James Stradenick. Thank you for tuning in on game day for what will be our third last home fixture of the season. At least until the final series anyway. And in fact, it will be the third last fixture here at Pertech Stadium as it currently stands before the whole thing is knocked down and rebuilt. Now, if you thought Wonderland was imposing now, just wait until a new $300 million 30,000 seat stadium comes together. A little shed, as described by one rival, a league coach who share a main nameless grey mullet, will soon be the envy of the league. Meanwhile, on the field, the Wanderers boys are sitting very pretty, returning to the top of the table after one old draw with Sidney FC last week. It wasn't our most polished performance, but Dario Vitisic's sublime header was enough to secure a point which allowed us to leapfrog Brisbane and return to the top of the table. And what about that away support? It's not very often that a team can travel to an away stadium and make it feel like a home match. But then again, you guys aren't your average set of fans and the Wanderers are very thankful for it. He's hoping we can carry that momentum off the pitch and into tonight's game. And tonight's game against Perth Glory will be a tricky one. Perth are in fabulous form, having won their last five games including last week's massive thumping of Brisbane Raw 6-3. They now sit one point outside the top six and if any team in the Hyundai A-League is desperate for a win this weekend, it's Perth. It's a thought not lost on Wanderers defender Scott Jamison himself, a former Perth glory man who spoke about how tight the ladder is looking in the Hyundai A-League. Well, seven games to go. You can't figure every game to test now and especially after the way the tables panned out. I mean, I think five, six weeks ago everyone thought the six was made and ourselves and Brisbane were in a way looking to sew up the top two and it's kind of fallen into place now where it's tight as hell and yeah, seven games to go. So I think regardless if we're playing Perth or Central Coast who are at the bottom, it just be as big as game. The Wanderers are set to be boosted by the return of Spanish defender Alberto after sitting out the last two games through suspension. Popper spoke yesterday about how important it was to have him return to the game. Yeah, he's done very well for us. So it was a shame that we missed him for a couple of weeks for the reason that we did. So he was pretty disappointed with that himself and he's been training really hard for a couple of weeks and you can see he's really determined to get back out in the park and help the team. So that'll be a real boost. One man who we hope to keep you spot in the starting eleven in tonight's game is the Wanderers newest debutant, Liam Reddy. Reddy put in a very solid performance against Sydney FC in last weekend's game, both with the ball in his hands and when commanding the back four. Let's not forget, he's one of Australia's most experienced goalkeepers and if Popper does decide to use him in tonight's game, no doubt the back four will be very confident knowing that Reddy has their back. As previously mentioned, the Wanderers are sitting at the top of the Hyundai A-League ladder and they are the team to beat. And although the Premier's plate is firmly within reach, the boys should not be feeling any pressure because as we know, when the Wanderers are firing, they are damn near impossible to catch. Well that's all for another week of Bay 46. Do not forget, the Western City Wanderers play Perth Glory here, Perth Tech Stadium tonight. Kick-off is at 7.40pm. If you can't make it, it is being televised, SPS2 and Fox Sports 505. That's a lot of words. My name is James Drudinick. I'll see you next time.