Hello everyone. Myself Prithviraj Thambe working as an assistant professor in Department of Electronics Engineering at Vulture Institute of Technology, Solapool. Let us today learn one interfacing example for LPC176 at my controller. So at the end of this session, students will be able to write a simple program to interface GPIO devices like LEDs and switches, outline. So GPIO port pins are available through 5 General Purpose Bidational Digital IOPorts, port 0 to port 4, which you can use for interfacing General Purpose IO devices like LEDs, switches, relays, like devices. So let us review the registers, which we will require for writing a simple interfacing program. So from pin connect block, we may require pin function selector register, which controls the function of each port pin. Also for GPIO, we may require fast IO direction selection register, fast IO mass register, fast IO set register, fast IO clear register and fast IO pin register. So let us design this small example. So let us interface a LED and a switch to LPC176 at port pins P0.4 and P0.5 respectively as shown below. So this LED is connected through this small register to P0.4 in pull-down fashion and this switch is connected to P0.5. So let us write a C program to turn LED off when the switch is pressed and turn LED on when switch is released. So look at this switch. So by default P0.5 is connected to ground. So if you read the status of P0.5, by default it will read as a zero. So when the switch is pressed, then P0.5 is connected to 3.3 volt and when you read the status of P0.5, it will read as a logic high. So let us first configure P0.4 and P0.5 for GPIO functionality. So we require pin cell zero register. Let us calculate the hex value for pin cell zero, which configures P0.4 and P0.5 as a GPIO pin. So this pin cell zero is third-bit register. So we are interested in P0.4 and P0.5, that is why we are going to make these two pins GPIO pins by writing 00 in the particular bit of pin cell zero register. So bit 8, 9, 10 and 11 are responsible for this. So applying mask and then ordering the desired function, we will achieve this. So the value we will get is 0xfffff0ff. So this statement configures these two pins for GPIO functionality. Next set the direction of these two port pins. Now here LED is connected to P0.4, LED is the output device. So we should connect P0.4 as output and a switch is connected to P0.5. So P0.5 should be configured for input. So let us calculate these two values which configures these two pins for the desired direction. So if you write hex value, you will get the hex value for the direction as 0xfffffdf. So this statement selects the direction of P0.5 as an input and the second statement, the ordering statement selects the direction of P0.4 as an output. Now let us write the values for fast IO set register and fast IO clear register. So here if you make P0.4 high, then this LED will turn on. If you make P0.4 low, then LED will turn off. So fast IO set register is used to turn this LED on and fast IO clear register is used to turn LED off because this LED is connected in pull down fashion. So let us calculate the values for IO set and IO clear register. So after writing 32 bit format for IO set register, you will get 0x10 value for both IO set and IO clear register. So these two statements turns this LED on and off. Now how to read the status of switch? So as we mentioned before, by default P0.5 will be read as a 0. But when this switch is pressed, this status of P0.5 will change to high. So how to read the status of P0.5? So we have fast IO pin value register. So this pin value register you can use for reading the status of any port pin. So this statement fast IO pin ended with 0x20 will read the status of P0.5. So suppose the switch is open, then P0.5 is connected to ground through this R2 register. Then the result of this statement is 0. So you can use this 0 in if statement or for making decision. If you press this switch, then this P0.5 will be connected to 3.3 which is logic high. Then the result of this statement will be a non-zero value. Again you can use this for making the decision. So this ending is here used to make the decision whether this pin is whether this switch is pressed or not. So this is the program and these are the values we already calculated. So first statement is the include. So hash include LPC17xx.h includes the definitions of all these registers int main is our entry point of the program. So this first statement configures the function of P0.4 and P0.5 for a GPI functionality. First IODR register ended with 0xFFTF configures P0.5 as input. First IODR register odd with 0x10 configures P0.4 as output. Now here we have implemented our logic. So this is an infinite loop while 1. So this first statement checks the status of P0.5 whether the switch is pressed or not. So by default this switch is not pressed. So this fast IO pin ended with 0x20 returns 0. So this is a false condition. So not of a false becomes true and fast IO set is equal to 0x0010 will execute. So this statement will execute which turns the LAD on. Now suppose when this switch is pressed this condition will become true not of true which is false. So the else part will execute. So in else part we have fast IO clear statement. So this statement will turn off this LAD. So this is how you can interface a simple switch and LAD like input output devices to LPC176 at my controller. The values of registers can be calculated by referring the datasheets of LPC176 set and by referring the specifications of these LEDs and switches. References. Thank you.


I'll kick off by showing you an example of what agile shouldn't be and this was an advertisement that was made a number of years back. Can we have some kids? Some people like to climb mountains. I like to build planes in the air. Good afternoon folks. Thank you for coming along. It is the session after lunch so nobody had carbohydrates, right? You all had salad and nothing else. You're going to stay awake. And of course nobody had anything with Katie and then Linda will tell us that is a bad thing. Yeah, but they had this lovely coffee ice cream. Okay, product ownership is a team sport. I suppose I should do this. This is me. I work in that place. I'm a full time trainer, teacher, coach. I'm part of that organization. I've got all sorts of things there. I do a lot of stuff at InfoQ. I'm a Kiwi. I'm from New Zealand. But the thing that I think defines me most at the moment, I've got six grandkids and they are beautiful and they're the youngest and they're the oldest and all of those in between. I've done my bit for the global population. The population explosion. I have five children and six grandkids. And I think those are the things that actually do define us. It's not what we've worked on and where we've worked and so forth. It's the things that come after us. But moving away from the philosophy I suppose, getting into the content of the talk. Now I've just made the man with the camera's life, but you're talking as I walk down off the stage. Because it's just wrong standing up there and looking down, looming over you. Product ownership. It's broken. Product ownership as defined by many of the agile brands and practices does not work. That's the premise. And I believe that it truly is a team sport. So in the principle of any good speaker, you're going to tell them what you're going to tell them and then you're going to tell them what you're told them. Well, this is our structure. We're going to talk about the role of the product owner and I'm going to put my hypothesis. Why it's broken? What can we do about it? Talk about it as a team and putting value first. That should take us up until the break. And then when we come back after the break, I want to switch modes and we'll look at some tools and techniques to help us put value first. One of the challenges that I find in projects is we get so bogged down in features that we don't actually focus effectively on value. So that's the plan. Now, we're at an agile conference. We know that no plan ever actually goes to plan. So we'll see how things go. Here's a definition from the Scrum Guide, the definitive reference, all 16 pages of it. This is the product owner role responsible for maximising the value of the product and the work of the development team. How this is done may vary widely across organisations, front teams and individuals. That's a good thing. The product owner is the sole person responsible for managing the product backlog. Failure does not work. I told you you were going to talk to each other. Please turn around and challenge my promise or agree with my promise. 10 minute conversation, actually probably 7 minutes. Because we are slightly time-compressed. 7 minutes on your table. What are the problems or benefits that you have found in the product owner role from your experience? Well, there's certainly a lot of conversations going on. What were some of the problems, some of the potential issues that you identified? Conflict in the priorities? Lack of team commitment. Product owner that doesn't actually know what the job is. Product owner starting to act like a manager. That is it. I'm the product owner. You've got to do what I tell you. Not being the product owner. The proxy is not available. Not aware of the technical details. Just make it show. The Jean-Luc Picard product owner, make it so. Not available. The team bigger project size team. Yeah. So dealing with growth. The product owner themselves becoming a bottleneck. Another term for the product owner that sometimes used is the single-ringable neck. Isn't that a lovely thing? The source of all blame. Yeah, state code is another term. Multiple product owners. What are some good things about the product owner? One person prioritizing the back lock. Sorry? Do we need a PO?  Problem is there's no one size fits all. There is no single, there is no single solution. And all too often I'm afraid I see the implementation of a framework, which is what's run, which it's the DSD in any of the agile methods. It's not treated as a framework. It's treated as a recipe. Give me two doses of TBD and one dose of behavioral development. And call me in the morning. Yeah, no. One of the chats that we had in the open space earlier on was talking about complexity. And I really enjoyed a session I was at a few years ago where Tom DiMarco got up and spoke. And Tom, for those who haven't come across him, is the author of the co-author of a book called People Where, recently published third edition. I'm going to do a shameless plug. If you have not read it, buy it! Linda, it's going to be right. Tom DiMarco. And he stood up and he said, the reason all of our projects today in the information technology world are so difficult is because the simple problems are more than solved. We don't have simple problems left. Today we're dealing in complex organizations with products that have to integrate across multiple platforms in many different languages using different tool sets, distributed teams, distributed not just around a single time zone, but across, I work on one team where we're 12 people in nine time zones. We have a monthly conversation. I live in New Zealand. It's only at 3 a.m. Not great. But the nature of the work that we're doing is going to be different every time. That's the key thing we need to understand.  And we can't use a single framework. Juneta Andrea came up with the term the Cinderella Project. She wrote an article about 2005, 2006. If you are in the Cinderella Project, then the product owner role as defined works beautifully. The Cinderella Project is a small co-locator team, 64 or less, working with clear business outcomes, probably using web-based technologies. There is the short duration, absolute clarity of product vision. We know where we're going. If you're in that space, then the product owner who is the source of all knowledge, the fountain of decision-making, works wonderfully. When was the last time you worked on the Cinderella Project? Has anyone worked on the Cinderella Projects in the last decade? I did. 1987. It was fun. It was beautiful. And it worked wonderfully. Yeah, that's more like what you feel like today. And in that space, the single wringable neck quality, the single decision-maker, doesn't work. There's too much going on for a single individual older man to understand all of the ramifications of the architectural complexity that customer demand, the changing business needs, the staff turnover within the organization. And by the way, you just got to keep that backlog coming. And the backlog probably consists of, what, 2,000 items? And you've got to know the relationship between every one of those 2,000 items. Yeah, you know, Dunbar's rule, Dunbar's number says there's 150 things you can keep relationships with. And that's about people, you know, things. But that's what we try and do to our product owners. What we try and do to our teams. One of the things that we need to consider when we establish an initiative, when we establish a team, is understand what the element of complexity are that are driving our project. And that's one of the hardest things to do. It's difficult to figure out where we sit. And there are some tools out there, and this is one that's coming from Philippe Christian. It's called the octopus model. Octopus means there are eight tentacles on this model. He says that at the very, very least, you need to consider these eight things. When you're thinking about the makeup of your team, the selection of your process, the tools, the technologies, the techniques, the way that you are going to work. And these things will have a significant impact. Size.   I do not want to get bogged down in counting function points or story points or anything else. But we intrinsically know the difference. If this is going to take 200% team or 10%, by the way, 200% is not a team. It is a collection of war and tribes. The level of criticality. How much do we care if something goes wrong with this thing? Do we kill lots of people all at once? We talk about software that kills. Air traffic control systems. We kill whole planes at once. Missile guidance systems. We kill the wrong people. Vehicle management systems. We kill families one at a time. If you're building software in that level, then I want to have a high degree of confidence in your quality processes. And I don't want you to release it until you convince me to my absolute, absolute confidence that it is safe. On the other hand, if you're building software to make lunch bookings for the team internally in the organization, and we order one pizza too many every three months, what can it be so fast? Understand where you sit in that second dimension. What's your business model? Are you building software to support an organization? Or are you building software that is your business? You're selling this as a product? You're going to have different approaches to the work you do. How stable is your architecture? Is this something where we know where we are going? Where the framework is solid? Or are we learning as we go? How distributed is your team? If you've got a thousand people spread across 13 time zones, as one of my colleagues worked on a project like that, with the European Air Traffic Control System redevelopment, you cannot have a daily stand-up with a thousand people. Now, I was amazed last week, Richard had told us about having a 60-person daily stand-up and they finished in 13 minutes. I mean, low innovations. It blew me away because I've never seen that anywhere else, if they achieve it. What's your governance model? That was one of the other things we were talking about next door earlier on. What do you need to do to feed the bureaucratic monster? Every organisation has a bureaucratic monster. It's sitting in the background somewhere and if you do not feed it, it will feed on you. Now, sometimes that bureaucratic monster is there because there are legal needs. You're in a highly regulated industry. Well, okay. Find out what the regulators need and then make sure you deliver it. I worked on one project where we were doing simple things. It really was. We were drawing a graph on a screen and then we printed the graph and put some boilerplate text with it. What we were drawing, however, was the release rate of the active ingredient of drugs. When you register a new pharmaceutical product, you have to register the release profile. So if you've got a rapid paracetamol drug, the release profile looks like that, 20 minutes, 100%. On the other hand, a slow release morphine must do 5% an hour for 20 hours. If you get those things the wrong way around, people die. In the case of the morphine, they die happy, but still not something you want to happen. Now, we were building this product to sell it to the pharmaceutical industry. That was our business model. We'd partnered with people that made scientific equipment, high-pressure liquid chromatographs and ultraviolet spectrophicometers. It was cool playing with those scientific instruments. The office looked like a lab for a while. Think CSI. But I could not turn around to the Medicines Control Council, the registration body, and say, we're doing agile.  Well, they would have just said, no problem. You can't sell your product. Your whole business model has just been destroyed. So in order to prove compliance, we had to produce 1,000 pages of compliance documentation. That was necessary to be allowed to sell in that government model. Another thing you need to consider is the rate of change. Some environs are fairly stable if you're working in the human resources department. Yeah. There's just something wrong with that term, human resource. A resource is something that's consumed in the production of a product. Yeah. Yeah, we put them into a grinder and the other one that worries me are people around greatest asset. Where I live, slavery was abolished a long time ago. I suspect it's the same here. And one hopes so. The only person I might be an asset to is my wife, and I suspect it's more reliability. But if you're in the talent management area of the business, it's likely that your business process is going to be relatively stable. On the other hand, if you're in the sales and marketing area of a telecommunications organization, the lifespan of a typical product is seven days. You need a development process that enables you to get back to market incredibly quickly. And they've got that. Those are sort of the two experiments. And the other one, the age of the system. If you're working on a 30 year old COBOL mainframe system, or like I did 1982, I'm a newly minted program. Now, weird things they do. You take your most junior people. What do you do? You put them on most critical systems as maintenance programs. Newly minted assembler program are working on mainframe systems. And we had to find a bug. Now, the nice thing about assembler code is it's got date and time stamps next to it. When we found the bug, it was date stamp 1964. It'd been a long way of waiting just for me for 18 years. That system, very, very different to the latest hard loop and, I don't know, what's the newest language. So what you want to think about when you're starting up an initiative is what are those elements? And these eight are useful. It's a helpful model. But we know that it's just a model. They're going to be other things than a specific that are unique to your organization. And you need to figure out what those are. So product ownership encompasses a whole lot of stuff. Product ownership is hard. There's a lot of things. It's about product management. It's understanding marketing. It's about business advocacy, customer advocacy and end user advocacy. Those are different stakeholder communities. Oh, I must admit again, I don't like the term end user. The only other domain where we talk about users, drug addiction. And the really perturbing thing for me with many technologists is when I talk about the users. You can hear the sneer in their voice. Our users. And then we build books, databases, places for dummies. And we give it to our users. This is just wrong. These are our customers. These are the reason we exist. These are the people that pay money for our products. We should be treating them with a lot more respect than just calling them users. We need demand, subject matter knowledge. We need analysis skills. We need to understand things like user experience, interaction and design. We want our product owners to be innovative. We want them to be good communicators. We want them to be able to make decisions and to make trade-offs. And oh, by the way, they have to know what the law is so that we don't release something that gets us into trouble. Now, who in the room has got a job type of product owner? Good luck! How do you achieve that? You don't. It blows your mind apart completely, which is why I firmly feel that product ownership is a team sport. You need a supporting team and I want to change your role name to value facilitator. You're not the owner, but you are the facilitator of bringing the right value out. We need delivery expertise and an interface too. We need project management, governance, analysis, subject matter expertise, user experience, graphic. Other roles that should be in there is interfaces to the support team, to the infrastructure team, the people that tell us what our customers are saying about our products. You want feedback? Go and sit next to your support team. Watch the call center after you do a new release and call volume spike. Yeah, that's not good. But you need that role, that facilitation, as that is hugely important. And yes, sometimes there will be an arbitration component to that as well. You need to be in a position to make decisions, to help guide the decision making, but you've got to look at that bigger picture. And I truly do not believe this can be done by a single individual on anything except the simplest of products, the Cinderella project. For everything else, you need a support team that makes this. And just to balance that out, we also need a delivery team, technical teams. Now, in relatively small initiatives, we're going to see a lot of overlap. These are not job titles or roles, skill sets that we need. And we need that interface and those commonalities on those roles as well. Bringing the voice of the customer. And then all of the technical stuff. It could be in a relatively small group, but this is a single team that's small enough. Because once you get above about nine people, team structure starts breaking apart. So then I want complementary and overlapping. Generalizing specialists, bringing all sorts of other skills into the team. So, do we need a specialist DBA? Well, I'd rather have people within the team with the DBA skills. For instance, do we need specialist performance testers? I'd rather that people within the team were able to do that cross-functionally. So you're generalizing specialist, lovely word, or the T-shaped skills. So again, turning it around on you. Things have a conversation again in your group. Does this resonate? Does this make sense? Could you apply some of this thinking in your organization? That does mean talk to each other. Speaking of this, do you have a talk with the same person? Yes, this is not a talk with the same person. We need the same person to do that. So let's take a look at this as the one and the other. I still think that, what I was trying to say, I think there's something that's not right here. Any thoughts, anything you'd like to share? Am I being an idiot? To involve the product owner and the team as much as possible? Yeah, make them part of the team. So record feedback, lots of interaction, involve, engage, which is really hard if you're looking off to five teams. We talked about using the burden of product owners and offloading them and distributing certain stuff, for example, story writing workshop, clothing and all that. Share the load. I think I've understood the word. The word product owner is a owner. Somebody seems to elevate this person in a different way. Yeah. Knowing you're only a few, we promise that you will talk about it in the biggest sense. You know, single-deck to squeeze in and then product. The specific order of the word is coming from the same response to this, but specificization makes it a little more of a product. Makes you believe that the product owner is part of your team. It's collaborative. There's the best product owners I know, the ones who take that mindset. They are collaborators by nature. So how can we help our product owners? People in this role. One of the things that I think we do really badly is have a background of 2,000 items. That's just wrong. We can envisage a 2,000-item list with all its dependencies. And all that becomes is just a whopping, great, big cube. So we need to change the shape of our backlog. I used to do a recent amount of work with the mining industry. And if you think of diamond mining in particular, in the underground diamond mines, I'm thinking of you, Kimberley in South Africa, they would take these big rocks out of the ground and they'd grind them down and grind them down and grind them down. And eventually what comes out of the bottom are the diamonds, are the gems. That's what our backlog should look like. Things that are close, we need to have ground down to the point where ideally we don't even have to worry about how big is this. It's just a standard unit of work size. One story point if we're going to use story points. And pretty much everything at that level is the same size. So now estimation for the next iteration is really easy. Don't bother with sizing. So they should come out at the level of the gems. The further you are away, however, the less of that granularity and detail you need. One of the things that you do have to do though is have the big picture in mind. This is the anti-pattern to this one is we'll only focus on the next one or two iterations. We won't think about anything at all in the future. And the danger there is we don't think about what, again for the Christian, calls the architecturally significant non-functional requirements. Isn't that a beautiful one? The things that are very, very expensive to re-hack. Performance, maintainability, stuff like that. Things that we know are coming. So that's why I want your backlog to look like that. And again, to use a real world example, I worked with the team and we were building an internet banking system. This was shortly before smartphones came out. And we had our backlog that was the stuff that we knew was going to be worked on over about the next four months. So as an internet banking customer, I want to log in securely so I can manage my own money. I want to list my account balances, those sort of things. And they, so most of our backlog was at that size and we were grinding it away in the little bits. But there was one that was sitting up there and we left it there for a long time. It was a story that went as an internet banking customer, I want to bank using my mobile phone so that I'm not restricted to using the computer. It was a big chunk. For us, it was a reminder to think about integration. We were not going to build anything for it at this point, but when we, for instance, chose our technology framework, our technical stack, we made sure that we had as part of that stack the ability to integrate with, and we knew that the state of the art of that stage was SMS, so we needed to be able to integrate through an SMS gateway. We didn't know which SMS gateway we were going to use, but we made decisions that would enable us to integrate with one at the time when we needed it. So knowing it was there was important. About six months into the project, we've got enough done that we were able to take that one and start dropping it down through the grinder and it ended up with about 35 stories. And what we actually implemented was a very, very simple registration process and your cell phone, and list balances and transfer funds using text message. That's what we implemented that stage. Today it's got the full, rich functionality of native apps for all three of the mobile platforms, but that text-pating bit is still in place and still working. So knowing what's coming is important, and typically how far away, and how far away each of those chunks is, that depends on, again, the context of your project and your organisation. Another thing we do really badly is track value delivered. We're really good at tracking velocity. We can count stuff. We give it a point of some sort, and then we plot it on a graph, and that's that orange line. It looks cool. The thing that I think we do incredibly badly is track the value that we have delivered. Now, it's hard to equate value to an individual user story, but we can certainly group value components around the user task element at the very, very least. And we should be doing that. And there are techniques such as biofeature and so forth, games that you can play that help to actually allocate that value. And this is something that I do hope and expect that the value facilitated that, is they define the value. Because without that, the only metric we've got is velocity. And my experience is, if we've got velocity, then we will carry on delivering for that velocity line. We will meet that target. It becomes a target, and we will carry on down that path. Whereas if we've got a value metric, value almost always looks like a bit of an S curve. The first few iterations are not, we may be doing the thin slice. We can show it. We can get feedback. We're mitigating some risks and so forth. But really, we're not delivering true customer value, but we have to have this stuff. Then we hit the point where we probably have our first MVP, a minimum viable product, something that we can actually, with confidence, take out to at least a subset of our customer base and people will pay us money for it. At that point, we see a fairly rapid ramp up in the value and we're now going through, if we think about prioritize backlog, probably we're getting most of the must haves and a fair number of the should haves. And it's looking good. And then we start to flatten it out. The y-axis is either velocity points and one is velocity and the other one is value. And I've deliberately not put numbers on. It's the shape. One of the things with velocity, never count the numbers just look at the shape. And value pretty much the same. What's the shape look like? With value, however, we see it flattening out. At some point, we're probably going to reach the stage where the incremental cost of the next iteration is less than the additional value that this iteration will give us in the marketplace. Well, if I don't have a way of equating value, I'm going to continue to be. Because our plan said we're going to have 12 iterations, we will deliver 12 iterations and the iteration cost us exactly $100,000. And this is a $1.2 million project and we've got a budget. And we're going to spend the budget. If I can monitor the value, well, we can stop after 7 iterations and save the organization of fortune. Release that team to work on things that are going to bring us more value in the future. The other conversation can have if we discover that we've got a new y-axis that comes into the backlog, and by the way, that is going to make this line go there, even though we're towards the end of the budget. It becomes an easy conversation. Well, if we spend this extra $120,000 over the next three weeks, we will bring in a feature that our customers have called us, there are nothing that they're going to buy, but with this we'll generate another $2.4 million profit in the next 12 months. Guess what? Please do it. It becomes a really, really simple set of conversations. But if we do not start putting value into our backlog, and I'm not saying this is easy, this is in fact an extremely hard thing to do, to define the value metrics. But there are techniques, and the one I like the most that I've worked with is the very, very simple buy a feature. We give people a bucket of monopoly money and we put the key chunks in the backlog and say, okay, which one of these you prepared to pay for? And then we see how much they prepared to pay of their monopoly money, and there's a limited quantity of monopoly money, and something that nobody puts money on doesn't get built, even if it is the CEO's pet feature. So a very, very quick conversation. Actually, we're over our break time. Five minutes. Cool. Well, we're leading up to the break. How would you tackle putting value into your backlog? A story point is not value, a story point is cost, because they are not that valuable. And how many, Linda reminded me of the sort of statistics and features in products. Somewhere around half of the features in a typical product are never used by real world users. Yeah. That's because we don't do this. We just carry on and carry on and carry on. We've got a budget. We're going to build it. What if we could stop them and not build all that excess baggage? Because really, that's all it is. It's stuff that's a space for more bugs to evolve in. That's not all they do for us with those features that nobody ever uses. We just fester there waiting to explore it. Can we talk about this value? So are we talking about the value to the end user? We're talking about the value that our organization will derive from this. Now, it may be that that is ultimately value to the end user, but there are going to be some things that we will do that we'll do not because of that end user, but because of our organization. So we build in the ability to, we give some stuff away free, and now we have a chargeable piece, a premium service. We may have certain things like reporting or stuff, which may not earn the revenue dollars, but it's still kind of important. I'm going to say that if you can't explain to me the value in business terms of having a report, then why are you doing that report? But if I look at a typical product, there's a whole lot of reports that nobody's ever looked at. There's three out of the 35 that you've built. Build the three and stop. But now you've really, really got to start looking hard at why is this thing on the backlog? Who came up with this idea? What's it for? What is the real value? Every item in the backlog should have a numerical value. And it's, I don't care what your metric is. Philippe Christian talks about utilities as a metric of value. Luke Holman's approach of the buyer feature, where you give people a limited quantity of dollars. Well, you divide those limited quantity of dollars and the amount of people will, of those dollars, people will spend. So it has to be a numerical value. It can't be a relative value. It should be numerical. And this is where it's... It's possible to put numerical value. Yeah, yeah. The one, the technique that I found works the best is we give a total number. This project is worth, let us say, an arbitrary million dollars. Where's your business case? If your business case doesn't have a very, very clear statement of this is why we're building it. It's worth, you know, we're going to spend a million dollars, but we're going to generate five billion dollars of extra profit for the organization from having this thing. If you haven't got a business case like that, why are we spending money? You know, we spend money for one of three reasons. Increase revenue, reduce cost, or avoid cost. If we're not doing it for one of those three things, we are being negligent in our fiduciary duties to the organization. Even a compliance project has value, and it is the value of not being fined. But it can be a relative size, yes, the value. Let's say this is one, two, and a half. Yeah, yeah. So it's going to be relative across the whole thing, but you've got to do is put a boundary around how much you've got. Otherwise, because I would add another one, and another one, and another one, and we get the strike line we don't get, we never actually measure the SQ. The ranking starts us. It's a good starting point. But if I don't have that metric, it's just, you know, this is number 74. So what compared to number 77? Number one versus number 77, sure. Now the marketing team tells us the business value. Yeah, business priority and business value come at the same time. The technical team do not define business value. The technical team define your cost side, the orange one. My experience has been if we don't do that, if we don't have some way of showing that value, and it is just where it is in the list, it's really hard to stop work, because we like how new features are the next feature, and the next feature, and the next feature. They're cool, they're pretty, they're shiny ball balls. The fact that nobody will ever use it doesn't matter. But the product owner, the SME representative that we show, oh it's cool, it's pretty, it's orange, like we show it. Yes, I want one. What's the value of that to the 100,000 customers who are going to download and install this thing? And this is where possibly some of the work that Dave Snowden has been doing in terms of sense making, can we build things into our product that will really give us feedback? We thought this feature was worth how much, how much is it really being used in the wild? For instance, the problem with that is a training metric, but it can help us make better decisions in the future. Do we know, do we have metrics across our products where you can say which of the capabilities or features that are in there are used to what extent by which customers? And if we haven't, then you don't know what the real value is. Because until it's in the hands of real customers, even this is a hypothesis, it's a guess. But I want you to get better at guessing. It's not usable, you know, we have usability issues. So usability is such a wise term, how do you define what you mean by usability? So we picked up 25 things that we thought were issues with usability, and we said, we give you $100, and you can, at a minimum, have to spend $20 on one thing, which means that at the most, you can pick five things from this list that mean the most to you. So you have the choice of five, or you can boil $100 on one, and then we'll pick out what are the most important things, and that's how things that we think. And did you get the satisfaction afterwards, after they'd been released, the customers were happy? Yes, because people went to focus and went to business. And making people spend pseudo-dollars really does help in this. Luke Holman's work on the buy a future game. I would encourage you. It's one of the simplest and best for this. Josh, any? Okay folks, I think you break home 15 minutes when we come back. We'll talk about some tools and techniques to start off in the right direction, anyway. Nobody had coffee? Linda tells us it's bad. Water. Okay, so the first half of the session was putting any context, putting some theory around it. One of the things that I think I see that happen a lot is we start projects badly. And to take knowledge of this, we are really good at solving problems. That's our job, right? Where we like to solve problems. The challenge is more and more often I see that what we do is very, very efficiently solved the wrong problem. We touched on it before the break somewhere in the region of half of the features in a typical product are never used. Now part of that is our traditional requirements approach and I do see a lot of our team still doing a similar thing. We're going up to this community to our customer base and we're saying we know that this project's going to take about a year. Tell us now everything you're ever going to need over the next year. Invisage the future. Here is a crystal ball and what do we get a laundry list of features we turn it into a backlog of stories and what's actually happening in the mind of those customers is a certain level of panic because they know there is no way in hell that they know what they're going to need in a year. So now they do the scatter gun approach. Let me think of every possible thing I could ever want and hopefully somewhere inside there will be a thing that I might actually need this year and we are asked for everything expecting that half of it's going to be descoped anyway. That's the other thing that they used to us doing. This is a funny one I don't care whether you're doing agile or not it happens on almost every project there is a phase that a project gets into it is never on the project plan but it always happens we call it the rapid destocking phase it's shortly before delivery when we realize there's no hope in hell of getting this thing out the door. What do we do? We redefine success to be what it is we've built. So our customers know we're going to do this to them so they give us this laundry list hoping that when we do descope the bits we get that they get left with are the ones that will actually be done. Yet not a great way of running a business. Agile Now this is one of my favorite quotes about why agile matters. Jim Hyslop The number one challenge of agile project management is creating a culture of innovation everything else pales in comparison. Agile projects often attempt to implement the new, the untried and the nearly impossible. This is not a problem domain which controlling tasks to achieve a fixed plan will succeed this is a problem domain that demands the innovative exploration of possibilities the innovative exploration of possibilities. A 2000 item backlog list is not an innovative exploration. It is a queue but that's what we've done. Let's find ways to tackle this. But the other thing we've been very conscious of is there is a big difference between a baby and the bathwater. Do not throw the baby up with the bathwater is the problem. The same. Just because we're doing agile doesn't mean that the good techniques that we've known about for a long long time have gone away. How many times have you heard the term we're doing agile therefore we don't do XYZ. Now what's really scary is often the XYZ is we don't bother testing. We're agile. Not wrong. We test first because we're doing agile. We don't do requirements anymore. We're agile. We just hope and pray that these things will bubble to the surface. There are a lot of tools that have been around that we can actually use. Now some tools, no maybe not so much anymore. Jeff DeLuca talks about 3,000 pages of useless cases. But perhaps a three page succinct use case could be very valuable. Maybe a list of 50 to 100 user stories. If your backlog is getting bigger than that today. So what are a few of the tools that we've used and that we can use? And I'm thinking here early on in your initiative but the inception activities where we want to try and figure out what value is what are our goals and objectives? How do we make sure that we solve the right problem? And value stream mapping is one of the greatest tools for that. A value stream map is a flow chart on steroids. It's a process modeled with numbers. What we're looking for is the opportunities to identify the waste in our process. That means we have to have an end to end view. We've got to look at our process. And I don't want to spend hours and hours and hours modeling it in Vizio or one of the fancy tools. I want to draw it as we had up there on a piece of paper or whiteboard in a collaborative workshop with a group of people who understand and who are part of the process. Ideally with the victims of the process. That's a much better term than the user, isn't it? The victims, the people we will inflict to the process upon a new product. And here's one that we prepared earlier so to speak but to make it a little bit easier here we've turned it into a more graphical image. So this is a business process that is about establishing a new customer. So somebody has come to us as the computer people, the IT department, and said, we have a problem. It takes us too long to set up a new customer in our system. Now if I were purely focused on the technology I would look in here and say, wow, it takes us two hours to do data entry. That's such a waste. I tell you, I've got a tool. There's this fancy new scanning solution and handwriting recognition is so efficient today that we can cut that two hours to 15 minutes. Wouldn't that be efficient? We could save two FTEs. You measure things in FTEs. Oh, my goodness. What is an FTE? But we can save two of them and it's only going to cost about $100,000. It's cheap. If I were purely focused on technology solutions well that would sound cool. But when I look at the end-to-end process I've gone from 180 hours to 178.25. Woo-hoo. My customer, the victim of your process truly doesn't care. And now I need to look at the flow and say, okay, where are the things that we can actually improve? Why does that take 24 hours? What is the delay here? How come that takes so long? I'll give you a real-world example. Something I worked on a number of years back was an organisation that had a problem and it was a business workflow problem. We were going to computerise. It was an insurance company and the business problem was it took six days from the time a claim form came in and the decision was made as to whether or not we should send out an assessor to go and look at the vehicle or the house or the damage or whatever it had. So there was a six-day cycle. This was not good enough. And we were going to implement a standing solution. We were going to automate the whole work business workflow and we were going to spend about $400,000 because this is a major problem for the organisation. But before we did that I did something really foolish. I walked the process from end to end. I pretended I was the piece of paper. In fact, I followed one of the pieces of paper. When it came into the mail room, I was there. And what would happen? Somebody opened the envelope. This was before email, sir. Well, before email was extensively used. Open the envelope, check the form, or put it into a basket. Later on that morning, somebody would come along and take all of these baskets, put them on a trolley and wander around the building and deliver them from desk to desk to desk. The form that I was tracing went into the end basket on somebody's desk. After about five minutes, this person picked it up, spent maybe five, ten minutes looking at it, made a few notes, put it in the out-basket. And there it sat. Now, I literally was walking with the form. So I sat there in this person's office putting my thumbs until the form moved. And later on that afternoon, the mail person came and they picked it up and took it back to the mail room. Now, this person was on the third floor, was now down in the basement because that's where the mail room is. It went into the mail room. It got sorted. Put it into another basket. Stayed there overnight. Came back in this morning, it was still there. Mail person came along, picked up this basket, trundled around the building and now it went to the sixth floor into an inbox. Within about ten minutes, this person picked it up, made some more notes on it, put it in the out-box. And it went back to the person on the third floor. And it did this cycle three times over the six days. Do you know the massive change we've made to that organization? Move those two desks next to each other. By doing that, we reduced the cycle time from six days to an hour and a half. Okay, I didn't get as the IT person to put in my fancy workflow management system then. Three years later we implemented it forward. Solved the right problem. And one of the tools that helps us is the value stream. There are other tools. This is one I'm particularly fond of, the Purpose Alignment Model, from Ken Pickle, the book is called Stand Back and Deliver. And they say, when you're looking at spending money in the organization, you're back consultant, so you've got a four-square grid. You can't be a consultant without a grid. Think about how and what you should be doing. How important is it in terms of mission criticality? And how important is it in terms of market differentiation? Over here, something that's absolutely critical to us in terms of mission criticality, but doesn't make a difference in terms of competitive advantage you're distinguishing us from others. Very clear rule, apply industry standards. Financial accounting is a parity activity for almost every organization. You've got to do your accounts, you've got to do them really, really well, but nobody buys your product because your accounting department is efficient. Down here, industry standards. Please do not spend a million dollars customizing a financial accounting package, implement it out of the box and modify your organization because this process is to manage it. Because really, there is no competitive advantage in doing it. But how many times have we seen, often it's because the finance department controls the budget? We are special in our business. No, you're not. Financial accounting is financial accounting is financial accounting. I'm sorry. Deal with it. Over here, it's very important for us for omitting for mission criticality. It doesn't differentiate us from anyone else. Please don't spend anybody at all. Or if you really have to, find somebody who does it better than you and your partner with it. Outsource to them. Up here, market differentiation important but not high in terms of mission criticality. This is find a partner versus an outsourcer. Find somebody who's really, really good and partner with them in such a way that you are there, that it truly is a partnership. Then, is the stuff in the top right hand corner. This is the things, these are the things we should be spending our organization's money on. These are the things we want to do better than anyone else. We want to excel. We want to innovate. We want to do the exciting. That's what we're going to focus our organization's effort up in that top right hand corner. So when an idea arrives, part of value facilitation is to make sure, one, are we solving the right problem so something like that used to be made. Two, what approach should we take to solving this problem? Where does it fit? We want to make sure that we know the approach. Then, we can start clarifying the outcomes, the goals, the objectives. And there are a number of tools at this level to clarify the intent, the outcome that we are looking for. One I particularly like is the vision box. Bring a group of people together and let them define what this project is in terms of compelling business value terms. Let them identify a name for it. And this group of people, by the way, these are the people who are going to build the product and the people who care about the product's existence. Don't have one group that does this over the wall for the development team because nobody only means that. Bring the people who are going to do the work into this workshop. So give it a title, give it a brand, give it a logo. And really important, define the benefits that we will have from it. And inevitably, when we're building a product, we're going to give to some community of users, victims, customers, clients. Then we need to consider benefits in two levels. There's benefits to us as an organisation and benefits to our customers, the people who will invest in some way in this, whether they are paying for it or not, at the very least they invest their time in using this thing. And there must be a compelling benefit for them to do this. Then we can use tools like the elevator statement to help us express in compelling business terms why this matters. So the one paragraph description expressed in those business value terms. What's the need, who's the customer, we give it a name, we define its category, we explain the key benefit, we differentiate it and what is that differentiation. Having a group of people come up with that sentence forces them to really think about why are we doing this. It's incredibly powerful and then I want that to be the brand, to be the motto of the team. Engrave it upon their souls in letters of fire. This is why we're doing this. There are some more mundane but really powerful tools that we can use at this level as well. This one is hard to read so I will take you through it and it is more visible in the download slide. This comes from a guy called Rob Thompson. Really good book, radical project management. And he says that in the project world today the old iron triangle is not enough. It's not, it doesn't deal with things. We're all familiar with the iron triangle, scope and cost and time and I don't know quality is somewhere in the middle I've never understood how the surface area of a triangle equates to quality. But Thompson says it's not that simple. The reality is there are at least seven elements that you will need to trade off against each other and this is the key thing this is a trade off tool and the rules are that you've got seven items and you have to rank these things in a continuum. No two items can be exactly the same. And it moves from fully off to fully on from fully, totally flexible to completely fixed. And the seven items have satisfied client groups. Meet the project's objectives or requirements as currently defined meets an agreed budget in either resources capital or equipment deliver the product on time add value for the organization meet quality requirements or have a sense of professional satisfaction for the team. Those are the seven factors that you're going to trade off when you look at what matters on this project and hugely important to force a conversation about the trade-offs. Mike Cohn has a version of this as well that's got four sliders and he says you can add others. I actually like to force people to think about all seven at least. And every project will have a different profile a different shape. One of the things that I do when I'm facilitating these workshops is I will print them out I'll print out this tool and I'll give it to everyone in the workshop and say you tick off set the sliders to the level that you think would be right for this project without discussing with anyone else then we stick them up on the wall without names on them. Inevitably the project manager's one has either got time or budget. The product owner and more business value, one of those two. The technical team quality. Because they like to do quality jobs. And now we have to have the real conversation about what actually matters. And this is where we need the business owner, the value facilitator all of that and we come up with a shared understanding. And every initiative will have a different profile and the purpose of this tool is to align us on our decision making later. If you consider that in a software development project you are making hundreds and thousands of small decisions constantly. Write down at the lowest lowest level when I'm writing the code to implement an algorithm I am making decisions. If I know that time to market is the most critical factor on this project because either there's a legal deadline or we know that the competition is launching a competing product then I will make a decision about how I implement that algorithm that enables us to get time to market quicker. I might be consciously incurring some technical debt but that's okay because we know why we are doing it. On the other hand if I'm building the next generation of hard case maker software I certainly hope that quality is the single most important factor and we won't release it unless it is of an adequate quality because we really don't want to kill people even one at a time. But understanding that profile profile is a hugely valuable activity for project teams. It helps us to make good decisions. Then other tools very simple in-out lists topic lists again from Rob Thompson he maintains he's the first person that came up with this and documented it one of the tool one of the elements of the product so these are the big features the capabilities that this product must have and at this level it's okay that we have some undecided stuff because that's going to tell us there are some decisions still to be made. How does this initiative link to our organization strategy and goals is another important question. So that second one is a simple list of the major topic areas, features or capabilities that this product has. In order to achieve this business benefit this is what we need to have. Now these have been the really big rocks in my phone. This is the beginning of the backlog. So all we're looking is that top top layer in that funnel shaped backlog. But here is another part of the why are we doing this the link to strategic objectives mentioned before the break. We do work for one of three reasons increase revenue improve service or avoid cost. IRACIS IRACIS increase revenue avoid cost or improve service those three things. Now seriously folks if you're spending money for something that is not related to those three things then you're wasting the organization's money. And we need to express the benefits that we're going to get in measurable numbers in these two areas. Now this is hard why are we doing this project? What is it going to do for us? Increasing revenue improve service reduce or avoid cost. And it's a tough conversation to have, but honestly if you don't have this conversation then you're going to be in an all over place for this product. There's the proverb, the adage again he goes furthest who knows not whether he goes. So these tools are about creating a guiding light for the team to work for work towards. And then the really hard one the cost benefit analysis what's it worth to us to solve this business problem? We were talking about value earlier on this is where value comes from this is how we divide or these are the numbers we divide to get our value elements across these things we start with. What's really important in the boundaries between the boundaries I've got no idea and this is true for both cost and benefit and it really helps us make good decisions from a project perspective from an organization perspective if we've got an initiative we look at it it's going to cost us at least a million dollars to do it and it could cost as much as five million dollars but we don't know between those numbers where it's going to be those two boundaries we have absolute confidence in if the benefit to the organization is at least 50 million dollars and it could be as much as 150 million dollars just do it don't bother estimating go and start work on the other hand if the cost is somewhere between one and five million dollars and the benefits are somewhere between two and three million dollars don't do it there's a very very strong non-financial compelling reason to do it which is often the avoid cost if we don't do it we will get a fine or branding branding is a very good one so there are reasons, there are non-financial reasons to do things absolutely but we've got to be honest we are going to burn money on this and we're not going to get any direct revenue benefit but there is a value to the organization compliance branding reputation is a really important one so we will do things we'll show that we're good and green and we're saving greenhouse gases and stuff yeah we've got the stamp of approval I'm going to be cynical and say most organizations will only do it because their customers force them to so these tools hard to do simple in concept because you need to force people to tackle the realities I did this as a workshop with a banking organization we were doing a bet the farm initiative they were a small bank or actually they were a savings and loans type institution and they were moving to changing their whole business model to become a bank to become a commercial bank and they realized that their existing platform would not support this new way of working we had a one day workshop where we tackled this and it was one of the most amazing experiences in terms of team cohesion finding outcomes and business benefits and so forth we had a group of 15 odd people in the room a smallish bank the chief operating officer of the bank was the project sponsor they were in the room they had a little bit of free work done and they had chosen a reference architecture and platform going forward they knew which one they probably wanted to use we had a number of tellers from different branches we had a back office manager we had a branch manager we had an international teller and various and one or two other people who represented the customer needs now the primary user or victim of the product were going to be the tellers and we had three tellers who were allocated as the SMEs we had the four developers who were going to be primarily responsible for the coding we had the lead architect we had the project manager we had three business analysts and the three BAs and that organization were also responsible for the testing activity so that was the group of people I was there as the facilitator and we started the morning by getting the project sponsor to stand up and give his vision is it time? 15 minutes oops okay I will wrap up oops okay come and stop okay folks we'll definitely take that one offline I will encourage you think about using these tools set yourselves up to be full and to go back to imagination is more important than knowledge. Innovation, imagination these are the things that make us successful in today's world so in conclusion sorry to reach thank you very much


Does your character ever daydream of being cloud strife? Do they think that great swords are more like just okay swords? Do they ever find themselves waist-deep in slain kobolds with another 30 left to go? Look down at the pitifully normal-sized earthbreaker in their hands and think, man, if this were only big enough for Cthulhu to use, this would all go so much faster! Well, then you're in luck. Because in Pathfinder, there's rules for that. Massive oversized weapons are a staple of popular media, from anime to... I mean, well, it's mostly just anime. But there's definitely something alluring about the idea of hoisting an axe twice as tall as you are and absolutely obliterating anything that gets within casual speaking distance. And Pathfinder gives us a couple of different ways to make that dream a reality. Our first step is to look at how sizing works. Creatures range in size from fine, like locusts, all the way up to colossal, like the Tarask. Player characters are almost always small or medium, but equipment is made to fit creatures of all sizes. Normally, of course, you'd get a weapon that's made to match whatever size you are. But that's not what this video is about, is it? So, let's ask the easy question first. Can we just find and use a bigger weapon? We can, but only up to a certain point. Bigger than usual weapons take more effort to wield. Each time your weapon goes up a size compared to you, it goes one step along the chain of light, one-handed, and two-handed. So, if you pick up a large scimitar as a medium human, it's going to be a two-handed weapon for you. But here's the kicker. If a weapon gets big enough to step past two-handed, you can't use it. It's just straight up not allowed. So, to get bigger than just large, we'll have to look at ways to increase in size magically. When you increase in size, all your stuff does too. So, how big can we make ourselves? To maximize our maximizing, let's look at how magical size increases do and don't stack. Following up on a Vega original rule, Paiso released a route which clarified that there are two categories of size change effects. And while you can gain the stacked benefits of both kinds at once, multiple effects of the same kind do not stack. The first category is for effects that change your actual size, like the spell in large person, which incidentally is exactly the spell we're looking for. One way to gain its benefits that still suits our ragey, smashy needs is the demonic bulk ability you get as a blood rager of the abyssal bloodline. At level four, you grow a size when you rage. How perfect is that? The second category is for what are called effective size changes. Abilities and effects that make weapons do damage as though they were one size larger. One example of this is impact, a special ability that can be added to a magic weapon. It's priced at a plus two bonus, which does make it pricey, but it should be affordable by level six or seven if you plan for it. That, along with enlarge person, has us attacking with a weapon that is effectively huge. But is that big enough? No, of course it's not. To go bigger, let's revisit our first idea of just using a physically larger weapon. We can bypass the restriction we mentioned before with the help of the Titanmaller Barbarian archetype. At level three, a Titanmaller's fittingly named massive weapons ability lets them use a two-handed weapon that's one size category bigger than they are. So if we take four levels in Abyssal Bloodrager, three levels in Titanmaller Barbarian, and put impact on something large and two-handed, we can wield a weapon that does damage like it's gargantuan. So that's pretty cool. But surely you plead, surely there's some way to get that one last step up to colossal, right? And there is, but it's a pretty steep investment. We'll start with three levels in Titanmaller, just like before, but instead of clashing into Bloodrager, we'll get our physical size increased by taking levels in the Goliath Druid archetype. To start, Primal Size gives us enlarged person as a spell we can cast, even if we didn't take the time to prepare it. Then after 14 levels in Goliath Druid, Wild Shape can act like the spell Giant Form 2, which, true to its name, lets us change into a huge giant, bumping everything we have of one last size. And there you have it. You've got a bona fide colossal weapon. Is it a practical build? No, of course it's not. But hey, if you're trying to use a Warhammer fit for Cthulhu, practicality probably wasn't your highest priority anyway. Well, that was entertaining, but I want more. Where can I get more? Tell me! I heard the crew of Doormonster does a bunch of podcasts over at Doormonster Podcasts, which is a separate YouTube channel that has all of their podcasts on them.  I'm gonna take a long carriage ride in the next few weeks, and the podcast is exactly what the doctor ordered.


Welcome to MOOC course on Introduction to Proteogenomics. In the last two lectures, Dr. D. R. Mani provided you the basic information about how to now utilize your data generated to make it much more reliable and statistically amenable for further analysis. So by now you are comfortable in generating data using mass spectrometers, but even you have obtained the very complex data sets for variety of samples, it becomes very crucial that you are really working on the dry data set for analysis, you have done proper build of normalization and now you need to employ the statistical tools for further analysis to find out the most significant hits out of a data. If your aim was to compare a disease versus a healthy individual and you have run in hundreds of patient sample with the individual healthy controls, now your next goal is to find out how many proteins are differentially expressed which are significant from one to other population. In this slide, Dr. Mani's lecture today will focus on different types of a statistical test and its applications in proteomics. So as we all know that any data analysis requires the power of statistics to strengthen the outcome. Some of the important and very common type of tests which are employed for this purpose includes correlation, regression and different comparison strategies. So correlations are a technique which can show whether and how strongly the pairs of variables are related, whereas Pearson correlation is important to test for the strength of the association between two continuous variables. On other hand, the spearman correlation is the test for the association between two ordinal variables that does not rely on the assumption of normal distribution. Then next comes the regression which can estimate if a change in one variable can predict the change in other variables and there are mainly two types of regression test, a simple regression, which test that how the changes in predictor variable can predict the level of change in the outcome variable whereas the multiple regression looks for the test how change in the combination of multiple predictors variable can predict the level of change in the outcome variable. And the test which we often need in comparison of means which actually looks for the difference between the means of variable, parity test it is another important one where it tests for the difference between two related variables, independent tea test on the other hand looks for the differences between two independent variables. Next comes the ANOVA or the analysis of variance this analyzes the difference among group means in the sample but sometimes when data does not meet assumptions required for the parametric test we have to then do non parametric test which means the data is not required to fit a normal distribution. A simple test Wilcoxon signed rank this test used to compare two related samples to assess whether their population mean ranks differ or not two sample test Wilcoxon man Whitney test this test is used to compare the outcomes between two independent groups whose data are not normally distributed some show you appreciate that there are variety of statistical test and options available to compare your data under which context you need to employ which type of test becomes very crucial to understand and that is where today's doctor money lecture is going to give you more detail and examples that in which context you need to employ which type of statistical test for data analysis. Let us welcome Dr. D. R. Money for his today's lecture. This is a kind of a cartoon figure for how a t test works. So, you have some mean and you have some distribution about the mean. So, based on the distribution about the mean you calculate a standard deviation and based on that you calculate a t statistic and if that statistic is extreme enough you say then it is statistically significant. So, you use the extremeness of the statistic to calculate your p value and so, the p value and the extreme value of the statistic are correlated. So, if you have a low p value then your statistic is more extreme than usual and so, based on that you can. So, if mu was very different from 0 and if this distribution was not too big then you would say this is statistically not 0, but if this was close to 0 or your variation was so large that you could not tell whether it was 0 or not then you would not say it is statistically significant intuitively. Similarly, for a two sample t test you are looking at two groups and you want to see if the difference in means is large enough. So, it now it depends not only on the difference of the means, but also on how much variation you have around each mean. So, that is why you do not want to like just take the means and then see if they are different. You want to do a formal test to take the variation of those measurements around the mean into account. Did someone have a question? So, a regular t test usually ends up being very unreliable when you do it with a small number of samples like 5, 10. If you have that many samples then a regular t test when you calculate the standard deviation depending on the actual samples you have measured the standard deviation can vary quite a bit and when that happens the t statistic varies quite a bit and so your p values can vary quite a bit and will not be robust when you do a test with a small number of samples. So, there is a variant called a moderate and t test. So, what we do here is we look at all the data we have seen we will look at all the proteins we have measured and see what is the average variation for the proteins and then you pick a specific protein and if that protein is varying way too much you say this does not look like all the proteins I have seen in terms of variation. So, I am going to damp down the variation based on what I have seen in all my data. So, you kind of moderate your standard deviation calculations to make your test more robust. So, when you are working with small numbers of samples it is a very good idea to apply a moderated test. When you have large numbers like 50 or 100 a moderated test and a regular t test would probably give you the same results, but if you have smaller number of samples a moderated test is usually much more robust. So, the F test like I mentioned is for multiple groups. So, you want to see whether any of these means are different from 0. So, there are lot of nonparametric tests which I am going to skip for reasons of time, but whatever you can do with a parametric test you can also do with a nonparametric test. So, there are many. So, the t test whatever it does it checks whether two means are the same or not. So, there is a the rank test that can do the same similarly for a two sample test and for an F test and so forth. So, I will not go into the nonparametric tests, but I they are listed in the slides and you guys can take a look. Sir, simple means two groups. Yes, only one group and you are checking whether the value of the mean is same as 0 or not. So, that is where the kind of data you have is very important. So, let us say you have ratios that come out of your mass spec processing software and you did not log transform it and you do a one sample t test. You are always going to get things as everything will be significant because 0 is not even a valid value you are ever going to get out of the software you are doing. If you just take ratios the value is going to be greater than 0 all the way to infinity and when you do a statistical test to see whether it is more than 0 or not it is going to be more than 0 by definition. So, that date for a data that is only a ratio you would not do a one sample t test because it does not make sense conceptually, but once you log transform it then the question you are asking is whether it is up or down regulated. Because if it is up regulated it is greater than 0 whether it is if it is down regulated it is less than 0 and if it is not regulated it is around 0. So, that is the reason why we kind of do a log transform because it makes things symmetric and may makes many of these tests applicable. So, if you took only a ratio you cannot apply a one sample t test, but if you took the log of the ratio then you can that is true I am assuming you will have some. So, Carl is mentioning that I should point out that to do any test you need replicates because why do you think you need replicates? What are we calculating? Variants. Variants exactly we are calculating standard deviation and you cannot calculate standard deviation with a single number you need at least two. So, in to do any of these statistical tests you have to have replicates without replicates you cannot do either a one sample or a two sample or any of the tests. So, if you measured your sample only once or there is a group for which you have only one sample.  So, any number you see you cannot tell whether it was 0 or not. So, in the worst case if all you have is one sample and you desperately want to say something about it what you can do is you can plot the log ratios and then pick the most extreme value assume it is a normal distribution and in a normal distribution anything that is beyond two or three standard deviations is considered an outlier or not is a is an extreme value. So, you can do something like that and still come up with a list of proteins or genes that are different if you have only one replicate, but that should really be an extreme situation that you hopefully never run into, but it happens sometimes. So, in for all these tests you need replicates and the more you have the more robust your results will be. We are studying the effect of the second drug and so on. So, we have one control and one drug treated sample and the sample size is also very less I mean one two groups are there. So, in this scenario what should be done? So, the question was they have a drug treatment experiment where the treated and untreated are like few samples like very small number of samples and they want to find what is that what is different. So, you would do a moderated test assuming you have at least two for both treated and untreated and you would do a moderated t test. So, moderated tests work well with small numbers of samples two is probably cutting it close, but if that is what you have that is what you have. So, in our group there are a lot of studies where we have only two replicates and we have done moderated tests with those. There are a lot of other tricks you can use when you are working with just two replicates, you can try to remove things that are not reproducibly measured in both the replicates, you can kind of try to trim your data to do as little as few tests as possible, but you can still do a moderated test. What do you mean? So, different number of samples per group yeah. So, that is one of the beauty of the test is that you put all the samples of a group together and calculate mean and variance. So, if you had a group with 50 samples the mean and variance calculation will be very robust you will be fine. If you have a group with only two samples the mean and robust variance can still be calculated, but it would not be as robust. So, if you compare a group two groups where you had larger number of samples and the marker was different you will get a lower p value, but if one of the groups has fewer samples you can still do the comparison, but your p value will be higher because the way the how definite you are about the estimation of your parameters is more uncertain with fewer samples. So, you can do it, but you will get correspondingly higher p values. Extreme values, but could there be situations where these extreme values are actually true and should not be considered as outliers and. Well, outlier was probably not the right word to use I think. So, when you have a distribution of things, things that are at the extremes are considered to be unlikely in most situations. So, that is why they are considered to be to validate the alternate hypothesis. So, in that way they are outliers, but they are still part of the distribution. So, if you have only one measurement it is quite possible that something that was an outlier if you measured it again would be in the middle because it was a very low abundant protein and you cannot measure it well and you ended up measuring it having one poor measurement. So, that is the problem with using only one sample for analysis and that is the reason why you want more samples. So, if you have two replicates and one was an extreme the other was right in the middle then the statistical test is going to say wait it was over there and this is here that means, I cannot really conclude that this is a extreme value or a central value. So, I am going to say this is not different based on the variance, but if both measurements came out in the outlier then you have more evidence that this is actually an extreme value and so it would be statistically significant. So, that is where the variation of your values is taken into account in calculating your statistical significance. If you have only one replicate too bad you cannot do it. That is what I am saying the model I am saying is a normal distribution. Yeah, you could assume other distributions by looking at it, but again you have to fit a distribution to a observed set of values and then use that distribution to calculate which ones are extreme. So, most likely people use normal sometimes they use a log normal distribution which is basically if you had direct ratios you could use a log normal or a chi square distribution and I think he mentioned a Pareto distribution. So, if you have sort of normally distributed, but with very heavy tails you can use a Pareto distribution. The problem is the more complex or exotic the distribution becomes the more things you have to estimate in order to fit the distribution. So, for a normal distribution you just need mean and standard deviation and the more parameters you have to estimate the more uncertain your fitting becomes and so the more kind of questionable your results become. Technical or biological replicates? When I mentioned replicates I meant biological replicates. If you have technical replicates then technical replicates are correlated because it is the same thing you are running again and again. So, suppose you had a study where you had 5 biological samples and you ran 3 replicates of each you cannot put the 15 together and do a t-test because the t-test assumes that your samples are independent. Here they are not because 3 of them came from the same biological sample. So, there you have you have to do what is called correlated analysis. You have to account for the correlation. So, there are a couple of models you can use for that they are more complicated and I will not go into it today, but the lima package I mentioned earlier you can specify that these 3 are technical replicates of that sample and then you can take that into account in in your modeling. So, it all boils down to you have to calculate variance and the question is is the variance the same for all the samples or are groups of samples have different variances. So, there is a variance matrix you calculate and the structure of the variance matrix is what decides how you deal with replicates and technical replicates and biological replicates. And so, when you have technical replicates you have to specify that to calculate the appropriate structure for the variance matrix. So, there are models called linear mixed effect models that are very versatile. They can account for things like correlation because of replication, they can account for time series, they can even take missing values into account and they provide some kind of moderation of how you calculate variances and things like that. But they are harder to set up and many times they do not converge and you have to like fiddle with the models to make sure it works and it is not straight forward for a for a person who has not worked with them to just like use it easily which is why I do not want to cover it now. So, this is one thing that I want to mention and after that I think I should be done. So, we have mentioned that we are going to do a statistical test to figure out whether a marker is different in cancers versus controls let us say. So, you you just measured 10,000 proteins. So, you want to find whether each protein is a marker or not. So, you do the test 10,000 times and you say anything that has a p value of less than 0.05 is a marker statistically significant and is a marker. So, when you repeatedly apply the same test a large number of times just by sheer chance you will get things that are that pass the test. So, you have a 5 percent chance that something that was not a marker will have a p value less than 0.05. So, an alpha of 0.05 means that your false positive rate or false positive probability is 5 percent. So, just by sheer chance by repeatedly doing the test on different markers some number of them are going to be marked as false positive even though are marked as a marker even though they are not. This actually gets significantly worse if you look at the example here. So, an example I have here is you want to decide whether a coin is fair or not. So, you flip the coin 10 times say 10 yeah. So, you flip the coin 10 times and if you get 9 heads the probability of that happening is 0.01 if you do the calculations using the binomial theorem. So, this is definitely less than 0.05. So, if you get 9 heads then you can conclude that your coin is biased it is giving more heads than tails. So, if that is your how you set up your hypothesis test and you test 100 coins there is a 65 percent chance that you will find at least one coin that is biased even though all your coins are fine. So, if you repeat the test many many times you you will very likely find things that are different just by random chance. To avoid that what we do is when we do a lot of tests like in genomics and proteomics we do this thing called multiple testing correction. We want to correct for the fact that our p values do not quite represent the real false positive rate. So, there are a lot of ways to correct for the multiple testing I will just mention two. So, one is called the Bonferroni correction this is the most conservative correction. If you do this correction and your marker still is significant at 0.05 then no reviewer will come back and question you. What you do here is suppose you did 100 tests then you take your p value that you get and multiply it by 100. So, this is assuming that each of your tests are independent and you are basically correct by multiplying your p value by the number of tests that you do. So, you can see that if you have unadjusted p value of 0.05 and you do 100 tests then multiplying by 100 is going to make the p value basically go beyond 1 which means it is not significant. So, this is the most stringent correction and many times this is too conservative especially with noisy data in genomics and proteomics. If you apply this test you will basically never ever get any markers that are significant. The reason that happens it happens is because this assumes that all your tests are independent that they are not related to each other. But we know that genes and proteins have relations. So, if you are they are part of the same pathway they kind of behave similarly and there are lot of correlations and relations between genes and pathways that you have measured. And so, this in fact does not quite hold. So, why do you want to be so conservative when you know that your testing was not exactly like the assumptions that are made here. So, a more relaxed correction is called the Benjamin Hockberg correction. Here what you do is you define this thing a correction factor that you apply to all your p values. So, intuitively what you do is you sort your p values from smallest to largest for the smallest one the lowest p value you got you do the Bonferroni correction. So, if you did 100 tests the lowest p value you multiply by 100 the next one you multiply by 99 the third one you multiply by 98. So, you keep relaxing the the stringency which which you correct as you go down the sorted list of p values. So, intuitively that is what happens and the paper this is actually almost universally used nowadays. And the paper shows that if you did that and you set a p value threshold of 0.05 then your false discovery rate in other words how many things that are false in your entire list when you draw the cut-off there is 5 percent or whatever value you picked. And so, this is a reasonable one to use and many times in small experiments where he mentioned you have a drug response experiment of 2 versus 2 even the FDR Benjamin Hockberg correction may result in p values that are I do not know 0.1 or 0.2 and in those cases we just use the p value as a ranking mechanism. In conclusion you have not learnt how to choose a right type of a statistical test and how to correct test can give the significant outcome from your data set. You also learnt increase in the number of samples provides you much more increase confidence and the statistical power to your data. We will continue more interaction with Dr. Mani and in the next lecture he will talk to you about machine learning and clustering. Thank you.


The annual observance of Caribbean Wellness Day kicked off on Friday 8th September at the Constitution Park, with a grand ceremony attended by various delegates. The ceremony was held through a collaboration between the Ministry of Health, Wellness, and elderly affairs, the Ministry of Agriculture, Fisheries, Food Security, and Rural Development, and the Taiwan Technical Mission. The 2023 observance of Caribbean Wellness Day is being observed under the theme of power through collective action. Permanent Secretary in the Ministry of Health, Jenny Daniel, in her delivery highlighted the importance of collective action in sustaining a healthy nation. We continue to partner with key public and private sector agencies, institutions, and community groups and organizations in order to make some progress along the journey to wellness. The Ministry has also recognized that it is a difficult task to get the population moving in a manner that is long-lasting and sustainable and that the contributions of our partners, key partners, are essential to this process and the achievement of this goal. Ms. Daniel Futhur added that the Ministry acknowledges a further need to continue exploring policy options, get towards achieving more of its objectives. In order to achieve the foregoing, the Ministry of Health has recognized the need to develop more specifically the wellness portfolio within the Ministry in order to develop smart objectives and implementation plans that will incorporate more effectively and sustainably the varied activities, projects, programs that are currently being implemented. Agriculture Minister Alfred Prosper also took the opportunity to zone in on the importance of collaboration for a healthier nation. He says St. Lucia has long shared relations with Taiwan, which has resulted in an improved agricultural sector. The Ministry of Agriculture, we acknowledge the fact that no ministry can work in solitude to achieve a holistic goal and thus having healthy food options for the feeding program is one way of facilitating good nutrition. It is imperative that we get physical activity on a daily basis and in our culture this can be done through gardening, farming and improve mental health contributing to a well-rounded individual. The 2023 Caribbean Wellness Day Commemoration Ceremony also included a farmers' market component where healthy and wholesome foods were on display throughout the day. Taiwanese Ambassador His Excellency Peter Chen-Yen was very pleased with yet another successful collaboration. Taiwan and St. Lucia enjoy very good partnership in terms of health, including combating COVID-19, arranging medical personnel to have training in Taiwan, especially just recently we launched a metabolic chronic disease prevention project. For that, I would like to express my gratitude to our Minister of Health, Moses Jean-Baptiste and all the colleagues from Ministry of Health for your efforts to make that a successful cooperation. Entertainment for the event was provided by members of the Youth Ambassador Delegation consisting of musicians, fitness fanatics and cooks. The official St. Lucia Moves Ambassadors, Calypsoenians, the Mighty Dre and Leonid Pierre also graced the stage with musical renditions. The Ministry of Health, Wellness and LLE Affairs, I'm Saint Justin.


This week Russ Cook completed his epic challenge to become the first person to run the entire length of the African continent. A journey which took him over 10,000 miles through 16 countries, the equivalent of 385 marathons in 352 days. But was he really the first? A year ago I had never heard of Russ Cook. Well, hardly surprising you might say. Why would you have? Well, you see, it's odd because Russ Cook is an ultra runner from Worthing in West Sussex. And I'm an ultra runner from Worthing in West Sussex. I just found it odd that I'd never come across him before. And when Russ started his epic challenge, I looked him up. But I couldn't find him on Power of Ten or Run Britain Rankings. I've never seen him at my local park run. And he's not listed on either the DUV, UTMB or the ITRA database of ultra runners. He's not a member of any local running club that I'm aware of. Although I do know that he did run the Brighton Half Marathon and the Brighton Marathon in 2018 when he was 21. But he's clearly not part of the local running community here in Worthing, or indeed the wider ultra running community. But that's absolutely fine. I mean, there are thousands of runners who never enter any races. They're not part of a local running club. And they're quite happy to just go out and do their own thing and enjoy running for what it is. And this run across Africa was certainly not his first venture into ultra running. Back in 2019, he ran 71 consecutive marathons, traveling from Istanbul in Turkey to Worthing. He's also ran a marathon on Worthing seafront in 2020 when he pulled a car behind him. And it took him nine hours to complete that. Surely that must have made some headlines here in Worthing or West Sussex. Maybe I just don't pay enough attention. I'll admit that when he started this challenge, I really didn't think he stood much chance of completing it. Purely from a running perspective, I just didn't think he'd be able to pull it off. So massive kudos to Russ for doing so. And it's also another testament to the power of the mind over the body. When we have dedication, desire and self-belief, it's amazing what we can achieve. Look at Russ. I'm sure he would admit to you that he isn't necessarily the strongest, fastest, almost experienced runner. And yet he's managed to achieve something that all the other strong, fast and experienced runners haven't managed to. During the event, Russ and the team suffered numerous problems. The support vehicle for one had to have regular maintenance and repair as one might expect, traveling such distances, often on very difficult terrain. Russ himself suffered sickness, diarrhea and bouts of injury, and it caused him to extend the run longer than had been originally planned. Russ was also held at gun point on one occasion and on another occasion was in fact kidnapped at knife point, taken away, held hostage and was only released when a ransom was paid. There were numerous issues regarding problems with visas, most notably when the British government themselves had to get involved to secure a visa for Russ to get into Algeria. But even after completing his journey and overcoming all those problems, it was then that the controversy kicked in. Or was it controversy? Anyway, a group calling themselves the World Runners Association claimed that Russ is not the first person to have completed the entire length of Africa. The WRA is a group of runners who have completed a circumnavigation of the globe. The issue seems to be that during the challenge Russ and his team were widely quoted as saying that Russ was attempting to become the first person to run the entire length of Africa. The WRA say that in 2012 Jesper Olsen became the first person to run the entire length of Africa from north to south as part of his run around the world. But how does one calculate the entire length of Africa? Before we discuss that, if you are finding this video useful, interesting, then please do consider subscribing to the channel. Also, click that like button and share this video with your friends I'd be forever grateful. Thank you. One might argue that the entire length of Africa would be from the southernmost point to the northernmost point, or vice versa. And as far as I understand it, that's exactly what Russ did, travelling from the southernmost tip in South Africa to the northernmost point in Tunisia. However, that's not how the jog or joggle work here in the UK. Neither Johnna Grotes or Land's End is the furthest you can go north or south in mainland Britain. Dunnett's Head is further north in Scotland and the southernmost tip of England is actually Lizard Point. Of course, using Johnna Grotes and Land's End is much more about symbolism and cultural and historical significance than technical accuracy. It's also a further distance and one could argue that the entire length of Africa should be the two points that are furthest away from each other on the continent. If we take that view, then Russ also did that. Jesper Olsen started his run walk in a place called Taba in Sinai, Egypt. He travelled to his most northerly point reaching Cairo on New Year's Day 2009 before travelling all the way down to Cape Town in South Africa. His journey was 12,787 kilometres. Russ actually travelled a lot further than that, covering 16,000 kilometres. So I think we can safely say covering all reasonable criteria that Russ did cover the entire length of Africa. Whereas we could argue that Jesper Olsen didn't quite cover the entire length of Africa. That's taking nothing away from Jesper's amazing adventure, because he did that as part of his second circumnavigation of the globe. However, the intrigue doesn't end there, because in 1998, 28-year-old Nicholas Bourne from the UK ran from Cape Town to Cairo. It took him 318 days and he travelled 12,069 kilometres. In fact, the trip had started in Alexandria in 1997, but he was forced to abandon that attempt when he got into trouble getting visas to get into Sudan. So he flew to South Africa and started all over again there. This time he completed the journey, ending at the Giza Plateau near the Keops Pyramid in Cairo on the 5th of December 1998. Similar to a UK Lajog attempt which goes from the southwest tip of England to the northeast tip of Scotland, neither of which being the most southerly or northerly points, Nicholas's journey went from the southwest tip of South Africa to the northeast tip of Egypt. So what do we make of all these shenanigans? Well, my take is that it doesn't really matter. If pushed, I would say that Russ' attempt is probably the most legitimate attempt to run the entire length of Africa because it went from one beach right at the southernmost point to one beach right at the northernmost point. That's probably the truest definition of the entire length that I could think of, and if Russ wants to claim that for his own, then so be it. But at the end of the day, does it really matter what Russ did was incredible, regardless of whether he was the first, and what Jesper Olsen and Nicholas Bourne did before him was equally amazing. In fact, Nicholas Bourne raised over a million pounds for Save the Children and the Bourne Free Foundation, and Russ raised a similar amount of money. Arguing about who was first smacks a little bit of poor sportsmanship and is rather uninspiring. So let's celebrate these incredible achievements by incredible people and not sweat the small stuff. Another couple of incredible individuals are Jasmine Parris and Damien Hall. And if you'd like to watch the chat I had with them about their Barclay marathon adventures, then click that link right there. I'll see you over there shortly. Don't forget to subscribe to the channel, and otherwise, I'll see you on the start line next time. Bye-bye.