In this presentation, we will enter data for the earnings records for August. Now in the last presentation, we did the payroll register, which gives us the information by employee per pay period. But we also need to track this information to sum up how much someone has earned during their time here. In other words, this will give us the information by employee on the payroll register for a particular pay period, which we need on the pay stub when we give someone a paycheck. We need to tell them, hey, this is how much you earned. This is how much we took out of it. There's your net pay. But we also need to know the year to date totals, which of course will be the same after the first pay period, but we'll differ later. In order to do that, we can't get that information from the payroll register. We have to use an earnings report. Basically the same information is just going to be formatted a bit differently. We put that over here. We scroll into the right. So this is going to be the earnings records. Now the earnings records oftentimes will have the data and the social security number and the name, the allowances on it. We're going to make everything as simplified as possible just to line up to the earnings record to the payroll register so we can see this information in our main goal is really to see it so that we can see what would be needed in order to fill out the pay stub as we enter this data and pay the pay periods out. So what we're going to do is just pull the same information into each employee. It's a similar worksheet. You can see the subtitles are going to be much the same so that we can pull this over as easily as possible. We'll use formulas to do so. And what we're going to do now is not break it out by pay period. It's by the employee. So here's the employee. Here's the pay periods August, September, October, November, December. All we have is August so far. Here's the next employee, Cindy. Here's the pay periods. Here's the next employee. Here's the pay periods. So we're just going to fill up August for each employee. So if we scroll back up, we're just going to basically pull this information over. So the filing status for Anthony, if I scroll back over, I'm just going to pick up that same married filing status, same number of allowances. So all these are going to be in essence the same. So if I go back over here, I'm going to do this with a formula. I'm in AB4. We're just going to say that this equals, scroll all the way over, and pick up that M for married in B5 and tab. So in essence, it's a formula going to B5, B5. Now what we're going to do is we're going to pick up all the information for this month, for this month for Anthony. Now if I scroll back over, it's all in the same format. So we've got the allowances, the regular hours, the regular pay. So we could highlight this whole thing and just copy it over. I'm going to do it with a formula. So we've got the formula picking up this cell. If we copy it to the right, it should just pick up the cell to the right of it. And we should just be able to pick up each cell. So let's see if we can do that. I'm going to scroll back over and we're going to put our cursor on this cell. I'm going to right click on it and copy, right click and copy. Now I'm not going to auto fill it across because I don't want it to change the formatting of the cells. I just want to copy the formulas over. So it picks up the formula but doesn't change the formatting. So then we're going to select from cell C4 or AC4 all the way over. Every cell after that, go into net pay, let go. So here's our selected area. We're going to left click or right click on the selected area. And then we're going to paste it, not normal because that'll paste both the formatting and the formulas, not one, two, three, because that'll give us the values. If we use just the format, then just the formulas, it should pull over the formulas and keep the format of the cells. So we want to paste the formulas. And so you can see what it did here. We still have the regular hours now, not having a dollar sign, having the dollar sign here and having the cell centered. So that's what will, the way we will do this. So it gives us the same information. We just pulled it over. We don't get to see the formulas over here this way, but the formulas are already calculated in the register and we can just pull this information over. Now the benefit here, of course, is that on our earnings records, we can give them the earnings for the time period and we can give them earnings year to date, which is the same right now. It will differ later. Okay. So then we're going to do the same thing. We did that for Anthony. We're going to do the same thing for Cindy. So Cindy in August. So the first pay period for Cindy AB 11, we're just going to say equals. I'm going to scroll to the left and find her filing status, which is in B6. So B6 enter. So all we did is go to Cindy and pick up cell B6 equals B6 and then we're just going to copy and paste. I'm going to right click and copy right click and copy and then select everything after that from CAC 11 all the way over to the net pay right click and paste it with the formulas, just the formulas. And then we have that information. So we'll do the same thing. Note the totals will be down here for Jill. Same information will be an AB 18 equals going to scroll to the left, going to scroll back up. We're going to pick up the S single for Jill. And then we're going to say, if we double click on that, we picked up equals B7. That's the cell going to right click on it, copy it. And then we're going to put an AC 18 all the way over to AT 18 right click and paste just the formulas. Then we'll do the same thing for Judy. Last one. We're an AB 25 August for Judy Jones equals, I'm going to scroll all the way to the to the left all the way up, pick up the married status related to Judy on the payroll register and enter. And then I'm going to copy and paste that all the way across. We're going to put a cursor on AB 25 right click and copy, but our cursor on AC 25 all the way to the end, right click. And we're going to go to paste 123 or I'm sorry, paste formulas only, paste formulas only. And there we have that. So if we were to sum this up, we could get a check figure then if we were to add all this up. So if we go down to our totals down here, I'm just going to sum up for all of our employees and see if that kind of matches what is over here. I'm going to scroll to the left, scroll to the right. So we have our totals down here. We could match that out right now. And that could give us kind of a check that this is in there correctly. So if we scroll back down, for example, if we go to the third quarter totals, I'm just going to go totals for the year, which is going to equal when I scroll up everything that we have so far for Anthony, plus everything we have for Cindy, plus everything we have for Jill, plus everything we have for Judy Jones. So there we have it. The formula is AF9 plus AF16 plus AF23 plus AF30. Comes out to 487.19. If we scroll back over up here, we get 487.19 for regular pay. So let's do that all the way across and we can kind of double check some of our numbers. I'm going to scroll back down. Now the formula is going to be relative the same if we copy it, if we copy and paste it. So if I copy this formula here, it'll pick up the same cells relative, meaning it'll pick up this cell, this cell, and so on. So what we'll do is I'll right click here, copy, and then I'm going to put the same calculation all the way across down here, from here all the way over. I go, we're going to right click and paste, and we could just paste the formulas again. It shouldn't really matter. They're all dollar amounts this time, but we'll paste the formulas. I'm going to make these cells a little bit larger. And then we'll double check the main, here's the 488.90 for the total earnings and notice Suta earnings are the same, but the Futa is less. So Futa earnings are 20,896. So if we scroll back over, double check that here, total earnings 48,896 and the Futa 20,896. So that looks pretty good. If we look, if we look at our net check for everything, kind of like the bottom line number, 28266.11 over here on the register. And if we scroll back over here on the earnings record for everyone, 28266. So that can give us a little bit of a check and note, we have to do this of course once again so that this information for the totals each employee can be summed up and be on the payroll, pay stubs and reported, whereas if we look at the register, we have only one pay period of information per employee per pay period. So we have to sum that up just a little bit opposite here. We got the pay periods and then the employees and the payroll register over here. We have the employees and then the pay periods, which is kind of reversing that ordering to get the summary data, the end.


I'm the chief methodologist for IT at IBM Rational and what I'd like to talk about right now is some work that I've been doing over the last few years called the Agile Scaling Model and the goal is to describe a framework around which people can understand what Agile, how they're applying Agile, the context in which they find themselves in. It's interesting, the previous speaker was joking that everybody jokes about this, that the consultant answer is, it depends. Well, I would really like if people were to follow up on that and say, well, on what? Because that's an interesting question. And this is the answer to, well, on what? At least some of it will be at least. So keep that in mind. So, that's not working. So, I want to talk about three basic things. I'm going to start out, first of all, by talking about what the Agile Scaling Model is. Because it's a fairly light thing, which I hope hopefully we'll be able to convince you of it's fairly light and fairly straightforward.  You know, how is this scaling model, how would it affect the common practices that you're probably used to and we'll look at daily standups and stuff like that and we'll see how you would scale them. And you've probably heard some of this already from other speakers. As well as what are some of the other practices that you might want to adopt?  This would be a several-day talk if that was the case. And I'm certainly not going to go through every Agile practice and show you how to scale them all because that would also be several days because there's 80 or 90 common Agile practices. And even if it takes me a couple minutes to walk through each one, which would be very short, that's still half a day of material. And I've got 60 minutes. And then finally, I'm going to talk a little bit about organizing large teams. Now, part of my message here today is that there's far more to scaling than worrying about large teams and actually large teams is a relatively trivial thing. But I just want to talk a little bit about large teams to give some advice around that and then get you thinking a bit outside the box. And I almost wish I'd given this presentation earlier today because some of the questions that I was hearing in other people's presentations, I think they could have benefited from a couple of diagrams I'm going to show here about how large teams are actually implemented in Agile. So what's the Agile scaling model all about? It's a three-level or three-category model. At the first level, the first category is Agile development in general. And this is typified by Scrum, by Extreme Programming. The focus is almost always on construction. We see this a lot. That's a great place to start. The goal of Agile development is generally to develop high-quality software, build it in an evolutionary, inter incremental manner, be very collaborative, be self-organizing. This is something that hopefully you've been hearing about over the last three days. So this isn't new. It has a value-driven lifecycle. So in Scrum, the rhetoric is we produce potentially shipable software, every sprinter, every iteration, depending on your terminology. So we're producing visible value at all points in time. That's a good idea. I'm without a doubt, and Agile Manifesto talks about how the only way to measure progress on development projects is the delivery of working software. So it's all good stuff. And for the most part, a lot of the advice is around small and reasonably co-located teams doing fairly straightforward stuff. And without a doubt, it's actually the majority of teams. So near-located, at least, not co-located. But the majority of software development teams are 10 people or less. They are roughly near-located. So we're sort of in the same building or same campus. And for the most part, most people are developing reasonably straightforward things. There's really only a few teams out there in the world that are developing air traffic control systems, or heart monitoring systems, or the Watson system to play video games, and stuff like that. So the vast majority of projects are reasonably straightforward. So that's OK. So this is a decent niche for Agile to focus on, the majority of teams. But there's more to it than that. This is the problem. Some of the questions I've been hearing in other people's talks over the last couple of days were around these issues that aren't being described all that well. So it's not about construction, just about construction. It's about delivery. So I've got to be able to say, how do I initiate a project effectively? How do I do the construction stuff effectively? How do I release the production effectively? If you've got a DevOps type of an attitude, and there's a DevOps track here, it's the next question, how do I operate and support the solution effectively? How do I do portfolio management effectively? How do I do enterprise architecture effectively? Look at the bigger picture type stuff. So there's a bunch of questions that's not being well-addressed by just this construction focus that we like to talk about in the Agile community. Value-driven life cycles are nice, and they're definitely a good idea, and they definitely pay down some risks. But delivering working software on a regular basis does not pay down all risks. So we know at the beginning of a project, it'd be really nice if we'd have some sort of agreement around what we're supposed to be doing. It'd be really nice if we had a clue what the architecture was. So we could go in a reasonable good direction to begin with. We should be worrying about these basic fundamental risks, and we should try to address them very early in the life cycle if we possibly can. So this is about governance, this is about portfolio management. Whatever you want to call that, we need to work a little bit smarter. So it's not just about showing working software on a regular basis. It was interesting, the gentleman that we were talking about regulatory compliance a while ago, they used slightly different terminology, but they both showed life cycles that had an explicit project initiator. Actually, one gentleman was talking using the term inception, the other one I can't remember what he was talking about, but he's basically showing you do a little bit of upfront work, then you do a bunch of construction, then you do a bunch of release work. And they both had this very clear cadence in their life cycles. You use slightly different terminology, but that's basically what they're talking about. This is having a full delivery life cycle. Self-organization is nice, and it's actually quite effective, but you need some adult supervision.  And all teams, by the way, are being... I realize governance is a swear word, and I apologize for using that swear word, but like it or not, all agile teams are governed in some way, like it or not. Okay, this is the real world now, not the Scrum Fantasy certification stuff.  So somebody at least is keeping an eye on you and how the money is being spent. That's governance, that's financial governance. And if you're really smart and you want to be really effective, you'll also know that you need technical governance. You should be working to common coding conventions. This is actually built into XP, by the way. You should be working to a common infrastructure. You should be reusing as much as you can. If you aren't a regulatory compliant situation, you should be following the regulations. So there's some basic fundamental governance things that you better be doing. Otherwise, you're going to get a spanking at some point from senior management for not doing your jobs properly. So yeah, you need this adult supervision, one of my colleagues likes to say. And this is still geared for reasonably small teams developing fairly straightforward stuff with the exception of that one word solution, not just software. And I was ranting about this this morning. This focus on software is not helping us in this community. It makes us sound like idiots, actually. It's very clear all these people are running a working software, working software, working software. You've just labeled yourself a junior employee, by the way, when you start talking like this. Because it's not just software that we're producing. We also deliver supporting documentation. And documentation is, in fact, part of Agilay. I would invite you to Google the term Agiladocumentation and see what comes up. And because there's deliverable documentation, there's going to be some operations documentation you're going to need. There's probably going to be some user guides, some training manuals that you need. There might be some system overview documentation that you leave behind for maybe yourself or for somebody else to overview the system. So that way you can maintain support over time. Let alone if you're in a regulatory environment and you want to avoid a few fines by producing some of the extra documents that the regulations ask for. So we need to worry about that sort of stuff. The software runs on hardware, and almost always in any system I've ever produced, there's been hardware upgrades. You do a major release, and you're probably going to throw a little more hardware in a production or somebody else will. Maybe the operations people will. If you're running in a cloud, then somebody's slapping some boards in there at some point to keep things running. But something's happening and the network's changing. All good stuff. The business process is changing. You might even be changing the organizational structure on the usage of your system. So you've really got to be looking at the solution, not just the software. The software's part of the solution, but it's only part. So we really got to be looking at the full picture. In many ways we've lost this in the Agile community from all the rhetoric and all the questionable training that we get sometimes. We've really lost this. And before Agile, we had sort of matured to the point that we recognized that there was more to it than just software. And then we sort of backtracked a bit with the... But anyways, so let's up our game and look at the big picture. And it's not just potentially shippable software. It's really consumable software. It's nice that the software runs, but it'd be even nicer if the end-users actually wanted to use it. That would be really nice. Because I'm sure many of you have seen systems that were wonderful. They were great systems. They met their requirements. People signed off on it. And then you ship it into production. You ship it in the marketplace. Nobody wants to use it. Nobody buys it. That might not have been all that successful. I will contend. So then the third level, Agility at Scale, is what happens when the situation is not so simple. And I'll walk you through this in a few minutes. So what happens when there's one or more scaling factors and you're not in this simple situation anymore? And so how do you tailor your process and tailor your tooling to meet the needs? So let's walk through these three categories real quickly. So this is the Scrum Life Cycle. I'm sure many of you are familiar with it. So I'm not going to belabor the point. So very clearly focused on the construction part of the lifetime. Which is important? Very important. Good stuff. Great ideas. You should probably consider adopting them. But as we know, there's more to it. Yes, there's construction without a doubt. So that's all good stuff. But we need to kick the project off somehow. We're going to do a little bit of initial planning up front. A little bit of initial requirements. That product backlog, which really isn't all that accurate, by the way. But anyways, this stack of work items has got to come from somewhere. Requirements just don't magically appear. And they don't get beamed down from the Starship Enterprise, if you followed the panel yesterday. But you've got to do a little bit of modeling up front. You've got to populate the backlog. I'm sorry, you've got to populate the backlog. I swore again. I said modeling. You've got to populate the backlog. Or repopulate the backlog. You've got to remodel throughout the construction as well. And you probably have to go hat in hand, get some funding for the project. Because money just doesn't beam down from Starship Enterprise either. Somebody needs to sign off and fund your project. So there's a little bit of upfront work. Some people call this sprint zero or iteration zero. That term is, of course, incorrect. First of all, if people are renumbering backwards in time, they didn't think a few things through. That's an indication right there. But it's not a sprint. And we know this because, well, at least I know this, because I do industry surveys. And the average construction sprint or iteration is roughly two weeks in length. Okay, that's pretty good. But the average effort to start a project is four weeks. So that's either one hell of a long sprint or it's several sprints, or maybe it's not really even a sprint because it's a different animal completely. So we need to start thinking. But the same thing with transition, by the way, this is, I think, four and a half weeks on average. And obviously, some people are doing transition on the order of minutes or hours if they're fully automated. Some people are transitioning in the order of months if they're fully dysfunctional. So I've seen some organizations that take three to four months to do transition of a system and they wonder why it's so expensive to develop anything. But what can you do? So we need to be a little bit smarter about this. And there's a few other things. This is the basic or the simple life cycle of dispensational delivery, which is based on Scrum. And there's a few other features that are interesting. It's enterprise aware. So you should be working with the enterprise architects. I'll be talking about enterprise people in general. I'll talk about that later. And it's scalable, which is where we get in the next slide. So like I said, this is for, both of these things are for fairly straightforward situations. And what happens when the situation is not so straightforward? This is where things get interesting. So what does it mean to scale? So what I'm going to do, I'm going to walk you through eight scaling factors one at a time. All the scaling factors are described in this sort of a format where on the left, from the point of view of the team, this is important for one of the scaling factors. From the point of view of the team, the simpler situation to be in, or the desirable situation to be in as the case may be, is on the left-hand side, on the right-hand side is the more difficult situation to be in, and it's actually an analog range. So you're co-located when all the people on the team are in the same room, including your key stakeholders and you work together to get the job done. This is the desirable situation to be in from a geographic distribution point of view.  This is a good thing. You're distributed. If you have people working in cubes, even though you're in the same building, you're now geographically distributed. You have erected barriers to communication. These are called cube walls. And there's a wonderful series of cartoons, Dilbert, that make fun of the challenges of working in cubes. They're right. Your success rate measurably goes down by several percentage points when you work this way.   Sometimes, your success rate going down by several percentage points because of the interior decorating decision to have cubicles. Let alone offices, let alone having people working on different floors, let alone having people working in different buildings in the same campuses. There's wonderful studies that say that if you have people working in two different buildings, even though the buildings are side by side, so I work in building D and you work in building C. The chances of me talking with that gentleman, because he's in the other building, he's one of those, he's one of those C people. He works in building C. I'm not going to talk to him unless I happen to be on a softball team or some other thing outside of work. That's the only, more than like the only way I'm ever going to talk with this guy. He might as well be on the other side of the planet by that time. There's been studies that show this. So, anyways, there's bad news. I've done work that says it's not quite as bad as him being on the other side of the planet, but it's darn close. And then let alone if you're globally distributed and you've got teams in different locations, and then your success rate plummets. And this is true of all paradigms, not just agile. So avoid distribution if you can, and sometimes you can't. So life's tough. Then you have large teams where you have different team sizes. See if teams of two people, teams of 20, teams of 200, teams of programs of 2000, it's not just a team by that point. And by the way, agile works at all points in scale. Like I said, I do surveys. I've got data that shows that I've got people reporting that they're succeeding at agile at all levels of scale on all of the scaling factors I'm going to talk about. So don't let anybody tell you that agile does not scale. Please don't. They might not, if they tell you that, what they're really saying is they don't know how to scale agile. Okay, that's a different thing, right? They're not communicating correctly, but they're telling you they don't know how to scale agile, which is okay, they just don't know. But other people have figured this out. So other people are succeeding at this. Doesn't mean that you will, but it is possible. Other people are. So we need to observe that and act accordingly. Sometimes you have regulatory compliance. That was a talk earlier on today. It's easy when you have no regulatory compliance. And there's different types of regulations, by the way. So there's Sarbanes-Oxley, which is reasonably trivial, all the way up to the FDA type regulations, where you're building medical equipment, or you're working in a pharmaceutical, you're supporting the development of drugs, not doing, oh, you might be doing drugs, but hey, why not? I'm from Canada, we're fairly liberal. So we were this close to legalizing marijuana, and then we voted the conservative party into place, which is our version of the Republicans, if you know the American politics. But anyways, that's okay, they won't last forever, so we'll eventually be able to smoke up. So anyway, so compliancy, it changes the way you work.  A lot of the compliancy is around, when it boils down to it, it's around risk management and good stuff like that. One of the really good suggestions from the previous talk is to read the regulations.  Most people hadn't read the regulations in the last few years, even though they were working in regulatory environments. And what happens is, if you let the bureaucrats interpret the regulations, which most people do, because they can't be bothered to read these phenomenally boring regulatory documents, you end up with bureaucratic responses. You deserve what you get. If you're gonna be that lazy, if you're gonna outsource the interpretation, which is the effect of what you're doing, you're outsourcing to a bureaucrat the interpretation of your regulations, the bureaucrats will put together a bureaucratic strategy to address the regulations. If you let the practical people, and I hope you're all practical, if the practical people interpret the regulations, you'll end up with a practical response. Isn't that nice? So, take a hit and read the regulations every so often. Yes, they're phenomenally boring, and what can you do? Now, it's interesting at this point in time, I usually like to make a point that different teams are in different situations. So my team might be distributed, might be all in the same building, might be a team of five people in the same building in a non-regulatory environment. This gentleman's team could be spread across the planet, be 20 people in a regulatory environment. That gentleman's team could be 500 people on the same floor in a non-regulatory environment. That's okay. Different teams are gonna work in different manner. A team of five people, I think it's pretty obvious, that a team of five people will organize themselves differently, will work differently than a team of 50, than a team of 500. A team in a non-regulatory environment will organize themselves differently, and will work differently than a team that is suffering from having to comply to Sarbanes-Oxley, who in turn will work differently than a team that's in an FDA regime. A team that's co-located will very obviously work differently than a team that's spread across a building, than a team that's spread across the planet. Different teams, different situations, different ways of working. So many of you have heard about ideas such as CMMI and CMM who sometimes prompt the idea and actually they don't if you were to actually read those regulations or read those, that guidance. It often gets interpreted as we have to have a repeatable process.   That is useless bureaucracy. Useless bureaucracy. Nobody wants repeatable processes other than useless bureaucrats. What we really want are repeatable results. We want to spend the money wisely. We want solutions that meet our needs. We want systems out in a timely manner. We want sufficient quality. Nobody cares what processes you follow. This morning there was a gentleman talking about lean IT and their experience at their organization adopting lean stuff. It was a really good talk. And one of the things that he just mentioned offhand was that in their organization they had adopted CMMI, they were like level five, they were doing Six Sigma and they weren't getting the benefits. They were still unpredictable.  There were some serious challenges. The promises were not because they were producing a lot of paperwork from the sounds of it. They weren't producing good solutions. And that's a perfect example of bureaucracy and not of discipline. So anyways, avoid, really don't get in the trap of looking for repeatable processes. The different teams are in different situations. You need to tailor your process. You need to tailor your tools. You need to tailor the team structure to fit the situation you find yourself in. One size does not fit all, will never fit all and never fit all and will never fit all. We need to be a lot smarter about the, we need discipline, we need skill. We need to be a lot smarter about the way we work. Sometimes you have domain complexity. Pretty straightforward to build an informational website.  A little harder to build a, you know, the Watson system that wins at Jeopardy or an air traffic control system or the control system for a nuclear power plant. Okay, so different teams are in different situations. I would hope that the team working on a nuclear power plant works in a slightly more sophisticated manner than the team building a website. God fuel tells me that would be happening. Sometimes we're organizationally distributed. Now, I'm sure none of you are involved in outsourcing here. But sometimes some organizations split the work up. They do some of the work and they have another company do some of the work. Or they partner, you know, sometimes there's companies that are partnering together. So, and this adds some complexity. It's pretty easy when everybody works for the same division of the same company. A little harder when you're working for multiple divisions. Harder yet when you're trying to partner with other similar companies to build some sort of shared infrastructure. Harder yet when you have outsourcing and contractors and all this sort of stuff that's being thrown into play. Sometimes there's technical complexity. Yes, it's pretty easy when you're building a silo system that is a green field so it doesn't have to connect to anything. Brand new technologies. No legacy whatsoever using all the whiz bang tools. Yeah, that's pretty straightforward. Some of us though are working in situations where maybe it's not the greatest, you know, the brand new technology anymore. Maybe it's not a standalone system. Maybe we have some legacy code that we have to integrate with. Maybe there's some legacy code that we have to evolve and fix. Maybe there's some legacy data that we have to use. Maybe there's some legacy data that we darn well should be fixing because my data people don't know how to do it themselves. Not that I'm bitter about that. Promo and Satellage had a great talk a couple of days ago, I hope, about fixing databases and stuff like that. So it's a little bit more difficult than something. So over lunch I was talking to somebody who had a situation where they were dealing with legacy code. How do you fix work on a mainframe and do Agil on a mainframe and fix this ancient cobalt stuff? Well, yes, it's possible, by the way. People are in fact succeeding at that. And it's highly desirable to do because some of these cobalt programmers are getting a little old and are going to retire soon. And that cobalt stuff is not going away, folks. I now know people. I have friends who are working on source code that is older than they are. I have absolutely no doubt that somewhere in the world there is a programmer right now working on source code that their father wrote. In a few years it'll be their grandfather wrote it. I have no doubt that that's going to happen. This source code stuff does not go away. Sometimes there's organizational complexity. It's often not this big happy family we keep reading about. There's politics. There's people in different parts of the organization have very different ways that they want to work. The CMI folks might not appreciate the fact that I'm beating up on them. But you can in fact do Agil and still be CMI compliant. There's some wonderful writings on that if you choose to read them. Sometimes the data folks have this very coherent at least to them this very coherent story for why they have to do these detailed logical data models up front followed by detailed physical data models. And then and only then would the programmers be allowed to start coding. They had these coherence. Well, they think it's coherent. But regardless of all the evidence showing that it doesn't work very well. But that's their religion. They believe in that and they have a good story around it. You still have to work with these folks. You still have to find a way to work together. So that brings a few complexities into the situation. And then finally, and this is the one where it's a bit weird. The discipline teams actually want to be on the right hand side not on the left hand side. And the basic idea here is you should have enterprise discipline or enterprise awareness. You should want to be following common coding conventions. You should want to be working close to the enterprise architects to understand what your infrastructure is. What can I reuse? What should I be building out so that that way other teams can reuse them? Where are my legacy data sources so that I'm not creating yet another customer database? Where, how do I fit into the overall portfolio management stuff? How do we govern the teams effectively? That would be a wonderful thing. A lot of IT governance efforts are phenomenally dysfunctional. They're dysfunctional for the traditional teams let alone for the agile teams. And these stage gate documentation based governance approaches are not good, particularly not good for agile but not that good for traditional stuff as well. So having enterprise discipline can change, also affect the way that you tailor your process, the tailor your tools, tailor the structure of your team. It was interesting that the previous speaker in here was talking about architecture and how architects fit on the team. And it was pretty clear that some people in the audience really were not getting it. And it was like a foreign concept to them. And what happens is when you start having an enterprise discipline, I think actually enterprise discipline was in the title of her talk or something very similar to that term. When you start looking at the bigger picture, you start changing the way. So she was in an environment where they were a little more mature and they realized they needed these architects on the team and that changed the team structure. They added an architect and the architect did stuff and help the team and did whatever, right? So it changed the team structure let alone the process and obviously the process they were following. And may even have changed the tools they were using. Maybe that architect started whipped out a modeling tool or something and started doing modeling. So who knows? So anyways, interesting observation to have. So how does this affect things? So let's walk through a few common practices. So how would I scale daily stand-up meetings or a daily scrum meeting, whatever you want to call that. So first of all, when we move to a more discipline approach, we start calling them by what the incident is calling it a scrum meeting, which is a branded term. Let's call it what it is. It's a coordination meeting and there's different ways of holding it of course, but it's a coordination meeting. It's not a scrum meeting or a daily stand-up. When you're geographically distributed, you're at least going to involve phones or maybe video conferencing or something. Maybe even typing, I'm going to make all these slides available on the agile site on the conference site. So you don't need to worry about writing madly. But yeah, you'll be doing some sort of electronic chatting or something. And they certainly won't be doing a stand-up meeting. I've actually been in situations where the scrum, so we have teams in multiple locations and the scrum master on the phone is saying, I want everybody to stand up at their desk so we can have the stand-up meeting. Do you really think that people are going to stand up to have a conversation over the phone?  But anyways, what can you do? When the team gets bigger, there's a different way you've got to deal with it. You can maybe have a scrum of scrums and that's good for up to medium-sized teams. I'll talk about this in a bit. It craps out with really large teams. Or you can take the combine strategy where they speak on a task board and what they're really looking for. What are the bottlenecks? What problems do you foresee? Because they don't need to worry about the stat... Because if you're working closely together on the team, we don't need to hear the status, all the status reporting that occurs in the scrum meetings. If this group of people here was a big team, a team of, I don't know, 100 people, I don't know what it is, but say you're a team of 100 people. Even if you're co-located in a really big room, I'm not working... I'm not really working with all 100 of these people today. I'm working with these three or four gentlemen across the front on a regular basis. And because I was working with them all day long yesterday, I got a pretty good idea what they did. They got a pretty good idea what I did. So we don't need to hear our status. We know. The people over there, I haven't interacted with them for months now because they're not really part of my little group of doing whatever it is that we're doing. I could care less what their status is. As long as they're not screwing up and affecting me or if I'm not screwing up and affecting them, we don't really care what they did yesterday. I don't care what they did yesterday. I don't care what they're going to do today. They don't care what I did yesterday. I don't care.  It's useless extraneous information. Everybody's wasting their time hearing this stuff. So in common, what they focus on is the real value. What's blocking us? If there's nothing blocking us, hey, we're good to go. Stop the meeting and let's go get some work done. If we're in a regulatory compliance situation, maybe we're sick meeting attendance. Maybe we're going to have to record action items because you got to show that you're following the process. At least you're going to have to record the fact that you held a meeting because in some regulations, you got to show that you're following whatever your process is. If you're organizationally distributed, so you've got different people working on different teams, you might not actually be a lot... If you've ever worked in a secret type of a situation or like a government situation, if you're working for the military, different teams might not even be allowed to know that the other teams exist, let alone what they're doing. So you got to be very careful about what status you're sharing. Or if you've got multiple consulting organizations involved. So I got TCS, I got WEPRO, I got IBM, and we're all working together for a bank in Europe. Chances are pretty good that the WEPRO people and the TCS people and the IBM people don't really want to share details with each other. This is real-world stuff now. So this is going to change the way that we hold meetings. We're going to make sure that only the right people are talking to each other. And if we've got enterprise discipline, we might have enterprise professionals showing up at the meetings. I might be inviting my portfolio management people to when I'm discussing project management issues. Or in my architecture meetings, I might bring in the enterprise architects and ask them to be involved.   And if you don't know what I'm talking about, you're lucky, don't worry about it. Okay, so scaling self-organization. If you consider this a practice. Okay, so like I said, one of the very first steps when you're moving from the construction focus of scrum to the delivery focus of dad, the very first thing is we bring in the concept of appropriate governance, the adult supervision concept. Because this is what we see. This is the types of things we see in real enterprises. If we're in a regulatory compliance situation, these plans or these estimates that we're talking about, we might have to record them. We might have to actually document them on more than just index cards in order to avoid fines and stuff like that. If we have organizational complexity, organizational complexity is IBM's nice way of saying organization dysfunction. So if we have a dysfunctional organization, we might need to educate our management team on basic leadership stuff and basic facilitation stuff and why this self-organization concept is a good thing and why they should be promoting it. We should be helping them get away from the command and control stuff. I ran a survey about a year and a half ago and within the agile community, I was trying to judge how agile people actually were. So I asked these, so are you agile? Yes, okay. Then I asked a bunch of other questions to explore how agile they were and roughly half the people claiming to be agile were agile in my mind. And I was being phenomenally generous. And one of the things that the most common thing that people were not as agile on as they should have been was self-organization. And I highly suspect the project management offices in their companies were getting in the way. They weren't allowing these teams to be self-organized and they weren't allowing them to have stand-up meetings or coordination meetings, I should say. They weren't allowing the developers to do the estimation and stuff like that. They were still being told what to do. They were still being told what the plan was. This is not good. This is hampering people's agility to be successful. At the enterprise discipline level, I might be bringing in the enterprise architects to help us help drive some of our architecture decisions or help motivate or mentor some of our people in this stuff. I might adopt some governance strategies from lean development governance. So things change, different situations. So here's the interesting thing. So for both of these practices, it's still the same basic practice of having a coordination meeting every day. Because you're in a different situation, you'll have a different flavor of that practice. Same thing with self-organization. The flavor will change depending on what scaling factors affect you. If you're doing an iteration demo, it will change based on the situation you find yourself in. If you're distributed, you might be doing a webcast instead of a face-to-face demo. In a regulatory environment, you might have to take meeting minutes again. You might have to re-context. In other contexts, it's really bad advice. So let's be clear about the context of the advice that we give. So having a daily stand-up, that's great advice for when you're co-located.   So it's not really a stand-up meeting. It's a coordination meeting. So basic things like this. So the advice should depend. Okay, so some practices that you might want to adopt that maybe you haven't heard of. Maybe you never heard in your two-day certification courses. So first of all, you might want to think before acting. This is what some of the agile modeling practices are around. So in the agile modeling methodology, which I led the development of over 10 years ago now, we have a few practices for doing some up-front, lightweight up-front requirements envisioning, some lightweight up-front architecture envisioning. By the way, 90 some odd percent of agile teams do some up-front modeling, regardless of the rhetoric you might have heard. And that is information coming from agile people.  And 90% of them, over 90% of the respondents have very clearly said, yeah, we're doing some form of up-front requirements modeling, some form of up-front architecture modeling, some form of up-front planning. Then you do modeling throughout the life cycle. Modeling is part of iteration planning. So you're pulling user stories or features or whatever off the stack, and you start talking about it, you might do a whiteboard sketch to figure out what the tasks are, you're at least talking about it. So modeling ends up becoming part of, it's actually part of your planning efforts. And it was actually interesting, I ran a survey just recently about planning and how people do planning throughout an agile project. One of the things I did, I luckily had an open form question where I was, when I was asking about initial modeling on a project, and roughly half of the response, this is how, I was just shocked at this, roughly half of the respondents to the survey were talking about doing initial requirements modeling, and they thought it was planning. So they were doing, yeah, so their idea of initial plan, which is okay, it's good that they're doing this, don't get me wrong, but they were struggling to communicate what they were doing. So they were doing, initial, they're doing, they're populating the backlog basically, right? So they're identifying a bunch of initial user stories and prioritizing them, and then they said that this is my planning activity. Well, no, that's initial modeling, and well, prioritization is arguably planning. Okay, fine. But creating the user stories, that's a modeling activity. So, we need to get better at communicating with the heck we're doing. But anyways, that's an example of requirements envisioning actually. And then finally, and we're doing documentation throughout the life cycle, either we're doing continuous documentation within the iterations themselves, or, which, so if you want to be potentially shipable, that's the way you got to work. Perhaps a better, well, there's risks involved, but the most efficient way is actually to leave the documentation towards the end of the life cycle. But you've got a very, but then you're not potentially shipable, so you get some very serious risks there. Cheaper to do, but there's some risks. So, there's always trade-offs. There's no perfect situation. And executable specifications are writing tests instead of writing static documents. So, instead of writing an SRS, you write executable and acceptance tests, things like that. So, and obviously require skill and the right tools and discipline and all that sort of stuff.  And, you know, obviously Agile modeling is not the only one talking about test-driven development, but those practices are there, if you're interested, at agilemodeling.com. Appropriate governance. So, I used this term earlier. What is appropriate governance? Good governance is based on collaboration and motivation and on enablement. So, it should be based on human behavior. Command and control governance of you. Follow my Java coding conventions or else. Chances are he's not going to do it, right? He's an intellectual worker.  He thinks better. He knows better. What is this guy now? Screw him. He's senior management.  But if I say, well, you know, we've got these corporate coding conventions. It's really good. It would be really good. We would like you to follow them because we'd really like everybody to be writing the same basic code because it's easy. If everybody's following the same conventions, I'd say if you have to update somebody else's code, you'll be able to read it easier. If somebody else has to update your code, they'll be able to read it easier, leads to better quality, blah, blah, blah. A bunch of benefits for doing that. So, I motivate them. So, it's a coherent story, right? People are like, yeah, yeah, he's pretty little inconvenient, but he's pretty much right. Okay, so their motivation is there. Then if I also say, oh, and by the way, here's this tool that you can throw into your continuous integration to check against the coding standard. So, we can automate that. And I can throw warnings. And so, if you break the coding, if you go against the coding convention, I'll throw a warning the next time you compile or the next time you build and let you know that. So, that way you can very quickly learn what the coding conventions are. Oh, making it easy now for me. So, I motivate them to do the right thing. I make it as easy as possible to the right thing. I also make it difficult to do the wrong thing because if he screws around, it follows his own coding conventions because he still thinks he knows better than me, he's going to get a heck of a lot of warnings coming out of the static code analysis, right?  So, reward the right things, punish the wrong things. That's going to greatly increase the chance that your teams follow and do whatever it is that you desire them to do. So, that's one aspect of governance. Another aspect of governance is monitoring the teams. So, good governance should, if I'm on the governing body in your organization, my goal should be to help make it as easy as possible for your teams to do the right thing, to get rid of some of the barriers to success. Some of the things that they talk about scrum masters doing at the project level, we should also need to occur at the organization level. I should be trying to make sure that you're building the right thing, that there isn't other teams out there, so that this guy here, he's not working on an ERP system. This guy here down the street in another building is also working on an ERP system. I don't need two ERP systems, right? So, if I'm governing effective relations, I say, whoa, wait, what the heck is this? And I should get these teams talking, and they're figuring out how to motivate them to come to some sort of solution to have one ERP system to get the job done, things like that. I should also be doing, hopefully, have automated metrics, having, if I adopt tools that generate the metrics for me, then I can have automated dashboards that show the metrics. If you want to get an example, if you drop by jazz.net, you can see live project dashboards from several IBM teams of building actual products in progress, and all of those metrics are being generated automatically by their tools.  No more of this typing stuff into Excel or typing stuff into a point specific tool. All bureaucracy, by the way, even though it's blessed, the blessed bureaucracy of Scrum, it's still bureaucracy. You could automate all that away if you choose to, and that way you can actually focus on doing your jobs. And the beautiful thing about that is great for the teams because they can focus on doing their jobs, as opposed to focusing on status reporting type stuff, like manually generating a burn down chart. And better yet, if I'm from a governance point of view, I can get accurate real-time assessment of what the heck's going on in the team. So if I notice that something's going wrong, I can walk down the hall or hop on the phone or get on the chat system and ask what's going on is there anything I can do to help? So if I see that your build has been broken for a couple of days, that might be a clue to me. Maybe I should give you a call because maybe you're running short of heart. Now you've got some hardware problems. You've got network problems. Your build master died. Who knows, right? Maybe I can help. So this is the idea here. And maybe I can make coherent decisions. If I know your actual status, I might be able to make real decisions to help your team as opposed to guessing. It's interesting. We like to make fun. Developers like to make fun of senior management, right?  They don't know what they're doing. And that's when they're being polite. It's not true. It's not true. These are smart people. They really are. They're smart people. They're doing the best that they can, given the information that they've got.  If we can improve the timeliness of the information, if we can improve the quality and the accuracy of the information, chances are managers will start making less stupid decisions because they are smart people who are actively trying to do the best that they can do. They really are. They're good, decent people. They really are. And they're doing the best that they can do. So let's give them more accurate information. Let's help them understand what the heck is going on. That will increase the chance that they don't get in our way. Wouldn't that be nice? So anyway, something to think about. Another technique that you might do at scale, something called parallel independent testing. So in Agile, we talk a lot about how the development team should be doing their own testing and the whole team testing all this great stuff. TDD, love it. Problem is it's not sufficient. So yeah, if I'm in a small team in a small organization, yeah, whole team testing is probably going to get the job done. You're assuming you got the skills, right? So we'll give the Agile teams the benefit of the doubts. They got the skills. They got the tools. They know what they're doing. Let's assume that. It's not always true, but let's assume that for the sake of discussion. Even then, they could be in trouble. So in a few situations, I might have to have an independent testing team. In a regulatory environment, I'm probably going to have to have some form of independent testing. Most regulations imply that. If I'm in a complex domain, if I'm doing a complex system, I might have some very interesting integration issues. So earlier, if I'm one of 20 teams in the organization, then I've got to make sure I'm testing against these other systems that are also in flight that are also being developed. I can't do that. I don't have the resources. I can't possibly keep track of these other 20 teams' builds. I can't possibly do all the integration work that I need to do to get them all up and running. Regardless of the wonders of virtualization, and IBM is happy to sell you anything you need to do it, regardless of all that wonderful stuff, you're still probably not going to have the resources to simulate production in an intelligent manner. And you certainly will not have the resources. No organization has the resources to do it individually for 20 different teams in flight, let alone 100 teams, or whatever you've actually got up and running right now. So economically, you're going to have to have an independent test team that will do this pre-production system integration testing for me. So my team will push my build, or make my working build available to that test team. Your team will do it. Your team will do it. Your team will do it. And then the test team will do this harder form of testing of making sure everything works together well. And then when it doesn't, they report defects back to the individual teams. And they might be doing even other forms of testing, like security testing. How many of you are working on systems where you have security experts on your teams right now? A few of you. How many of you are working on systems where you might have some security concerns because maybe you're building a web-based system? Oh, uh-oh. Screwed, right?  So you might want to be doing some security testing. So if the independent testers know this, oh, they're building a web-based system that's going to be deployed out to the internet. Oh, there's a few hackers out there that like to break into systems. Maybe we should be doing some security testing, right? So, and because security testing is a skill and there's expensive tools and stuff like that, and you're more than likely, you're not going to have the ability to put security experts on every single team. We saw this just now. More than likely, you're not going to have the money to buy expensive security testing tools for every single team, right? So economically, you're going to want to centralize. This is a bunch of different reasons for having independent testing. It's a phenomenally good idea. And worst case, if you put an independent testing team up and you find out that they're not finding any defects because the agile team is actually doing a phenomenal job at testing, okay, fine. That's great. Now you know, now you've verified that. If on the other hand, you find, oh, this independent testing team is in fact finding defects early in the life cycle when they're inexpensive to fix, that's probably a good thing. I don't want to be doing testing at the end of the life cycle. I don't want to leave acceptance testing to the end. I don't want to leave integration testing to the end. That's the worst possible time to do testing is at the end of a project. The most expensive way of doing it. Well, actually the most expensive way is to not do any testing at all and let your users test. And bad things really happen. But yeah, I want to push testing to the front of the life cycle as much as possible. So large team stuff and then we'll end up. So the basic idea here is how do you organize a large team? There's a lot of literature around how do you organize small teams. But what happens when you've got a team that's 100 people, 150, 200 people? First of all, you're going to organize and there's no such thing as a 100 person team. It's a team of teams. So how are you going to coordinate these sub teams with each other? So if you're only three or four sub teams, then yeah, doing a daily Scrum of Scrums where you share your status and all sorts of stuff with each other, that'll probably get the job done. But when you're in a larger situation and you get a larger team than that, the Scrum of Scrums concept starts to fall down. What's happening here is there's three, maybe four things that you're coordinating. First, you're coordinating basic project management stuff. You know, what's the current status? How much money are we spending? Are we onboarding people? Are we off-boarding people? And if I've got a team of 100 people, chances are pretty good one or two people left this iteration. One or two people got hired on this iteration. So I've got these basic management stuff of bringing them on and off. If I've got a 100 person team, I don't know what your charge rates are here, but you're spending a fair bit of money every week. You probably should be tracking it. So there's the basic project manager, program management stuff that should be occurring here. Somebody should be making some coherent decisions. You should be coordinating the activities between the teams. Then on the requirements management side of things, the product, there's dependencies, functional dependencies between requirements between the different subteams have got. So you've got to manage these things. So if my team is working on something right now and we expect a feature that this gentleman's team is working on, then if we're managing things accordingly, his team will either be doing it in the same iteration as mine or in iteration before. Because if I depend on him to deliver something, and we're both in iteration five right now, but his product owner has prioritized it down to iteration nine, the things that I need in iteration five, I'm out of luck. I can have to mock it out or whatever. And as soon as I mock something out, I'm no longer potentially shippable. I now have a risk. So what we should do is the product owner should get together and negotiate. I need it in iteration five. He thinks it's going to be iteration nine. Maybe we split the difference. Maybe he prioritizes up. Maybe I prioritize down. But something got to occur, so that way everything works out well. So this prioritized simply based on business value, interesting and quaint concept for small teams for larger teams, reality gets in the way sometimes. So stuff like that happens. And then there's technical issues that you've got to coordinate. So you'll have an architecture owner on your team or an architect depending on your terminology, and they'll be part of the overall architecture team for the overall program. And they'll be negotiating technical issues as time goes on. And so people on the team will be bringing stuff up and everybody will be working together. And then finally there's probably an overall program manager keeping an eye on all this stuff and managing it all. Because you've got a 100-person team, I would hope there's at least enough work to keep one person busy coordinating everything. I'm even just running the leadership team is often enough. So the team lead or the scrum master in each team is part of the project management team. The product owner is part of the product ownership team. The architecture owner in each sub-team is part of that team. And then all these people together form the leadership team. So that's the basic idea. So these are some of the ways that you're going to be organizing larger teams. You'll probably have independent testers involved, which might be a sub-team all by itself. You might even have a build master or an integrator person because the integration effort is so difficult now because of the complexity that you're implementing. There's a couple strategies around. There's different ways to organize. There's great religious debates, all of which are a name around how do you organize large teams.


In lecture 15, we began our official study of trigonometric identities. We reviewed the fundamental identities we've seen previously in the lecture series, and we've used them to simplify both trigonometric and algebraic expressions. So what our goal is, and one of the big goals of chapter six here, is for us to learn how to prove our own trigonometric identities. And so this often is intimidating for many trigonometry students. And I mean, it's unfortunate thing because trigonometric identities are our friends, they're our tools. Basically, what we're saying is every trigonometric identity is a tool we can add to our toolbox. So do we want a toolbox that only has like a hammer and a screwdriver? Or do we want a hammer, a screwdriver, a ratchet, some wrenches, a saw? I don't know. I mean, there's so many tools.  You can see all these tools. It's like, wow, I need a square. That's so awesome. Oh, I need that crowbar. I often do home renovation projects in my home. And so I love and excuses like, ooh, I gotta go buy a reciprocating saw because I have a job that requires it. So every time I do a new job, I basically get a new tool, which makes my toolbox bigger and bigger, bigger, bigger so that I can do better and better, better jobs. My jobs become easier the more tools I have. And that's how trigonometric identities work as well. Now, unfortunately, if you have a very obscure tool, like what in the world is an Allen wrench, right? What's a hex key? They're the same thing. But, you know, but if you don't know how to use it, then it's not a very useful tool. We need to learn how to use them. And so in this case, we need to learn how to prove these trigonometric identities. And so in that regard, what I'm gonna do for the remainder of this lecture 15 is give us pro tips on proving trigonometric identities. We'll do that in force in the next lecture, of course. And so each of these videos will be one tip at a time so we can drill in these ideas of how to prove trigonometric identities. So the first tip, which you can see here on the screen, when proving a trigonometric identity, always work one side of the equation at a time. That is transform the left-hand side into the right-hand side or transform the right-hand side into the left-hand side. We never, ever, ever, ever, ever, ever one more time, never use operations that involve both sides of the equations at the same time. So before we prove the trigonometric identity, let me show you why we never do operations on both sides of the equation at the same time. Let's prove the following. I have a theorem for you. The theorem is that one equals negative one. Now you might be laughing at me right now. This is a false statement, right? One's not equal to negative one. Well, here's the proof. The proof is one equals negative one. I'm then gonna square both sides in which case one squared is equal to one. And then negative one squared is also equal to negative one. Oh, well, negative one, or one equals one is definitely a true statement. So since this statement is true, that must imply that the original statement was true. And that's the proof. That's a false proof, right? That is not true. Don't do that, right? But that illustrates a point. This is how many students try to prove trigonometric identities. And the thing is, if this is a valid proof technique, then I can prove a false statement that then becomes true. Well, that's not the case. It means the technique is invalid. So any truth we discover using an invalid technique actually doesn't verify the truth of it at all. So we don't work simultaneously with both sides of the equations.  Well, let's see what we could do there. We could divide both sides by cosine theta, right? The cosine there canceled. Then you get tangent theta equals sine theta divided by cosine theta. Oh, tangent equals sine over cosine. That's the ratio identity. Boom, I'm done. So they would say that's the trigonometric proof, which that's not a valid proof. That's the same problem about proving one is equal to negative one. Basically, the issue here is it's circular reasoning. If you start using this equation, like if you start working on both sides of the equation simultaneously, you're assuming it's an equation, because those techniques are only valid to equations. In which case, if you assume it's an equation, you assume it's true, right? In which case, then you're assuming it's true, then to get to a statement that's also true, and then you conclude the truthfulness of the original statement. This is circular reasoning. It's not a valid logical argument. So instead, what we have to do is we have to work with, pick one side. In this case, we're gonna pick the left-hand side. So pick the left-hand side, cosine. Oh, so that's just cosine theta, tangent theta. And we have to then show that the left-hand side is equal to the right-hand side by a sequence of identities. So we might say something like, well, what if I change tangent into sine over cosine? So we get cosine times sine theta equals cosine, or sorry, sine theta over cosine theta. So these equations can be justified. So this first equation is justified by the ratio identity. All right, then the next one is just, well, cosine cancels out the cosine, and we get that this is equal to sine theta, like so. And what's the justification here? Well, this is just an algebraic simplification. You just simplify the expression by canceling out the cosines. And then you'll notice that sine theta is equal to the right-hand side. And so we've showed that the left-hand side is equal to the right-hand side as a sequence of equalities. And you can write those equalities horizontally, or you can write them vertically, or a combination of the two, doesn't matter. But the point is you move from the left-hand side to the right-hand side. You don't work with both sides simultaneously. You just take one step at a time, one step, two step, red step, blue step, things like that. You just do one step at a time. The ratio identity was applied. An algebraic simplification was applied. And that showed that the two quantities were in fact equal to each other. It's important you only work with one side at a time and move from that side to the other side. So that's trigonometric identity tip number one.


Rwy'n gweithio yn y tynnu i'r ysgol yng Ngharliwyr i'w ddweud yng Nghaerdydd. Brannu'n ddim yn gallu ddweud i'w ddweud i'w ddweud. Yn y gofyn, dwi'n ddim yn ychydig i ddigonwch ei ddim yn ddweud, ie, mae'n mynd i'n ddweud. Rydych chi'n amser ar y fanau'r ddweud, yma'r ddweud yn y cwrnod yn ddweud, mae'n ddweud y gweithwyr, mae'n ddweud, I'm more than confident to be going into the seas and on a positive note looking to earn promotion. And what do you know about the squad at the moment? Obviously just now I've done from playing against them over the years and stuff and seeing bits and bobs, but now it's a good squad. It seems to have a bit of everything. And you've played at the Northern Commercial Stadium, you've scored there. You know what it's all about. It'll be very different, I guess, running out in the Clouwerthamber. Of course, there was a massive factor in me signing here, the fan base, the passion behind the fans, and the support is great, so it's... oh, can't wait. And do you sense a little bit of pressure, obviously? You know you're going to be the number nine, but I mean you'll be looking at the squad thinking you've got the guys around you to get you the ball way you need to put it. Yeah, absolutely. Pressure-wise I don't really feel, not the minute anyway. Maybe when I go again or two, without a goal, it might come hit me down, but no, as I said earlier, I can't wait to get going now. Can't wait to meet the lads, settle in, and hopefully we'll have a successful season. In a relatively young squad though, you'll bring some experience to what you've had. 400 plus games in the football league. So you know everything about these divisions and what's required to achieve? Yeah, of course, yeah. Hopefully I can... it seems to have long gone. It was one of the young ones myself, but it feels like hopefully I can come in here, help a couple of the young lads on their journey as well, I suppose. Now I'm confident what we have here as a squad is more than enough to get us over the line this year. And just lastly, what will you bring to Bradford City? What are you looking to achieve here from a personal standpoint? Promotion, obviously. That's something that we're hoping to achieve. Personally I'll just give me all, run myself into the ground for 90 minutes every week, and hopefully chip in a few goals and aid the team in a successful season.


The study assesses the immunogenicity and safety of H7N9 vaccines through meta-analyses of randomized clinical trials, finding that adjuvant vaccines with Iscomatrix, MF59, AS03, or aluminum adjuvants improve immune responses effectively, while non-aluminum adjuvants save vaccine dose. The study concludes that H7N9 influenza vaccines with adjuvant may be the optimal available option in an influenza pandemic at present. This article was authored by Dan Jing, Facial GAO, Cheng Jiao, and others.


Welcome, everyone. Thank you for joining us. My name is Susie Lee, and I lead program-related investments at the W.K. Kellogg Foundation, and I will be moderating our discussion today. It's an honor to join forces again with SOCAP to host this conversation with our friends at every table. Every table is a mission-driven food company disrupting the food system by providing affordable, nutritious foods in communities that lack access to healthy options. In addition, they are providing flexible financial support to entrepreneurs through a radical social equity franchise model. The Kellogg Foundation is proud to be one of the early investors in every table. Three years ago, we made a one and a half million dollar program-related investment in every table to expand its retail stores and seed its social equity franchising model. We invested because every table aligns with our mission and commitment to creating an equitable, resilient, and sustainable food system so that every table can make good food available to children and families and create quality jobs. Today, we'll explore every table's innovative model, how systemic racism prevents people from accessing healthy, affordable food, and how a venture like this transforms the landscape by intentionally centering racial equity in its values. We see that workers are constantly being shortchanged in this current business environment. Small business owners of color were hit the hardest by the pandemic. Access to capital is disparate and many entrepreneurs of color did not receive the same federal relief as their white counterparts. Every table's franchise model is promising for entrepreneurs of color, their families, and the broader food ecosystem. And our goal for today's session is to really highlight the moment of opportunity to fix the broken food system and the financial system. And we hope you're inspired by every table's innovative model and come away with new ideas on how to embed racial equity into your work. Now I'd like to introduce our panelists. We have Caster D. Garrett Ademora, store manager, and every table university participant. Bryce Fluelen, executive director of every table's social equity franchise program, and Sam Polk, founder and CEO of every table. And as a reminder to all of our participants, you're welcome to drop comments or questions in the chat throughout the event. And with that, I will turn it over to you, Sam. Thanks, Susie. I really appreciate it.  And at our core, we're a social enterprise in Los Angeles whose mission is to transform the food system to make fresh, nutritious food affordable and accessible for everyone everywhere. And the history of the company is I was actually a hedge fund trader in 2009. And at the time, I started reading a lot about the civil rights movement, especially this series by Taylor Branch about Martin Luther King and the entire civil rights movement. And I was so moved by the courage that I read about, but also aware that so many of the injustices they were fighting were are still very much in effect today. And so, you know, that caused me to leave Wall Street and come back to Los Angeles where I grew up. And then basically didn't really know what I was going to do until one weekend sat down and started watching a bunch of food documentaries on Netflix. And one of them talked about neighborhoods that they called food deserts, which were neighborhoods where there was very little access to healthy fresh food and tons and tons of fast food. And for me, that was this sort of clarion call sort of life changing moment where I just thought, you know, healthy food is a human right and it shouldn't be a luxury product. And so, you know, that started a journey now eight years ago, where first we started a nonprofit to work with families on issues of food insecurity and food justice. And that led to the founding of every table. And the core idea of every table is can you create a food production model that is more efficient than a standard restaurant model so that you can bring down the cost of healthy fresh food. And the way we do it is we have a single central kitchen in every major region right now we're in Los Angeles and San Diego and then opening up in New York City this year. And at that kitchen, incredibly talented chefs create fresh, healthy, delicious meals, and then package those meals and grab and go containers, which sounds simple, but it's really the key economic insight which I'll get to. And then they take those meals and our fleet of refrigerated vans to our stores. And, you know, these are two of our stores, but just so you understand the vision, we plan to have over 30,000 of these stores across the entire country. And what's really interesting about these stores is because we have a single central kitchen, we don't have to do any food preparation at the store level. And so the efficiency of the central kitchen and the low operating and capital cost of the stores means that we can make healthy food more affordable and accessible for everyone. But for us, affordability means different things in different neighborhoods. And so while we bring value to all of our customers, we also charge different prices depending on the neighborhood. So if you live in a wealthier neighborhood like Santa Monica, you can buy an incredible meal from us for seven to eight dollars, which is about half the price of fast casual competitors. But if you buy the same meal at one of our stores in Compton or East LA or South LA or Watts, that meal will cost five or six dollars. And it's not charity. It's really about creating a system that is inclusive and works for everyone. And so you can see that this model allows us to drive down the cost of a delicious, fresh, healthy meal to even below McDonald's prices for far more actually food and far more nutrition. A few of the elements of our model is that we started in the beginning employing folks from the neighborhoods that we were most trying to serve. And that led to the creation of the social equity franchise model that Bryce is going to tell you about. So we are an inclusive employer. We have a supply chain that goes direct to farms and local and regional and regenerative farms, often prioritizing BIPOC farmers. And we also do quite a bit of emergency relief business. And this came up during the coronavirus crisis where we make sure to supply meals to homeless shelters.  So every table is really about a systems level change that is about healthy food access. But now with our social equity franchise program, I think we have the potential for much more impact. And I'll turn it over to Bryce to lead on that. Yeah, thanks, Sam. And Susie. So our social equity franchise program is an innovative and transformative model that eliminates two of the biggest barriers to entry for marginalized entrepreneurs of color getting into the franchise system. That access or significant upfront investment which can be anywhere from $50,000 all the way to $2 million and access to traditional and patient capital. So in social equity franchising, every table funds the build out or constructions of stores through our philanthropic partnerships. Thank you for you being the first to step forward and support that. And we've had several several going into these couple years and then offering non capitalized but highly talented entrepreneurs like D, who you're going to hear from later on, comprehensive training, coaching and mentorship through every table university, which is the training portion of the social equity franchise program. So we're really excited about the impact that it's going to make. So I mean, personally, I used to be an entrepreneur at one point, I had dreams in opening a restaurant and went forth and tried to do that and was unsuccessful in obtaining or having access to traditional bank capital. I've had I had about 15 years of experience at that time in the restaurant business and operations. And I went to probably about 10 banks and then also talked to the SBA and was when I was unable to get along. So I've experienced it firsthand. It ended up where I had to open a catering company. Instead, I didn't have access to generational wealth. So I was able to get a small amount of money from from my father to start the catering company. But I was always under capitalized and always looking to get access to capital. The other part that really excites me is that as you see, Maria here, who's one of our candidates candidates, she's been a manager with every table for a few years. But she comes from a background where she had a family of 10. Her father is an entrepreneur, actually. And so she's seen it firsthand. She started working when she was eight years old. And she's always had this dream of being an owner, but never thought that it would be attainable. So that's one of the things that drives me is that being able to make her vision and these vision come to pass. And so where we are today, I'm excited to share that at the end of July, end of July, excuse me, we welcome our first seven candidates, amazing, driven, hardworking folks. Four of them are internal employees. And you'll hear from D later on. She's been with every table almost four or five years as a store manager. And then the other three are external. And so all seven of them have started their leadership, bi-weekly leadership development classes and sessions with me. They're also getting ready to start at the end of the month, our leadership coursework, communication class, which is a part of our leadership coursework. And then the three that are external, I'm excited to say, they've made it through the first stage, which is management training. And they are now managing stores. And so that's going to be a part of their training throughout the process. And so we're really excited to see them become franchisees one day. Thank you. And I'll kick it back to you, Susan. Great. Thank you so much, Bryce and Sam. And now I'd like to bring in D to the conversation. D, you've been managing the store incompetent for the last few years. It's been one of the most successful stores in the company. And then in the very near future, it sounds like the store could be owned and operated by you as well. And just to give the audience a bit of context here, as Bryce mentioned, you know, to own a franchise in the conventional marketplace, it typically it's very cost prohibitive for most entrepreneurs and it needs usually $500,000 to a million dollars of startup costs. And D, you have the business acumen and the lived experience as a senior manager at at Carl's Jr. for I understand 25 years or so. So can you can you share with us a bit more about your background and your experience with every table and perhaps what some of the barriers are that you faced up to this point and really giving us a sense of your vision for the future. Hi, Susie. Thank you. Yes. So I have been in the quick service restaurant industry for over 30 years and 25 years at least have been managing and operating at Carl's Jr.'s restaurant. I have managed multiple locations here in Southern California, managing anywhere from 30 to 40 people, both back in front of the house. Coming with my experience coming over transitioning over to every table has been like a breath of fresh air with coming in with the ease of running this quick and grab boat motto. It has been both rewarded in rewarding and welcoming to me. And the other thing I wanted to point out is that you got to love our mission is to bring and make accessible the fresh affordable food to everyone everywhere. And you got to love that model and that mission. And then just speak to you ask me about the barriers that I had or that I faced up to this point. Should I go on talking about the barriers? That would be great. Yep. Thank you, Susie. Okay, so I can come up with a couple of the barriers that I think I faced up to this point that comes to mind is one is being capital. And then the second one that I will speak to is being the staffing requirements are needed. And this is reflected back at my time with Carl's Jr.'s. One is speaking to the capital. With the capital, we didn't have any programs such as, so to speak, a Carl's Jr.'s university or social equity program. And no one from upper management ever offered me an opportunity to actually own my own franchise restaurant. Or did I even have did I have the funds to manage my own stores? So would that be instead the senior management at that time with Carl's Jr.'s was the only opportunity I see my growth being stopped at. So the other second point is what I wanted to bring up is the staffing requirements or the staffing levels. It was a little bit more complex over at Carl's Jr.'s. And I'll give you a kind of an example of what I'm talking about. Would running a Carl's Jr.'s, let's say the lunch service, you need it anywhere from eight to 10 staff members. And that to run a successful lunch service for that time, for the restaurant at that time. But the challenges of keeping a staff requirement up, having that level, being able to run, you needed to have the 20 to 30 people as a whole was very challenging. And it was always a lot of hiring required, a lot of training required. So that was a lot of challenges or some of the challenges that I faced for staffing. And then what I would like to say transitioning, transitioning over to every table, that is scaled way down where you only really for a lunch service really need two people. And you can see where all this brightness and calls go down when you're operating a quick revenue every table unit. Great. Thank you so much, Dee. And just wanted to let the audience know that the Dee is actually joining us from the store. And she's taking a break from her management responsibilities to have this conversation. So she's actually in an every table store right now. So you can see a little bit of that in the background. And maybe to close out your story here, what can you share with the audience about your vision for the future in terms of your role and what you envision going forward? Well, thank you, Susie again.  I don't think I've seen that vision when I came in. However, I did love this whole concept of every table. And I love everything that we are about. But looking to venture, I'm looking just to continue on the journey and get into making those steps and get into my first store to operate and just serving my community this delicious and healthy meal that we have here every table. Great. Thank you. Maybe turning it back to Sam and Bryce. Now, what would you say is important for investors, philanthropists and other industry actors to understand about the importance of embedding racial equity into your strategy and how it can be a game changer? Maybe we'll start with Sam with you and how you thought through embedding this as you started the business and perhaps how has it supported your vision going forward? Yeah. And I think the way I would answer that is our company was really built on principles of racial equity. And I think the way we approach racial equity is this idea of inclusivity. And can we have a world that works for everyone and includes everyone? And I think that sort of idea of inclusivity has actually become incredibly powerful for both our company as well as our investors in our access to capital. And so, I'm a guy that comes from a white Ivy League hedge fund background, which is about as sort of white privileges you can get. But I bring a lot to the table sort of with that background. And you know, Bryce is an incredible operator with a tremendous nonprofit background. And Dee herself is, you know, basically the best store manager in Los Angeles. And so, you know, I think it's this idea of sort of, you know, not having an us against them mentality, but all joining together in a singular mission. And I think what's really powerful for every table is, you know, that that is true with our investors as well. So we, you know, we have this incredible market opportunity to really, you know, basically make, you know, the next healthy fast food brand bigger than McDonald's. And so we have investors that are pure venture capitalists. But we also have a lot of impact investors. And we have a lot of foundations who see that we can, you know, that we have the potential to make a more just and equitable world. And so, you know, I think the good news about sort of embedding, you know, racial equity is that, you know, while there are some sort of crazies out there, there's a lot of people that really agree with this mission and from all over the spectrum. And so once you sort of are overt and forward about that as the core of your company, you know, support for that comes from, you know, places you couldn't even imagine. Thank you, Sam. And Bryce, did you want to add to that in terms of your experience as an entrepreneur yourself and just that how perhaps every table's racial equity lens has really perhaps been different or any surprises and any perhaps any challenges that the company has encountered in trying this bold vision of embedding this into both its values and operations and everything that you all do? Yeah, thanks, Susie. I'd like to start with the first part of what you asked about what would I what would we ask philanthropists and, you know, investors, et cetera to really think about it and starting with a quote, but Dr. King says, you know, life's most persistent and urgent question is what are we doing for others? So it's in that spirit that my ask to everyone would be to reflect on the urgency and the cause the last 16 months ago for social change, right? And in this country and across the world. And for those folks who have the means to continue to be steadfast, to be courageous and really be bold on the investments that they would make into a racial equity. It's it's a marathon. It's not a sprint. And so my thing is that that's not forget where we were last year. And we knew a lot of us knew that these were issues that happened that were happening and have been happening for generations and decades. And so let's take that energy. Let's not run out of energy, I would say. And let's continue to be bold and making these investments towards racial equity and investments in the world that we want to see. So that would that's what I would say. And I think on the teller that the challenge is, is like I said, a lot of times, because it is hard work, and it takes time to really see change. Some people run out of, you know, to use that, use the example of a marathon. Some people run out of energy at the 12 month mark, 12 mile mark, shall I say. And so we got we can't keep going back to we don't want to go back there. We want to see those strides, but it's going to take every one of us. And so those folks, like you said, the players that have the means to access the capital, the resources, information and knowledge, I would just say, Hey, continue making those investments, and let's make this world a better place for the generations to come. Thank you, Bryce. In terms of, I think a lot of us, and certainly the audience here is really clear around the moral imperative of embedding racial equity into into businesses. And but then there are those around kind of more tangential to the conversation, you know, who are wondering, you know, is there a business case or what, perhaps what elements of having such a strategy might inform or enhance the business model and and actually drive return financial returns, in addition to social justice. So would love to hear, would love to hear from me, Sam, you can start us off just around some of the elements of your racial equity approach that might again influence positive business outcomes.  And what I mean is there's sort of three legs to the social equity franchise partnership. There's the foundations who provide this capital in the form of grants and program related investments. And I do think that we offer value to them for, you know, true systems level change on some of the issues that are most important to them. And then for D, there is the ability to own her own business. And so there's incredible sort of economic benefit there. But for the company, every table, there's plenty of benefits as well as specifically, you know, it's the idea is that, you know, ownership and capitalism does harness this, this deep desire and drive. And so, you know, our belief is that our stores will be better run and more successful with owner operators as opposed to hourly workers. And also, you know, we get to grow our store footprint in our brand through the help of capital from our foundation partners. And in general, I think that customers, you know, and this is customers everywhere, you know, Compton and Santa Monica and Pacific Palisades are really looking to support companies that are making positive change in the world. And so we get sort of a brand benefit from it as well. So I think that, you know, there's a tremendous amount of value. And in my view, it's sort of equivalently shared between those parties, which is I think makes for a perfect partnership. Great. Thank you. And Bryce, did you, Bryce or Dee, do you have anything to add in terms of being, you know, running, running, running the business and being day to day in running the store? Any, any additional points that you wanted to add to what Sam outlined? I'll see if Dee has something I have points, but I want to make sure that she's able to, to share if she, if she has something she wants to say. Well, um, well, the experience has been for me, like over the last three years, that not only, you know, being able to operate your own store and franchise, but there's a need for what we're doing here. I mean, there's definitely a need in our communities that don't have these accessible, healthier meals in their neighborhood. And I get day on and day out. I see that my guests have face to face every day that faces a lot of health challenges or wanting to eat better, you know, maybe lose some weight.  And just to be afforded to have, to be able to operate my own restaurant someday, it's just a privilege, you know, something that I, you know, didn't see prior coming here, but I was directed here, I believe, for that reason.  Great. Thank you. Bryce, did you want to chime in? You mentioned you had a couple of thoughts. Yeah, I'll just share one. From a business perspective, like Dee said, particularly in underserved communities, there's a huge need and market and so many people have ignored it. And so business wise, it makes sense from a, if you look at the country and you look at the exorbitant healthcare costs that we have, it's also, and I can also, we can also make a point that we really need to be visionary and bold around making investments on a preventative end. And so what we offer every table, not only as Dee and we talked about from an economic social equity standpoint, but if you think about our food and what it does and what Dee says, the stories that she hears from customers and the impact that it has on people individually health wise and how we can ripple that effect. Our vision is Sam talked about 30,000 stores. I mean, that's the business case right there, that you're going to eliminate, be a part of eliminating some of those healthcare costs and then also economically putting people in the space where they're economically mobile, have ownership and then creating generational wealth that they can share with their families and then the community at large. And so I would just close with that. Great. Thank you so much. And any, in closing, and we've got a couple of minutes left here, any closing thoughts around perhaps an action or a tactic or an approach that you might recommend others think about? Perhaps it's something you have embedded within the every table business model that has really helped amplify your approach to achieving racial equities or something that a closing thought that you might want to share with our audience, something for them to take away? I mean, I can take a stab at that, but I think what I would say is like there's a lot of reasons that food deserts and food inequality exists. And every table, I do believe has, you know, frankly, you know, the best or the only sort of answer to that on massive scale in the country. And the thing about it is that it requires, you know, scale and investment to get there. And so that's what I would, I would sort of echo what Bryce said, which is like, be bold, because we've got, you know, a vision sort of in front of us for a more just and equitable food system that makes healthy food affordable and accessible to everyone everywhere and empowers tens of thousands of entrepreneurs to own their own business. And so, you know, and it's really thanks to the foresight of people like Acumen, people like Kellogg Foundation very early on, who really saw that vision and decided to back it up with capital, even, you know, amidst a philanthropic world that had historically been really binary between, you know, nonprofits are good and for profits are bad. And so we do think the world is changing in a really important way. And that combination of for profit and foundation capital is really, I think, what's needed to really change the world in a way that is possible and within reach. Great. Thank you, Sam. That's a great way to close us out. So just in summary, thank you panelists really appreciate your insights, Dee and Bryce and Sam. And in closing, just wanted to recap that every table really does embody a dedicated commitment to racial equity, health and economic justice. And as you've heard, their franchising model is radical. It's forging a new path for innovative and equitable financing that we can all learn from and support in different ways. So we hope that this conversation has provided an urgent call for more actionable investments in entrepreneurs and communities of color. And again, we really appreciate everyone's participation to stay up to date and learn more about every table social equity franchise model you can visit their website at everytable.com backslash university and really wanted to thank everyone for joining us today. And hope you all enjoy the rest of the virtual convening. Thank you.