All right, welcome to this enterprise day. This rocket is carrying the Mars climate orbiter. It's December 11th, 1998. And the purpose of the spaceship being carried by this rocket is to study water and water distribution and atmosphere on Mars. After launch, it's going to spend 286 days in space, traveling 669 million miles or a million kilometers. It's going to arrive on September 23rd, 1999. Upon arrival, the main engines will fire for 16 minutes and 23 seconds to slow into orbit. And then it's going to use the solar panels to drag against Mars' atmosphere to gradually convert that wide elliptical orbit into a nice circular orbit. So here we are, December 11th, 1998. The spaceship being carried by this rocket costs $193.1 million to develop. The launch costs $91.7 million, and there's $42.8 million budgeted for mission operations. $327.6 million total. This is part of NASA's smaller, cheaper, faster initiative. 286 days later, September 23rd, 1999, nine o'clock and 46 seconds universal coordinated time, the main engine fires. 9.04 a.m. and 52 seconds, communication is lost. This is expected. The spacecraft is going to pass behind Mars' shadow. It's going to block communication with Earth. But it's a little bit early. It's one minute and eight seconds early. Communication is expected to be re-established at 9.27 a.m., so I can only imagine that the mood in the control room was tense as they waited for those minutes and seconds to tick by. 9.24, 9.25, 9.26, 9.27, 9.28. Communication is never re-established. And two days later, the mission is declared a loss. $327.6 million, countless years of effort down the drain. Now this is NASA, and NASA being NASA, they investigate and they figure out what happened. What happened was that the trajectory was just a little bit off. It entered orbit too low, and instead of dragging against the atmosphere and forming a nice orbit, it instead burned up in the atmosphere and was lost. They investigated further. NASA's good at this. They take their root cause analysis very seriously. And what they found was that one team that was producing information for some of the trajectory calculations produced their information in a pound seconds of force. And the team that was working, that was depending on them, expected the answers to be produced in Newton seconds of force. So it was a U.S. metrics measurements versus metric measurements problem. The moral of the story is that large systems are hard. And every time you have cross-team coordination, you're subject to delay and error. And if it can happen to NASA, which is famous for their code quality practices and their attention to detail, and spending huge amounts of money on these problems. If it can happen to NASA, then it's gonna happen to you too. Cross-team communication is hard, and yet as agile has become more and more popular, more and more proven, it's being used on larger and larger problems. How do we make agile scale? How do we grow agile to work in these larger problems? Well, before I answer that, I wanna make a definition. I wanna define what I mean by large scale agile. Large scale agile is a system of interdependent agile teams. Teams that have to work together in order to get their work done. They rely on each other to achieve a joint success. So if you have an IT organization with 500 teams, that's a lot of teams. But each team has their own stakeholders. Maybe they do a bunch of sequential projects. A team takes on a project, works for its stakeholders, and then delivers the project, goes off and does something else. If you have a situation like that where all 500 teams are working independently, that's not large scale agile. It's big. It's a lot of teams, but each team is working on small scale agile. You don't need to coordinate. Conversely, if you've got 20 developers in a company, and they are in multiple teams working on a single product, that's large scale agile because those teams have to coordinate, and now you have the problems of cross-team coordination. You've got the delay and error that results from cross-team coordination. So large scale agile, despite the name, isn't about the size of the organization, but rather about the existence of the need for cross-team coordination. Large scale systems are air prone, and I would suggest avoiding them if you possibly can. Rich Sheridan, who gave the keynote on Tuesday morning, he's the CEO of Menlo Innovations, and he's got 70 people, 70, 80 people in his organization, all on one team, which means that he gets to avoid these problems of large scale agile cross-team coordination because they all work together on all of the projects. They do a lot of very rigorous pair switching and code ownership and code quality practices to make this work. But eventually, it's very likely that you're gonna be on a product that has a need to involve more people than even that. And I think that for most organizations, 70 people is gonna be an outlier. I don't think that most organizations will be able to get up to the level of rigor that Rich is talking about. And you're gonna need these large scale ideas. Existing approaches to scaling agile tend to focus on what's safe and acceptable, and it's even in the name of one of them. We've got safe, less, nexus, dad. I think we're gonna hear about dad next. The problem is, is by focusing on what's safe, what's palatable to the enterprise, I think they're missing some of the spirit of agile. Now this isn't a dig at safe, even though I'm saying to avoid safety. This isn't a dig at safe, or the other methods that do this. That's an understandable attempt to satisfy the needs of the market. But this isn't where agile came from. Agile isn't safe and acceptable. The original idea is, I mean it's not that kind of safety. It's about doing things that are rigorous, creating great results, and that is actually a very safe thing to do. It's a very safe thing to produce software using something like extreme programming, which has a lot of attention to code quality. But it's not acceptable. It's not something that you can take into an organized organization and say, if you do this, you will never fail. And in fact, the early ideas were anything but safe. We had, they were bold, they were extreme. It was in the name of one of them, extreme programming. They rejected the status quo. Ward Cunningham told me, and I don't remember the exact details. I didn't write this down at the time. So I may be misquoting this, but he told me that Kent Beck chose the name extreme programming so that people who weren't willing to try it, so people who wanted to sell stuff to other companies wouldn't use it because the name was too extreme. He succeeded, unfortunately, maybe. Nobody uses extreme programming anymore. The people who wanted to sell something but didn't really know what they were doing, but wanted to make a quick buck, they migrated to using Agile and Scrum. That's not because Agile and Scrum are bad or wrong, it's just because they're safe. They're easy to sell. Can you imagine anything less acceptable than Agile in the early days? I was there, and I remember the countless flame wars that erupted from this work. We were telling people, don't plan things in advance. Don't figure out everything you're gonna program before you program it. Don't understand all, don't try to figure out everything that you want to build. That's lunacy. That's absolutely crazy. It is not acceptable and safe, but it works. And it works better than the other things people were trying. And so now the enterprise does want it. And they still want it to be safe and acceptable. And there's a contradiction here, isn't there? We have ideas that aren't acceptable, but a desire to package them so that they are. But you know what, let's not worry about that. Let's not worry about the enterprise. There's a lot of money to be made there and other people will solve that for us. For now, for today, let's think about what's going to work. Not what's effective or not what's acceptable, but what's effective. What's really gonna make a difference? What if we rejected the status quo? What if we rethought team coordination and planning and ownership? That's what this talk is about. Now this isn't just theory. My current client is over 1,000 people. I can't say how big the engineering organization is in this company, but I am allowed to tell you that the office that I'm currently working with has about 300 people in it, the primary office I'm working with. I'm typically, and that's typical, I typically work with organizations that have up to 200 or 300 people in the engineering organization. I'm usually brought in by senior execs, typically at the C level. And what's neat about being brought in at this level is that the folks who bring me in, the people who work at this level, they are excited and looking for inspiring ideas. They're excited by cutting edge, excited by innovation. And the work I do is intensive. I usually work day in, day out with a company for several months and then I follow up for a year after that and then I usually stay in touch in the years that follow. What this means is that I get to see what happens when my ideas run up against the hard rocks of reality because we always have beautiful ideas that look perfect and wonderful and wrong until we try them and then we learn new things. So I get to see the consequences of my actions and as a result, what I'm doing today and what I'm talking about today is very different than what I originally wrote on the subject six years ago. That said, even though this isn't all theory, it's not proven either. When I was working with teams doing team immersion, I was seeing that things were pretty predictable. Given a certain context, there was an obvious set of practices to put into place that would lead to good results. It wasn't easy and for those of you who are team coaches, you know that this is not easy but there's a lot of books on the subject. I wrote one, too. And you pretty much know how to do team level agile. At the enterprise level, no, not at the enterprise level, at the large scale agile level, these multiple interdependent teams, I'm learning new things every single time I work with one of these companies. So the ideas I'm gonna present to you today are not proven ideas, they are just the latest in a sequence of ideas. I am slowly assembling a suite of principles and practices but it's not done yet. I also wanna, I'm not gonna mention any company names in this talk but I do wanna say thank you to the people who have worked with me in these various companies. They actually have done a lot of work to help develop these ideas. It's a black screen, there's nothing wrong. There's nothing wrong, this slide is blank. Thank you. So I can't say the names of the people who have helped develop these ideas but you know who you are and think. Of course, everything needs a name, right? We need to know what to call this. We've got SAFE, we've got LESS, we've got NEXUS, we've got DAD. So what should we call this? Let's call it bold, bold, be bold. Oh, now we do have a problem. Okay, so bold, what does bold mean? Now that we've got the name, we've gotta figure out what it stands for. Let's try big, audacious, lifelong dream. Terrible names, forget it. Let's just call it the shore model. March 2016 edition. There are no courses, no certification, no fancy website. This is just me talking to you about what I've seen, what I've experienced and what I think. And I hope you'll take these ideas and be inspired and try some ideas in your organizations and then tell me about it. And there'll be you talking to me about your experiences and about what works. And I'll take those ideas and I'll steal them and I'll try them out and then we'll have the March 2017 edition. So yeah, just some ideas based on experience and a desire not to accept the acceptable mediocrity but instead to try to create something great. So what if we rethought all these ideas? What if we rethought team structure? This here is a picture of the teams and dependencies at one organization I have worked with. I am not lying. This is totally true. By the way, could I get some water please? Every card, thank you. Every card on this picture is a team. Every line is a dependency. And if dependencies result in delay and error, you can imagine that there was a lot of delay in this company. Is this something unusual? I don't think so. I think this is pretty typical.  It wasn't easy to create. We affectionately call that the spaghetti diagram. It wasn't easy to create that spaghetti diagram. It took us about four hours of about 30 people all working together from the various teams. And if the organization had been any larger, I think it would have exceeded the ability of our brains to figure out how to group things. Because we did, believe it or not, we tried to group it so that things with the most dependencies were closest together. But I don't think this experience is unusual. Those of you in the crew, how many of you are in an organization with more than 20 teams who are interdependent?  Keep your hand up if you think that your diagram would look something like this. Put them down if it's nice and clean. I saw two or three people out of the 20 that raised their hands put their hands down, maybe 30. I think this happens because of a very obvious thing to do. You've got a team that's working on a product, and it's a nice cross-functional team. Let's say it's a software as a service website. You've got a nice cross-functional team and they are doing everything on the site, and the product is successful and the team grows. And eventually it gets to the point where you just can't be effective as a single team anymore. So you split, and how do you split? Well, the people on the team are programmers. I'm a programmer myself. And there's an obvious way to split things when you're asked to, and that's to split it the way programming is done. You split by layer. And that works fantastically in software where communication between layers is perfect and instantaneous. But for human systems, what you've now done is create a dependency for every single thing you want to do. Every time you want to add a new feature, you've got to make a change to the front end and to the back end. That's the typical split, right? Is to have a front end and a back end team. Now every single thing you do requires those teams to coordinate. This maximizes dependencies. So there is a common Agile alternative. It's feature teams. This was originally introduced by Craig Larmann and Boss Bodhi in one of the original books on scaling Agile. The idea here is that we have a single backlog and then a bunch of teams that can pull from that backlog. The teams collectively own all of the code. And whenever they finish their current feature, they just go to the backlog and pull the next one off. They can work on anything. This is a very Agile idea. Cross collective ownership, just go take whatever's next. It's very Agile. And I don't think it works. At least I don't think it works very well. What I've seen with feature teams, and I'm not the only one to notice this, is that it seems to lead to code quality problems. And it's very, very tempting when you're designing methods, particularly when you're designing enterprise methods to pretend that code doesn't matter and that all we're gonna do is structure the system. But we are building software and we have to pay attention to the fact that we're working in code. If code quality suffers, then our ability to get things done suffers. Then you start hearing people muttering about technical debt and legacy code and searching the want ads when they're supposed to be working. We have to pay attention to code quality, otherwise we can't get our stuff done. And feature teams seem to lead to problems with code quality. The thing is that collective ownership works very well inside of a team where you've got the peer pressure and the pair switching and the test-driven development, all this stuff sort of happening to keep code quality high. Hopefully you have those things. Otherwise you probably have code quality problems. But when you have collective ownership across teams, something very human takes over. We're basically chimpanzees, we're primates, and we love to form tribes. And then we love to throw poo at each other because that's what chimpanzees do. We form tribes and then we throw poo at the other tribes. Menlo innovation doesn't have this problem. And I think that's because they have one team. They have very rigorous approach to pairing across all their projects. They have a really rigorous approach to code quality and test-driven development. They have one team. But for feature teams where the teams are fairly stable but then they're pulling features from this common backlog, it's fairly easy when under pressure, when under time pressure. And we are always under time pressure, aren't we? Always. It's very easy when under time pressure to see something that's poorly done and to say, well, yes, we collectively own this, but that team wrote that code and that's their problem. We've got other things to do. Or conversely, to say, we've got a lot of pressure, we've got to get this stuff done. Yes, I know what we just built isn't that great, but one of the other teams will fix it. It's ironic that these two statements will come from the same team because they are mutually contradictory. Michael Feathers has said the same thing. He has a great talk-up. I recommend that you look it up. It's called Conway's Law and You. And he talks about how feature teams, as one part of a much bigger talk, he talks about how he has concerns about feature teams and code quality as well. So we need to rethink our teams. Before we look at that, I want to talk about dependencies. So what we want to do is rethink our teams to deliberately minimize dependencies, but I do have a specific definition of dependency. A depends on B if A needs B to do work for them in order for A to accomplish their goals. Just using another team's software isn't a dependency. And if you have a lot of dependencies, then you probably have a lot of delay and error as well. Now, I know this is a bit of an unusual definition. If you use Microsoft Word, in a sense, you depend on Microsoft, but you don't really depend on them to get your work done. They're not a source of delay for you. They may be a source of error, but Microsoft Word is pretty good these days. The primary approach I take is full ownership teams. This is actually a fairly well-established agile idea. What we do is when we want to have a, when our team grows and we want to split it, rather than splitting it by layer, we split it into separate teams that can own an entire segment of the market from UI all the way down to database, whole thing. So for example, if we have our Software as a Service web app, maybe we split it into three different market segments. We've got the landing page and sign up an account management team. We've got what you see when you're signed in team, that's the actual product. And then we've got maybe the administrative team that handles administrative work that the company does internally. And you can see how you could continue to split. The what you see when you're signed in team could eventually split into this part of the product and this part of the product and this part of the product. But even so, they'll own the whole thing from front to back. Every step of the way, we're trying to maximize ownership so that each team is completely in charge of the thing they own. They don't have to wait for anybody else to do anything for them. Those of you who have tried this know that I'm leaving out something very important, which is that this doesn't work on its own. In a large organization, you're typically going to have a lot of stuff that doesn't fall into this full ownership model. You're going to have some common needs, for example. Typically, you're going to have legacy code that can't be split up. You're going to have shared components, services, or databases. And you're going to have specialized knowledge that doesn't make sense, or you simply don't have enough people for every team to have one of those people. So you might have, for example, security needs or a user experience design that you don't have enough people for every team to have a user experience designer. So I have four techniques for you. The first is full ownership. It's the most powerful technique. And this is where I advise you to start if you're looking at your organization and how you can design your teams to minimize cross-team dependencies. We're looking at cross-functional teams, vertically integrated, so they've got all the skills on the team. We're going to accept some duplication of effort, and this is hard for programmers. But if you've got two teams and they're solving the same problem, let's say they're parsing a configuration file. And both teams are solving this problem. It's very tempting to say, hey, let's make a configuration file parser and pull it out into its own team. Let's dry it up. Let's eliminate our duplication. That's good coding, right? Well, yes, it is good coding, but it's bad team structure. Because building that parser is probably only a day or so of work. But introducing a new team and a dependency and a bottleneck so that anytime you want to change the parsing of the config file, you have to go to somebody else and wait, that's going to cost you more than that day of effort you've just saved. So what's the right amount? When do you split your teams apart? When do you pull those common things out? I don't know. I know that something that's a day of duplicated effort, that's not worth it. There's not enough benefit. The delay you'll get from that extra team is too high. If it's a year of extra effort, if you're doing some sort of highly scalable text search database and multiple teams need one of these, does it make sense to pull that out? If it's a year of effort? Yeah, I would say so. You're going to save more than a year from having a team do that for everybody. What about a week? I don't think so. What about a month? Maybe, a quarter? Probably. I don't know where that line is. That's something that I've yet to learn. But I do suggest that you not just automatically look at every duplication as something to pull out into its own team and create a new dependency. And something I want to emphasize here in full ownership, when we're talking about cross-functional vertical integration, we're talking about all the skills needed on the team to work on all the code, and the code base isn't shared across teams. Team owns their code base entirely. Of course, sometimes code base can't be split across teams. So in this situation, I've got a couple of ideas. One is collective ownership. So you've got teams that are each responsible for their own thing, but they collectively own the code base. You can have the boss body style feature teams. Or you can do what Menlo does and have mega team. That is more people than normal on the team. All of these are something to use sparingly. In fact, and before I heard about what Menlo was doing, I would not have said that you could have more than about eight to 10 people on a team if they were pairing. Less than that if they're not pairing. Probably three to five, maybe six. Not people, three to five developers. Three to six developers on a team, plus the other folks on the team that are not developers. What happens when you have a lot of people on the team is that so much work starts happening simultaneously that people can't keep track of it. I asked Ward Cunningham what he thought the largest number of people on a team could be, because he lives in Portland and so we see each other fairly frequently. And he told me that the largest team he had seen that was doing pairing was 30 people, but only 12 of them were actually contributing to the effort. I've personally been on a team that got up to 10 people pairing, 10 engineers pairing, and that was starting to feel uncomfortable. Rich mentioned to me at dinner on Tuesday that the largest, although he has a 70 person team, the most people he has working on a single project has been 30. So that's probably the limit for mega team. And if you're gonna use these ideas, use them sparingly. I think to do it well requires more overhead and less autonomy. Y'all have a very stony face look at you out there. So I'm gonna say it one more time. Mega team. Thank you, I love that. The company I'm working with now every so often, somebody just says mega team and everybody else goes mega team. We don't actually have a mega team. Sometimes you need to have a shared component. And the technique that I'm using for that is facilitated self-service. The key idea here is that if you can't use it right now, it doesn't exist. You treat the other teams as external to the organization. If Microsoft Word doesn't do what you want, what do you do? Either go find something that does.  Similar idea here. If some other team doesn't have it right now, you don't plan on it. You don't look at their roadmap and say it's gonna be ready on this date because you know what, it's not gonna be ready. You know it's not gonna be ready. And that's gonna create delay and air and when it does come out it may still not do what you really want. So if it doesn't exist, you build it yourself or you change your plans. There's various techniques for doing facilitated self-service. You can have an internal platform as a service for DevOps type of stuff. You might have your DevOps team build some sort of infrastructure maybe based on something like Amazon or using your own servers or whatever. If you have, let's talk about that software as a service web app example again. Maybe the team continues to be successful. Awesome. And they grow and they split off an accounts team because the account management is very complex. There's lots of sales and business rules and all these things that have to be managed. And so they provide an API to the signup team and to the do stuff while people are logged in team. But what if that API doesn't do what you need? Well, one thing that the self-service team can do, the accounts team to do, they can provide a lower level sort of raw API that doesn't do anything for you. It just gives you the data. And then it's the responsibility of the team to interpret that data well and they might need to do some caching if it can't be retrieved very often. It's more work but it prevents them from being stopped by a dependency. And then the fourth idea is consulting services. When you can't have a cross-functional team, when you've got stuff like security or user experience where you just don't have enough people in the organization for every team to have one of these folks or when the skills needed just aren't used that often. Like security, maybe you don't need somebody full-time doing security on your team. And because we're talking about full-time team members, what do you do in that case? Well, then you can have consultative teams. You can have a community of practice or a standards body. Sometimes you'll see this for like front-end, the front-end JavaScript folks might have a community of practice that talk about how to do JavaScript well and they may set some standards. Or you might have the backend team or you might have the architecture team producing standards. You can also have rotating embedded experts. The team actually provides experts to join other teams as needed. I like to see, one thing I'd like to see more of is something I call roving bands of feral architects. Architects and organizations tend to be these sort of ivory tower people presenting proclamations down from on high that actually don't work all that well because they're not grounded in experience with the actual problems that you're facing. So an architecture team that's consultative in this model might provide architects to go join teams and actually work with them and help work through those problems and learn from that, bring those ideas back and share them out with the rest of the organization. You can also have on-call consultants. One organization I'm working with does that with their user experience designers. They actually go out and can ask the designers for help. You can have sign off and review. I saw that with a security team that was really good at not being a bottleneck. What they did is they provided standards and then they would do a sign off on teams before they could shift or you could provide documentation and training. Various ways of being useful to other teams without getting in their way without being a bottleneck. There's a fifth idea that's coming from the company I'm working with right now. You all know who you are. Thank you for your help. And this is something that's basically the consultative model taken one step further. I really like these ideas. They want full ownership teams but they've got a big legacy application. And so they decided to create a couple of teams. They're gonna have a legacy extraction team whose sole job is to help other teams pull their piece of the big legacy spaghetti code app out and bring it into their code base so they can be full ownership. And they have another team which is the legacy quality team whose entire job is to deal with the fact that this is joint commit rights, collective ownership. And they'll be focusing on code quality of that system to make it easier to split things up. Also have some teams that do some very difficult technical stuff but to be full ownership there is a small UI piece but it doesn't make sense. The company doesn't have enough UI developers to put one on each of these teams and actually it doesn't make sense to have UI skills full time on these teams. So instead what they're gonna do is establish a UI enablement team to help train up the people on these teams to do their own UI work and possibly also provide some infrastructure, some copies, some examples to copy and so forth. I do have some assumptions here. I'm assuming some basic agile concepts. We're talking about the team as the primary resource. Organizations love to talk about the resources in their company and what they really mean is the people, right? They'll say, I'm gonna assign a resource to this project. I'm gonna assign a resource to that project. They're saying, I'm gonna move Prashant over there and I'm gonna move somebody else over here. The, in this model the team is the primary resource so when you have a product or something that you want done you're gonna say I'm gonna assign this product to that team. And then the people on the team stay on that team full time. They're 100% assigned. The teams are long lived. You don't start a project, put a team on it and then stop it. Instead teams own products, full ownership of their piece of the market. For as long as that product makes money or otherwise produces value. And the team has all the skills and technical resources in terms of computers and cloud systems and so forth needed to do their job. We're talking about a lot of autonomy here. A lot of independence of these teams but there is a need to maintain the overall system. And one of the ways that I've seen this done is through an architecture team. The role of the architecture team is to be out in the world. Those roving bands of feral architects is one technique. Looking for mismatches between teams and responsibilities. Looking for the situation where there's been too much attempt to reuse something and putting that back into the teams or when there's big problems that multiple teams are solving that would make sense to pull out into a new self-service team, facilitated self-service team. And most importantly, they're helping the system continuously adapt and improve. But notice that I didn't say that they are continuously adapting and improving the system. They are a supporting role. They're not dictating. They're not shouting down the architecture laws from on top of the mountain down to the huddled masses. So to summarize, five techniques, full ownership, joint commit rights, facilitated self-service, insulting services and full ownership and enablement. What if we rethought teams and focused on eliminating cross-team dependencies which is one of our primary sources of delay and error. And most of the stuff I see about Large Scale Agile ignores this problem entirely. Probably because we're talking about big changes here. And when I work with companies doing this, we do big changes. We actually look at the entire organization and redesign what the teams are very collaboratively with the rest of the organization and then go out and do it. One technique for, once you've designed the teams, one technique for getting people to go onto those new teams is something called team self-selection. Where actually teams, people choose their own team subject to skill needs. It's a really neat technique, there's a book out on it, a new book that just came out on it. And I don't remember the name of that book. Shane, do you remember the name of the book that I'm talking about? Sandi Mamoli and David Moll, I think the book may be called Creating Great Teams. And team self-selection's been around for a while, but it's really starting to gain currency. I've done it myself just once so far, but it worked extremely well. And I'm gonna do it again very soon. All right, let's talk about idea flow. What if we rethought idea flow? Idea flow is what most people call requirements. But when I'm talking about idea flow, I'm talking about how ideas flow throughout the organization from initial conception, wherever they might be in the organization, through prioritization and winnowing out and rejecting and throwing away all the way down to teams actually making the change and shipping the software. There's several problems that stand out to me about the way idea flow is done at most organizations. At many organizations, there is a value for the illusion of progress. So we wanna see progress being made even if it's not very effective. There's a lot of local optimization. So people are moving resources, by which they mean people, onto whatever the emergency of the moment is. They're surging in response to pet projects. So maybe sales has got a big customer that they want to convert. So they'll say, okay, everybody drop everything and go work on this and they'll move their resources, by which they mean people, onto another team and completely destroy all the consistency and code quality that they were trying to create. There's also a tendency to focus on schedules over value. They say, when's this going to be done? Or more often, this will be done on this date. And tell me what you need in order to get that done. And then they'll move people onto the team for a little while until the next priority comes along and they'll move people back up. That's a great way to destroy team cohesion and quality, by the way. Let me show you something neat. Imagine you've got just a single team. Imagine you've got a single team with three things they could be working on. And each one takes two months. And if you earned an organization that values the illusion of progress, they will work on all three simultaneously. So they can demonstrate that they are making progress on all three goals. So each one takes two months and we'll assume a perfect world where there is no cost of task switching. In which case, it will take six months to do all three. And then at the end of the six months, six months, you'll make some money. By the way, this perfect free task switching, it's a lie. The actual time required for this is more than six months. Task switching is very expensive. But we'll ignore that for this example. Now let's say this organization had an epiphany and they realized that they didn't care about the illusion of progress, but instead they cared about being more effective. If they did, they could try working on one MMF, one thing that can be delivered at a time. In that case, they'd work on the first one and ship it. And while they're working on the second one, the first one would start bringing in money. And while they're working on the third one, the second one would start bringing in money. And by the time they got to the end, the third project would still take six months. But the first one would only take two months and the second one would only take four months. And at the end, they would have gotten four or six months of free money. That's astounding. And this is obviously a made up example, but there are real examples out there of how this can really change the return on investment in your organization. A book that I recommend is called Software by Numbers by Jane Klin-Lan Huang and software by numbers. So one thing I strongly recommend is working on one minimum marketable feature at a time. A minimum marketable feature is the smallest thing that we can ship that brings value, that actually has some sort of concrete tangible result for the organization. It's not always bringing in money, but it's doing something useful. Another thing organizations love to do is move people around. That leads to a need for something called resource shaping. How many of you are familiar with resource shaping? How many of you like resource shaping? One person, two people. Do you sell resource shaping software? Okay, just checking.  Because it's this idea that we are gonna very carefully plan our projects so that the person with this expertise is gonna come up and work on a project and then right when they're getting done and we're ready for the next person, we'll bring the other person up and they'll come onto the project and then we'll bring the next person and the result is this nice smooth flow of steady progress. And that would work perfectly if software was perfectly predictable and nothing ever went wrong. That never happens. So instead what we get is people are delayed, so there's this big trough where nothing's happening and then people will come on all at once and then there's too much going on and then somebody's starved and it's a big mess. So the agile idea is very simple. We have teams as our resource. They work on one thing at a time which means that our resource shaping is very simple. We are either working on your stuff or we are not working on your stuff. We are 100% on the current MMF until it's done and then we are working on something else, some other MMF and 0% on your project. That makes resource shaping extremely simple. It's just what are we working on right now? Now neither of these are large scale issues. The one MMF at a time, the 100% or nothing resource shaping which it can't even be called resource shaping just the way we work is what people can and should do on single team projects as well. In large scale systems we have the problems of surging. We've got the need to respond to enterprise sales needs perhaps or some new idea that the CEO came up with. So one approach that we're looking at is actually I've used both of these before. One approach is to have a sales response team, a team that's dedicated just to serving the needs of people who are trying to make enterprise sales deals and they will build whatever is needed for those teams to close their deals, dedicated team for that. Another thing that I've seen is at one company the CEO was particularly entrepreneurial, had all kinds of new ideas. Actually I've seen this a couple of times. And so they built a new market exploration team. And the entire purpose of that team was to take all the new ideas that the CEO came up with so the rest of the teams could continue working without being interrupted. And so rather than being a team that was working on product X, they were working on whatever the CEO cared about at that moment which changed on a fairly rapid basis. Even with these things you still have a need for rapid responses. Let's say you've got a really big enterprise deal and the enterprise sales team isn't gonna do it. You actually need to demonstrate the ability to do something new in your software. In that case, something I've put into place is a rapid response queue. This is a dedicated work for the important stuff that must be done right away. But in order to prevent this from overwhelming the more strategic ongoing work of the company, we keep it to very limited scope. Each thing must be able to be completed in, oh, let's say less than two weeks. And we have a tight work in progress limit on this queue. Once you've got three things in the queue in progress, that's all you can have. Then everything else has to wait and just go through the normal prioritization mechanism. Now this doesn't address all the problems that I see with idea flow but before we can talk about what's next, let's talk about how we could rethink ownership. By the way, for those of you who are looking at your watches, the schedule says 9.45 is when we're done but we're actually done at 10. I checked so don't worry. I came up to Noresh last night. I said, Noresh, I've got more than 45 minutes of content. What am I gonna do? And he said, don't worry, that's 15 minutes for questions. I said, okay, I'm gonna steal that. And then if you have questions for me, just come talk to me in the hall. Let's rethink ownership. So the idea of the product owner may be the worst idea in the squad. Somebody said, thank you. One person who owns the backlog, as Shane Hastie mentioned in his workshop yesterday, the idea that one person can do this very challenging work is laughable. And also I don't like the idea of one person having the ownership, like making all the decisions about what's going to be done. The people who are in this role are often overworked and frankly underskilled. They usually don't actually have the knowledge or authority, the real authority in the organization, to own the backlog. Instead what they do is they go out and they ask questions of other people and get permission. And because they're overworked and underskilled, they leave out important things that the rest of the team needs to knows needs to be done, but they haven't gotten permission for it. I've actually seen very commonly that one product owner is assigned to multiple seniors and they are just not able to get anything useful done when they're overworked like that. This product owner idea has infected large scale agile. We often, you often see the idea of a master portfolio backlog that decomposes down into program backlogs, that decompose down into team backlogs. This is a very rational thing to do but I don't think it's a good idea. And each of these have an owner. We've got the portfolio owner. We've got the program owner and then we've got the product owner. Somebody who has final say over the work of the team. But the problem with this is that this is sure to leave out important priorities that are too small to make it up to the radar of the portfolio owner. Let's say you've got a self service, so let's say a self service team that is responsible for your database that you do a lot of searching on. This is a hard problem and scalability is always a challenge for growing companies. The team sees this coming. They say we need a minimum marketable feature that is about increasing scalability and the value of this, this isn't a technical MMF, this is a business MMF. The value of this is that our company doesn't go out of business next year when we stop being able to serve customers. They see this coming, but it's not on the radar of the portfolio team and often it's really not on the radar of anybody, it's not scheduled into the team's backlog until things are already falling over but this is a hard problem and it's not solved overnight. Any of you been in this situation? Couple of hands. Most importantly, there's a really foundational principle of Agile which is that the people closest to the work know the most about the work being done. And shouldn't that be true of the market as well? We're talking about full ownership teams. Shouldn't these full ownership teams know the most about their portion of the market? This is a bit of a leap of faith. If you're familiar with the Agile Fluency Model, Diana Larson was here last year and she presented a workshop on it. If you're familiar with the Agile Fluency Model, what we're talking about here is optimized value teams. This is something that is not appropriate for many organizations. It's difficult for many organizations to accomplish because it requires that you actually bring into the team business expertise and that takes an organizational structure shift and that's hard. But we're bucking the status quo. We're saying what if we don't say we're not looking what's acceptable or easy, we're looking at what's effective because that's how Agile started and that's what I wanna do today. So yeah, let's go ahead and say we have three star teams. They may not be fluent but they are working towards proficiency at this level. So we are giving them authority and ownership over their slice of the market. So let's say that you are working towards three star fluency, now what do you do? Well now we don't have to have a master backlog and tell the teams what to do. We don't have to push our MMFs to the teams. Instead we can trust that the teams know their piece of the market better than anybody else and have them generate their own backlogs entirely on their own. So let's bring it all together. There is a need to have strategy. You don't want every team to just go off and do their own thing. You do need strategy that ties the organizational priorities together. So one thing that I've looked at is the idea of a product council that is responsible for the organizational strategy. What are the big ideas that the organization is pursuing? And what they do is they create a list of, at my current client they've decided to have them create a list of press releases. Each press release is something that they want to be able to send out when the work is done to the press. This is what we have done. These are strategic things that are gonna make a splash. And then teams use this list not as here's what we have been told to do but instead as inspiration. As they are defining their own backlog, as they are deciding on their own list of MMFs, they pull from this list of press releases to help them come up with those ideas. But they can choose to do something else. For example, a database team may choose to work on scalability instead of whatever the top most important press release is about. They know their market better than anybody else. Teams work on one MMF at a time using whichever process they want. Remember we are talking full ownership. Teams can decide their own process. Presumably they break the MMFs into stories but honestly I don't know and I don't care. As long as they are working on one MMF at a time and shipping those MMFs from an organizational perspective, that's how we know that they're being successful. And as long as those MMFs are also satisfying their charter which I haven't talked about. But I'm assuming every team has a charter that says what the team's purpose is, what their market is and some measures of success that the team has generated for themselves but have been approved by management. Team uses whatever process they want, full ownership. They ship whenever they want full ownership. They define whatever MMFs and stories they want, full ownership and they do have to justify their decisions back to the product council. They provide demos and they explain why the MMF they're working on is the most important thing they could be working on right now. Some initiatives will require cross-team coordination even though we're talking about full ownership teams.  On the product council are program coordinators whose job is not to manage the program but to help the teams involved coordinate with each other and to help them understand the big picture goals of the product council. There are a limited number of cross-team initiatives in flight at any one point because if you have too many, the system will bind up. You need slack in the system for these things, for everything to work together. So we strictly limit the amount of work and process, cross-team initiatives. Now this is a newer idea in smaller organizations where we've had this product council and the teams working independently. They actually just organically coordinated on their own but with my current client they're quite large and so we're introducing the program coordinator but I do need to tell you I have not tried this idea yet. So I don't know how it will work out but I can guarantee you that if I were to come back next year with the March 2017 edition of Shore Model then it would be different. What if, how it's gonna be different? I don't know. So the program coordinators are going to help coordinate these cross-team initiatives and of course there's always a need to search. Some organizations have it worse than others but there's a need for, when a big project comes along to have more people working on that, that my current client, the VP of product who reports to the chief product officer is particularly concerned about how they're gonna do this because historically they have solved their problems by moving resources, by which they meant people from team to team and we're saying you can't do that anymore. So the product council is going to have a couple of surge engineers. These are people who are really experienced in organization have exposure to a lot of the different code in the organization and the product council can put wherever they want. This is another new idea and honestly I am not sure it's a good idea. It's very in line with this company's culture so we're gonna try it but I'm generally not a fan of moving people around like this, I don't believe, there's the Mythical Man Month, programmers are not interchangeable parts, we'll see how it works. And let's also not forget the rapid response queue. Again, there's gonna be some initiatives that come along from sales or from the CEO that they want to resolve right now so we have the rapid response queue which consists of MMFs of strictly limited size and a strictly limited number and unlike the press releases that the teams pull these are actually pushed to the teams so the product council gets to assign MMFs to teams. This is another new idea, we'll see how it works out. I've done the rapid response queue before but the ability to actually override the teams decisions, I'm not so sure about, got 90 seconds. It's easy to get it caught up in the pretty pictures but remember there's three main ideas here. Talking about rethinking team structure, we want full ownership teams. Talking about rethinking idea flow. Stable teams, one minimum marketable feature at a time and we're talking about rethinking ownership. Teams that are expert in their market, leading to teams that design their own backlogs inspired by strategic ideas but not dictated or controlled by the strategic ideas. Their inspiration, not a straight jacket. And above all, reject the status quo. Steal these ideas, make them your own, let me know what works and project that acceptable mediocrity. Avoid the merely acceptable and seek greatness. Thank you.


Alright, what's up internet? We should be good over the internet. I hope the stream is better this time than... The last time I think I did the stream last Friday tapos parang di siya stream para siyang... para siyang picture book.  Actually, there was no video going on. It's like suddenly a new image at a new image. Like there was no actual stream going on. It wasn't a stream. It was more like a clog.  Okay, just keeping with the analogy. So I'm two wins away from getting ranked for support. So let's do that today. Hopefully we don't get interrupted. I got interrupted also last time kasi. So hopefully that won't happen now. But yeah, just rank up and then see what's going on. Let me just post it to Facebook. Oh, I also need to do another Facebook post. Yeah. Let me just do some housekeeping and then we're good. Okay, wait lang. Yeah, two more wins before I get ranked. Hindi ko naman hinahabul yung ano. Yeah, I'm not like... Okay, that's just... Yeah, all of these miscellaneous streams are kind of just whatever we have time. Although Rafael is out of the country. He's the one who usually handles the game stream. So I'm picking up the slack this month and probably next month as well. Okay, and then since my friends and I have gotten into Overwatch 2. So, you know, there's a game that I'd like to play. Let me just finish up a chat thing. And yeah, how's the stream? I hope it's actually streaming. I don't know what happened the last time. Sobrang olat nung last time. I'm trying to branch out. Yeah, I think that's the plan. I think that's the plan to... At the end of the month, I think, is the plan of the guys to livestream the LOL Tournament. Or is it LOL? Di ba siya? We're actually doing a League of Legends, you know? Oh, mother's crying. We're actually doing a League of Legends LOL. Don't ruin it for me. This is just a survey, so it doesn't matter. But I need help. I thought we were doing a Dota Tournament. Nothing a quick repair won't fix. Alright, thanks for the update, ITX addict. Alright, there we go. Found the game. Two more wins. I thought we were doing a Dota 2 Tournament. I approved a Dota 2 Tournament. So I'm feeling cocky now because I was able to kill somebody with Sojourn in Skirmish. So I'm going to use a hero I don't usually have very little experience in. Although I hear my daughter in the background. Kulang yung players for Dota kaya di change it to LOL nalang. I'll find my own path. Nobody tells me anything anymore. Hey Kiriko, do you do a lot of office work? No, why? Because you always leave a paper trail. Man, Winston, you got to get better lines. What's up? I'm not giving up. Guys, hello. I wish you would. Greetings. Uh oh, we have people actually using the team chat. Don't stay near me. You get my COVID. Don't stay near me. You'll get my COVID. Alright. Thank you for the payload.  Kiriko, can you? I don't think it's a good use of my character, but okay. Oh, we got a Moira. Fracker. Yeah, on top. Alright, I think this is doable, but let's stop fudging around. We'll find the key. No, Ren. This is yung virtual green screeny and media. So it's through the GPU. It's pretty good actually. I mean, where are our guys? Everybody's being cute on top. Okay. Okay, let's be cute.  Lose on the payload. Shit gets done when I'm Moira. I mean, you know. Okay. Ah, tangabogo. Get out there. Oh, thanks. Thanks, Mercy. Same guy. I mean, same, same play. Kind of like, got pushed back. Oh, cut them, thanks. Oh, it's laggy again. You know, what's going on? Hi. Nice one. A jacket. I have no jacket. Okay, I guess I should just stick with Moira. Don't see, I'm good at. I do like monkey around with other heroes, though. And our, um, our Mercy is pretty good. Do we hit this? And I think J Plays League of Legends. Humanity is shackled. I will find the key. You've been distant lately. Lakula? By your design. Pondering anything unusual. Dangerous? Don't not get in my way. Thank you. I find generally Moira's like this initial skirmish kind of thing. Parang, kasi natu really contain.  What am I doing? Trashing Doomfist to my friend. But then, then I keep, then suddenly I keep getting into games where people use Doomfist to, uh, to, uh, not, not significant. I mean, you know, it's a good result. Where'd you go? Where'd you go? That was terrible use of the ball. Off the, uh, on top of the IS. Get out of there. Thank you, Mercy. Ah, Mercy is so good. Dammit. Ay, sangabobo. There seems to be so many squishies. What happened? Well, he had his own. Time again to try again. Dammit. God, dammit.


Hey, I am Chris Caswell. I'm vice president of the board for Off Center for the Dramatic Arts, and we are so excited to have a small black box theater available to the theater community here in Burlington, Vermont again. I have seen so many wonderful shows over the 10 years that Off Center had been active before the pandemic, and I look forward to many, many, many more, not only being in them myself and experimenting, but also just watching people take risks, watching people produce published pieces in a new way, watching anything, just about new stand-up comics, new people experiencing improv or groups that are have been around for a while and want to venue. We're so excited to be a home for theatrical arts here in Vermont. Thanks. Okay, hi, I'm Rick Ames, or G. Richard Ames is my actor name. I'm an Off Center board member, Off Center for the Dramatic Arts. We began in 2010, or that's when we were incorporated as a 501C3 non-profit organization, although it was a concept as a way back as 98 in downtown Burlington, and we are a generator space for new arts, new theater, new performing arts, but also old stuff if you wanna bring in some old Neil Simon show or some even older show, you're welcome to do it if you wanna rent our space. For 10 years, we were in the Old North End in a former bakery building, and now we're in a former UPS store here in the new North End of Burlington in the Ethan Allen Shopping Center, where we hope to be for many years. We went from a 65 seat space over in the Old North End for a year, we were in a 35 seat space, and now we have opportunity to have 100 seats in here with another 20 people in, so 120 capacity, and we're in affordable space to make theater affordable for the people doing it, for the people seeing it, so if you want to rent our space, go to offcentervt.com, and you can find out ways to book it, and you can bring in whatever you want as long as it's safe and sane and hate free, and you can use our projector screen with a rear projector that's new to us, you can close the curtains, you can have as many or as few seats as you want up to 100 seats, and if you hear some excited chatter here, this is our reopening gala, and we're just having friends from the theater community, and people we don't even know yet coming in to see the space. We're super excited about it, we've had a lot of happy tears over this, and we've been in hiatus during COVID, and it's here the night before Easter, and here we have a rebirth of a wonderful spiritual community that we call theater, so some have called me the finder because I was devoted to being the space finder, and we did find the space, but no, that's not for me, I want to say that there would be no need for a finder without the founders, and three of our four founders are here today, Steve Goldberg, Genevra McPhail, raise your hand, and Paul Schnabel, and John Alexander, I know is here with us in spirit as well, as well, I know that the old home wouldn't have been possible without the benefacture of Ben Bergstein saying, hey guys, I have this space, and do you want to use this garage? So thank you, Ben, and April, and we have so many of our previous tenants here who we hope are going to be our future tenants, and we're going to support each other by going to see your shows, I was just saying, I would love to be in this crowd in any event, but it's so wonderful to be here today, and so many happy tears, and here's a moment for those we've lost, and now, without further ado, we'd like all the people who are part of the fit up to come up, it's a BYOS event, bring your own scissors, and we're going to have these now, you can pull it nice and tight, right? Tight, tight, okay, okay, I'm sorry, I don't mean to be the taught police, but very Orwellian, right? Oh, I had some other jokes I was going to make too, but I made the founders founders joke, oh, okay, one more thing, I am your emcee of sorts, this is the first slide of my show, please come see it in a couple of weeks, and it's to show you how well it can work. Anyway, well, it does work, I did it the other day. Just one more thing, a couple last summer, I started, I was doing a show in Adamant, and for some reason, I wrote down Offcenter for the dramatic arts, and I wanted to anagram those letters, and I'm an anagrammer, and I'm not a grammar, because I never had kids or grandkids, and I'm not a lady, so, but I'm an anagrammer, and the only one I could come up with that uses all the letters, and if somebody else can come up with something, let me know. Comedic stoner father, fart, fart, so, and you know, and some of the material that's been presented at the Offcenter is kind of equivalent to that phrase. So, and basically, if you can pay for the space, you can do what you want in here, as long as it's safe and hate free. Yes, and legal, and legal. So, everybody come on up now. We're gonna have two more people speak real quick before we cut the things. Paul, I'm gonna invite you up to speak first, and then Chris will come over. Holy moly, this is just pretty darn incredible, right? I was just thinking this morning about the Offcenter and how, like, 13 years ago, we started this thing, and then I was like, wow, 13 years, and now we're in this new space, and I was just trying to imagine if it could last another 10 years. That would be 2033, and you know, like there's so much stuff that goes on in the world, there's so many problems, and who knows what is gonna be in 2033, but the Offcenter is the antidote. Places like this, open, it's free for everybody to express what they wanna express. It's available, and it's pretty great. So, congratulations to everyone. This is a monumental effort to get to here, so thank you guys. Thank you, Caitlin, for organizing this event. And Marty Gill, thank you Marty. I would like to thank everybody who worked so hard to open the space. People who donated money, I think most of the people in the space donated money and or donated their time and or donated equipment and or donated, well, and or donated all of those things. Just so that, I can't do this. Paul, thank you so much. Steve, Genevra, thank you so much for giving this community this space. I just, I think it's needed. We know that it's needed, right? And I can't believe that we're back. Um, yeah, thank you, everybody. Thank you, thank you, thank you, everybody. That's it, that's all I can do. All right, now we can invite everyone who's on the board to come up, please. And yep, give them back. Choose your scissors, we do have, and then we also have scissors for the founders. Yes. Please. So, does the tallest founder get the tallest scissor? So come on up, Paul, and all of you. Paul, I brought this especially for you. You seem to hurt himself, so I got you. It'll work, right? So is it one, two, three, cut? Or is it one, two, and cut on three? One, two, three, cut. Yeah, yeah, there we go. There's the next biggest ones for you. I tested these all out, they do cut. I got one. Other people? Is that what you're doing?  Come on down here, you guys. Cut on the end here, I'll get them. All right, founders right in the middle, and then everybody else fill in the sides. You're filling the sides. All right, I feel like, you know, I like audience participation, so how about we have the audience give us one, two, three. Hold on. Hold on. Hold on. Hold on. There's people to get in. Photo, photo, photo. Yeah, yeah, let's do it. This is your chance for the photo, thank you. Oh, they're counting on us. Are we ready? Yeah. My name is Caitlin Durkin, and I am one of the board members of the Off Center for the Dramatic Arts, and we're here at our grand opening today, and we're really excited to be here and welcome the community into our space. Our goal and our mission is to provide affordable and accessible theater to the Burlington community, and provide a space that can allow for innovative and exciting new theater to happen here. Hello, this is my opportunity to say a few words about the Off Center and what the Off Center coming back to life means to me. If you can get a sense of the convivality, the energy that is manifesting in this room right now, you'll be aware of what is drawing me to speak to you now about the Off Center. This is a place that excites your imagination, that brings to life your dreams, so I would just suggest take an opportunity, come here, experience the space. Experience the company of people who have that spirit of adventure and exploration and a lot of life in here, so that's all of God.


The first matchup on Saturday as the Indianapolis Colts visit the Kansas City chiefs Casey is favored by five Gabe. What do you think about this? What I think is I'm very excited about this football game Maria and I'm excited about all four contests this week from a fan perspective from a DFS and a fantasy perspective and of course From a betting Perspective as well quick history lesson here guys last five years the one seed has won the Super Bowl All right home field has mattered and the seeding has mattered as well another interesting tidbit going back to 1975 16 one seeds from the NFC have won a Super Bowl only nine one seeds from the AFC Which leads me into this a football game and the theme of the week this week I like the dogs in the AFC and I like the favorites in the NFC now the last time the Kansas City Chiefs won a home playoff game Joe Montana was their quarterback They're oh and eight against the spread in their last eight home playoff games, and I'm getting Frank Reich I'm getting Andrew Luck. Once again Maria. I'm feeling lucky. Give me the five points with the Indianapolis Colts I also like them on the money line as well But it wouldn't shock me if the Kansas City Chiefs won this football game by three points Now last week there was a lot of talk about rookie quarterbacks into playoffs And we talked about this and we told you the last seven rookie quarterbacks start a playoff game lost all seven of them We like to charge us last week against the Ravens, and that was one of the reasons Lamar Jackson will chalk it up to oh and eight Right now now my homes not a rookie second year But nevertheless first playoff start what we see last week with guys making their first playoff start to Sean Watson It's not a rookie man's players play our first playoff start lost Mitsubishi lost we can go on and on okay, and there's only so many numbers We can tell you that align with the Indianapolis Colts in this football game, but I'll tell you what The last 15 times that a quarterback is started his first playoff game against the quarterback That's been in the playoffs before their record three and twelve a lot of pressure on my homes This is gonna be you know the fact that a matter is I think the Colts are just a deeper football team Right now the only team left in a playoffs that are ranked in the top ten in offense and defense The Colts gave me the Colts plus the points gave me the Colts on the money line I like the over as well, but it's extremely high a couple of turnovers or if the weather gets crazy in game It might slow down the toll a little bit, but it should be a track meet I like the five points and I'm gonna sprinkle on the money line So interesting we think of the Chiefs as one of the most potent teams for sure Offensively all year long with the Colts They've just been hot and as you said Gabe Andrew Lux been there before big test for my homes And how about this murder you mentioned that the Chiefs and their explosive offense This is courtesy of my good friend Mark Lawrence over at playbook.com Nine nine teams in the history of the national football league have scored 540 points or more None of them have won the Super Bowl before Just saying I love when you throw these tidbits at me Yeah, as we know you get into the playoffs and defense matters a whole lot more


One should not pass up an opportunity to help somebody to help a good cause. You know, that's just a pretty good goal in life. All veterans, in general, have the feeling that they were never properly thanked when they came back from the war. One of the things that I remember, just like it was yesterday, was in 2008, getting involved with Stan Cass and Lee Seward to start the Honor Flight of Northern Colorado organization. And they had an idea of flying World War II veterans to Washington, D.C. to see their memorials. I was so fortunate to be along with my husband on that very first Honor Flight and to have three World War II veterans that I was the guardian for, seeing the gratitude and the love and the appreciation from being up at Cheyenne and seeing everybody clap as the veterans came through all the way onto the plane, then being at Baltimore as they got off the plane and having an announcement on the loudspeaker. Attention everyone, we have honored veterans, heroes in our airport today. Please give them your appreciation and watch these gentlemen and a few women walk through throngs of people clapping and cheering as they did it. I've never seen men so proud, women so proud.  I got out of the Navy in 1972 and hid that until May of 2011, when I was in a meeting with Ted Posiwak, who was the Fire Chief of Frederick Firestone Fire Protection District, and he asked me if we were coming to the Honor Flight Sunday morning. I had no idea what he was talking about. So Barb and I gathered up some flags and went out there Sunday morning.  And when they went by, I just sat down and cried. I had no idea that I had so much stuff built up inside of me and that was the launch of me getting back into the community of veterans. So we both have been very involved in the community and love doing it and when the Honor Flight came up Stan got in touch with the gentleman who started it and we've been going willy-nilly ever since. What Stan Cass and Cicely, what their vision was for this has had a tremendous impact on this community for the veterans and the families of veterans, the active military and their families and the young people of this area. So the Centennial Society was created to recognize folks that would like to support the community foundation and their charitable interests after their lifetime. So if they leave a request to the community foundation in their will or make a plan gift with a life insurance policy we invite them to the Centennial Society. We have an annual event where we recognize those donors and we also recognize them in other publications. The community foundation makes it so easy to be able to set up a fund and to get started with this and as we're looking back in our lives now and coming to the end part of the lifestyle it's nice to be able to sit back and know that what you did will continue to work for you.


Today we are taking a look at Frankie's free-range meat versus butcher box and honestly I'm a little bit nervous because what I did was have my friend order butcher box and then Ordered the exact same stuff from Frankie's free-range meat So I haven't had a look in either of these boxes now this arrived today This is what was packed up today at Frankie's free-range meat as well. So This is anticipating what you would receive at your doorstep and I believe butcher box did send a free turkey So we can definitely take a look at that and talk about The difference between that and heritage breed stuff You know off the bat they do have branding on their box But you know have a feeling if we put branding on our box on Frankie's free-range meat They would actually intentionally destroy our packages. So We don't have the luxury of that Now this is how butcher box puts the dry ice we usually we just put the dry ice in a bag like this Oh, they also do a bag So they have some dry ice in here and they have more dry ice down there. This is the free turkey This is a little thought out over here. It's it's marked for butcher box All natural all vegetable diet no preservatives razor without antibiotics complete traceability problem This is basically your conventional your conventional turkey your bird I will throw this out and take a look at the meat when it's thought out. This is some type of packaging material So the meat and the meat's frozen, but it's a little soft so You know, it's mostly frozen, but it's definitely thought out a little bit They could have put some more dry ice in here So here they have a whole chicken. They have some ground beef Okay, so this actually this actually doesn't look that good the the seal on the ground beef is broken It's it's soft. It's a little thought out. It looks like this is oxidized a little bit This one looks a little better, but you know From a ground beef perspective, it doesn't look that good. It's kind of light in color that indicates oxidation This is top sirloin cap Which is supposed to be pecania. It's pretty lean. It looks oxidized You know, we'll take a closer look at this, but it's oxidized already. That's not good Two ribeye steaks seals broken on this one Seals not broken on this one so far we have you know out of the You know four things we looked at half the seals are broken This is a pork tenderloin seal looks intact, but this is obviously, you know regular pink conventional pork despite the misleading marketing And we got some strip steaks Seals broken again, you know, we're assuming they didn't package meat that had a broken seal We're assuming the seal broke throughout the shipping process You know what they can do is they can put more packing material more empty material in here to To prevent it from knocking around envelope that is completely soaked Recipes and how to defrost the meat and cook from frozen. So just some cooking instructions here overall Could be better could be worse now Frankie's here aged meat. I Don't think they put ice in this because you know, I literally just want to pick it up today, but Maybe he had some ice to put in here Now this is probably why butcher box thought out because I Don't know what type of insulated lining this is but this is this is crap for oh, that's probably breathing in some crap To but this is not going to keep the cool in that well It's not it's not insulated on top. I don't know how the hell they It's not really insulated that well. It has gaps On Frankie's here aged meat we ship in the Styrofoam you get a little bit of a you know Thank you for purchasing if your meat arrives like this. This is how to store it Okay, so he did put some ice in here. So This is how the dry ice comes depending on What your order size is there will be more there will be less and All of the meat we wrap it in paper just to To try to prevent it in case, you know, it gets knocked around the seal doesn't break It's packing material as well as if the seal does break it does leak It it doesn't leak that badly because it's wrapped in paper so he put in a whole pecania whereas so this is This is the sirloin cap from Grass-fed top sirloin cap grass-fed top sirloin cap. Obviously. This is much bigger. Let me see if you put something else in here That's closer to that So here we have Rib eye steak That looks really good actually especially compared to that. Oh, but let's put all this stuff on the counter And then we'll compare it side-by-side This is our chicken And I'm already noticing, you know when comparing the packaging side-by-side, you know These are already sealed. It's a lot tighter Another rib eye steak This is our pork tenderloin. Obviously huge color difference already This is a strip steak Okay, this is our sirloin cap, so You did he did put a smaller one in here, here's another strip steak This is our 8515 ground beef and This is another one of our ground beef Yeah, if I'm trying to be objective from the consumer perspective of the packaging material and the experience opening the box To me, it doesn't make any difference as long as there's enough ice in there and everything is wrapped neatly So to me both of these were okay, although again, you know butcher box could have put a bit more dry ice in their package you know it's completely melted and You know if this box was delayed one day Then they would have had a major issue all the meat would have been completely thought out both of these orders cost Approximately the same amount of money but your box was 149 Frankie's syringe meat is a hundred fifty six on butcher box You get a free turkey on Frankie syringe meat. You get steaks that are almost double the size So, you know butcher box sent us 10 ounce strip and ribeye on Frankie syringe meat ours are over one pound You know 16 17 ounces and in addition we usually offer something free with your order every week this week It was lamb brains, which are $15 value. Sometimes we offer ground beef So there is a promotion here that does make up for the turkey and you get more bang for your buck You know you're paying less per pound of meat from Frankie syringe meat and it's legitimately high quality But I don't need to say that let's let the meat speak for itself the main focus in our video last week was talking about the quality of the pork and the chicken on butcher box and You know if we look here The pasture raised chicken from Frankie syringe meat, you know, it's a tiny bit smaller It indicates it's an heirloom quality You could tell you know the coloring is slightly darker and this is obviously much much Lighter coloring, you know, you don't have the yellow carotenoids from the natural pasture raised diet And we could let this stuff throw out too and then we'll open it up later and take a better look at it The ground beef You know the butcher box is a bit lighter in color a bit more red and again, you know This one's open. This one's kind of oxidized. You know if you look at the ground beef from Frankie syringe meat It's darker Indicates a higher mineral content in the beef and it just packaged a little nicer too. It's it's it's a tighter package For the sirloin cap. There's a significant difference here.  This is you know This looks like a almost conventional grain fed sirloin cap and the seals broken and there's not much marbling And there's not that great of a fat cap, you know, even on Frankie syringe meat when the meat isn't that marbled The pecanio always has a fat cap on it I think the most drastic thing we might see today is the difference in Iberico pork versus conventional pork, you know, our pork is Deep red. It's like as dark as beef and their pork is you know Pink very light in color, you know, they're claiming. Oh, you know, it's an all-vegetarian feed No antibiotics dot-dot-dot This is 100% pasture raised pork Iberico This is what your pork should look like if it's high quality just like that's what your chicken should look like if it's high Quality you could tell people all you want that you're selling high quality meat But when you compare it to actual high quality meat, it's not you know, look at this Look at this strip loin. Look at these strip lines compared to theirs. The meat's much darker in color The fat is yellow beige. Yeah, I didn't talk about butcher boxes beef last week But I'm comfortable saying that I've never seen grass-fed beef that looks like this, you know The flesh is is light in color. You know, the fat. It's it's kind of white I don't know what's going on here. I'm not saying anything for certain what I know is This is the grass-fed beef we sell on Frankie's Surrange meat and that's the grass-fed beef butcher box sells They're both grass-fed. Which one do you want?  This is lighter in color. It's not cut that nice So let's Thought everything out. Let's let it sit. We'll cut everything open and take a look at it outside of the packaging Now that everything is thought out I noticed something more substantial than a color difference and that is the smell of the meat some of these butcher box steaks Have a very Minerally gamey smell now some of their steaks don't but for some reason most of the butcher box meat It has this mineral gaminess that happens when the animal isn't getting enough nutrition in the grass, you know when I smell Yeah, it's consistent across their meat and I'll tell you right now These steaks are gonna be no good the Frankie's Surrange meat Yeah, it doesn't have that mineraly smell It actually doesn't have much of a smell at all. It's also means the meat is much fresher. It's not aged as much Let's see if the ground beef has that difference, too Yeah, I smelled a little bit on their ground beef, too Not on our ground beef. That's weird. I didn't really expect that I guess I could smell the difference between the chicken as well You know, of course we could cook this up and taste this but usually smell is a good indicator of quality as well Yeah, our chickens a bit fresher So, you know, their chicken smells like a regular chicken does and our chicken doesn't actually have a smell to it So so one thing people might not know is when meat is really really fresh like slaughtered recently It doesn't really start developing its smell its flavor until two or three weeks after that's why most meat is aged You know three four weeks before it hits supermarket shelves So when the chickens thought out, you know, there's a substantial substantial difference You could see the darker color of the meat. You could see the caranoids and the fat and skin I mean the sheer size of the conventional bird, which is what butcher box is probably selling versus what we have it is a big big big difference and We hope to sell even higher quality chicken on Frankie's here range meat in the future And despite being only in business for a year and a half We're already knocking butcher box out of the water on the quality front You know, what has me really excited is that future of even higher quality meats And it is a bit disappointing when you have a company where you know, several hundred million We could kind of cut the meat open and just take a quick look See if there's a big difference in the color of the breast.  It's kind of hard to see on camera, but it's definitely darker the conventional meat has a bit of a pink hue to it and the outside of it is is a much lighter and Our bird has just darker flesh all around That's the main indicator and then you can also look at the size and say alright This is clearly, you know more heritage breed bird that is a naturally attainable size So now the ground beef is thought out There's less of a discrepancy, but ours is still slightly darker What's really going to tell is is the inside, you know, butcher box on the left versus us on the right You know our ground beef is slightly darker I'm not going to nitpick and say there's an incredible difference here I you know, we definitely have some ground beef like the local ground beef and the wagyu on Frankie's T-Range meat That might have been more of a stark contrast Yeah, all I really have to say about the ground beef for them is is theirs has that slightly Minerally gamey smell and this is a bit fresher as well.   This is a Substantial difference in quality and what you're getting so the pork, you know, we showed earlier There's a substantial color difference in you know, conventional pork versus actually pasture-raised pork And although pork isn't as bright as chicken, you know, it's supposed to be really really deep red that has like a Not much of a smell to it at all This smells like acorns. This smells like the forest This smells really really delicious that I want to take a bite out of it. Actually, I Think if you bought this butcher box pork and then you know bought the Ibarico pork from Frankie's T-Range meat or any Actually pasture-raised pork. Oh my god world of a difference This is probably the most substantial taste difference you will see in a product ever. So the strip steak That really off-minerally smell again. That's throwing me off of it From a comparison perspective of something more reasonable actually, you know, the meat is fairly similar in color The outside on both is a little bit lighter on ours you could tell the fat is Softer more beige yellow tint to it grass-fed Yeah, these smell pretty similar, you know, I would say if you cook these steaks side by side You might enjoy this one a little bit more, but overall on butcher boxes end This is not the worst piece of meat in their box by any means Can't say the same about the other stuff so for the ribeye We have the same Disgusting minerally smell. I am not I'm gonna have Adam eat this beef I'll let you guys know how it was because I'm not a I'm not a fan probably have to marinate it But but the other ribeye that they sent This one doesn't have that minerally smell. You could tell it's a little bit more marbled and that the animal was getting some feed by Let's not compare these steaks.   The meat is darker. There's more marbling. It's cut nicer You know, which one do you want? You're paying the same amount of money for both of these steaks It's it's absolutely crazy and this is probably the reason that we're not making half as much money as butcher box Because butcher box is selling you this low quality meat At the same price. We're selling you this meat overall. I'm a little bit disappointed But I kind of expected this because I have ordered from butcher box in the past and not once Have I ever gotten a package that hasn't had a seal broken Same thing with the quality of the meat.  You know, as I said in my video last week I mostly focused on the low quality chicken and the low quality pork because you know from a marketing perspective If butcher box says they sell grass-fed beef and I say I sell grass-fed beef I just have to let the product speak for itself and put that in front of you and say, hey, you know Butcher box is selling this we're selling this it's the same price Which do you think was from a more properly raised animal? Which cut of meat do you think is going to taste better? What really threw me for a loop and what I didn't expect was the meat to have that Really off Minerally gamey smell half of this beef wouldn't get past the quality control on frankie's your range meat You know if we were cutting something up and it smelled like that, you know, we wouldn't send it to a customer and we do occasionally get meat that smells like that from Animals, but again, you know, we don't sell it to our customers And we certainly don't send a box full of half of it to our customers You know butcher box could sell higher quality meat, but we know that's never going to happen and with their corporate structure They would certainly have to raise their prices I'm pretty comfortable saying this is probably The competitors playing field and that, you know, frankie's your range meat really is above what everyone else is doing At least in you know, the online butcher shop space And again as we expand as we grow as we control more of the operation ourselves The quality is only going to improve, you know, so we're already beating out the big guys You know in another year or so it's going to be night and day comparison You won't ever want to order from anywhere else. So thank you guys for joining me today As I've illustrated several times in this video I'm really excited and looking forward to the future of frankie's your range meat Considering how far we've come in just a year and a half If you guys have been ordering from butcher box And you want to order from frankie's your range meat Just you know, send me an email that you placed in order and I'll give you an extra like few percent discount Maybe I'll even do five percent On some of your orders if you guys want to switch over if you guys want to learn more about our products Definitely check out frankie's free range meat calm Thanks for joining me you guys and I'll see you for tomorrow's video