 My name's Howard Diner. In case you're wondering about the title for this, it might be a little bit enigmatic, let me try to explain. There's a saying that I used to grow up with, you know, with doctors, you know, you call the doctor, the doctor says, take due aspirin and call me in the morning, right? Well, there's another part of this presentation that we did yesterday in the open space, you'll see a little bit of it here, called red bead experiment. So I want you to take two beads, call me in the morning. This is one way that we can get to manage software projects better. I first, oh yeah, here's the whole thing. I first want to talk about what it's like, what you usually experience as you go through and put together a piece of software, do a project, do a product. What does it look like? Well, for me at least, I find that as things keep on falling in, it's like, you know, things falling out of the sky, all the what's, all the when's, all the why's, they keep on changing and at the same time, the who's and the how's of making this stuff happen, they also change and we have to stay current with that or, you know, the stuff that we do becomes inefficient, very hard to do. So when you do it right, at best, it kind of feels like an organized chaos is taking place. Of course, if you're not doing it right, we get into this cycle, a bad cycle, a very bad reinforcing cycle where we somehow plow through the stuff, we get it done and just about the time we're about to wipe our heads, we do it again. Okay, so it's kind of like the Toils of Sisyphus. So, how did we get there? What went wrong along the way? My feeling about this is that we tried to look at how we produced things. 20th century was all about how we can produce things efficiently. We looked at guys like Henry Ford. We looked at Taylorism. We looked at the scientific way that we can improve the production of goods and thought that we could actually apply this to software. Now, what you're seeing here is a picture of what's called Rouge River. It was built by Henry Ford in Detroit between 1907 and I'm going to say 1918 or so. The plant itself was a mile long. At the one end of the plant, the idea was to take in raw steel ore, raw rubber, and other raw materials, build a car on a long, long assembly line, and at the end roll it off, start the engine, and drive it away. They got very good at that. Okay, we engendered a whole middle class that can now consume those things. Unhappily, we tried to apply those same kinds of principles. We started breaking down the work that we needed to do into small little pieces. We started employing people, giving them titles. Okay, and saying, your job is to do this, your job is to do that. Rather than the way they used to build cars, which was to employ craftsmen that understood the entire process from the beginning to the end. So, Taylorism came to play. With car making, a lot of it has to do with blueprints. I've figured out this stuff. I've done the engineering, everything works, and I can give it to somebody and stamp it out. Time after time after time, it reduces the cost. It doesn't work with software, does it? So, it doesn't work with software because we never really build the same piece of software twice. When you look at software, instead of the type of process that we use, a predictive process, we need to do something that's more adaptive. Something where you employ it with guided missiles. If I want to put a missile on target, there are physics that define the path, second order differential equations that will define the path. I can aim the missile at where I think it needs to go. But the missile itself is going to be subject to forces of chaos, tiny manufacturing defects, small currents in the air, things that change. If I don't take that to an account, I'll never be able to hit my target. I need to be able to correct course, which is what we do with iterative development. If you look at software, the development of software, it's actually a kind of a wicked problem. Wicked problems are defined as those problems where small changes in either requirements or the way that we get to a solution have nonlinear effects. In this case, those nonlinearities will be on the resources and or the schedule. So, if you look at this diagram, what you're seeing is that I don't know everything in the beginning. My solution is going to be something from the requirements that I know now and the requirements that I have to learn. And somehow, I have to cover everything inside there. And this is why we have those nonlinearities. In any case, this is an example of a nonlinear problem. There's a bridge in Seattle that was built called the Tacoma Narrows. And engineers didn't understand some of the hidden requirements inside that problem. And this is what happened when they built the bridge. Well, we have another problem here. Now, the reason I chose that clip is in our releases, when we have late changing releases, many times things actually fall apart right at the very end, which is exactly what we don't want. We have these kinds of collapses. So, let's talk about how we can get things better. I'm going to start with the quote that everybody remembers. Those that cannot remember the past are condemned to repeat it. This was done by a guy named William Edwards Deming. Show of hands? Good. Okay. If you know about his background, he was actually a statistician. He actually worked in the predictive process arena originally. He was tasked with helping the US government produce goods for the Second World War. He was very good at it. Unhappily, after the war was over, he couldn't find a job. And he ended up finding a job in Japan, helping the devastated industries there rebuild. And he did stuff that was kind of interesting. This is a picture of the Red Beads experiment. Right? It was a great analog to help people understand what he was talking about. Deming worked with a lot of the people like in Toyota helped them understand things like the build the Toyota production system. You know, those were the original thoughts that went on before it. These sort of analogs were very illustrative. Now, what I want to show you is a short clip from training that I did last year. This happened to be at AT&T in Seattle. And let me just show it to you first. Hopefully it's humorous. Now, the reason for this clip is the process that we put upon ourselves, the extreme ceremony, the forms, all of the pieces that are supposed to go, the gates that we are usually associated with are replicated in what we did what we did it yesterday too. Okay. And some of the takeaways from that is that too much process kills the things that we're trying to do. There's something adaptive about it. We can't put process on top of it. And in fact, the biggest thing that we're producing is not just software, but software that has quality. Right. We can't incentivize the stuff away. And I'll talk more about that too. And I want to give you one thing before we get into the rest of it that kind of explains it. The iron triangle of development. Couple. Okay, for those that aren't familiar, we can describe the physics of software development. I don't want to draw on the board because I think it's kind of set in its ways. A triangle. So this triangle has vertices at features, at resources, and in time. And given a setting of two of those vertices, the other vertex is going to be fixed. So if I have a set of resources, and a certain amount of time, then the features that I can put together are determined. If I try to move those features around, I can't do it because the iron triangle will break. The reality is that the iron triangle isn't quite descriptive enough. It's actually a tetrahedron. There's a fourth vertex that connects the other three. That fourth vertex is quality. So when we're when we're stressed, we're trying to get something done and our managers yelling at us, you got to get this done by law, what will we do is we lower the quality vertex. Let me talk now, which is what this talk is really about, about those 14 obligations of management us, given the time, I'm going to be brief and some and I'm going to go into depth in the others. Okay, but it's all kind of there. Okay, this was from a book that he wrote. Oh, I should give you the name of the book. Back in 1993, called the New Economics. Right. Again, nothing about software. It's all about people all about organizations. Deming was talking about forming a constancy of purpose. Okay, uses the word improvement of product and services. Why? Because we have to stay competitive, stay in business, provide jobs. In an agile world, what does that mean? In an agile world, what it means is that we provide stuff like the wise. Right, what what do product owners do? They specify what we need. They kind of prioritize it and say when we need it. And they tell us why we when we tell our teams and involve them for that constancy of purpose, people will react better. It's why the values of transparency, openness, those are those are really important. I happen to believe that a lot of what we do in agile and scrum in particular has to do with team formation. Okay, and in sense, that's why people wouldn't understand at first, how scrum could scale. Because it's about forming those teams. And we'll talk about that as we go. Yes, and it's all about how we reason with them. If we're honest, we're going to expect honesty back. Right, easiest policy. Then it goes on to talk about cooperation. Okay, we have to be able to involve everybody in his world. This was employees, customers and suppliers. What is it in our world with software development? Well, it's about working with the people that we need to work with, working with them in a way that doesn't say, here's what I do. Here's my card. This is what I do. Instead, it's what can I do for you? We're going to do this whole thing. We're going to figure it out. Okay, so we have to remember that the team can do more than the whole than any individual. And that we have to get away from heroism. So we create, you know, some sustainable engineering. Deming says, forget about dependency on inspection for achieving quality. Okay, instead improve process. What do we think about in an agile setting that says the same sort of things? Where does this come from? Well, in an agile world, if you recall, most of the engineering practices that we want to use are from the XP area. Okay, the reason for that is that software is inherently complex. Okay, testing, the quality aspect of it, we don't produce quality software, we haven't produced software at all. So how can we do that and accept new requirements, make changes quickly? To do that, we have to bacon the quality from the beginning. It's something that you can't do with control. In fact, too many organizations confuse, you know, the QA role, right, quality assurance with the QC role, quality control. Remember, quality control is more about having that assembly line, looking at little pieces and flicking them off when they don't, when they right. Instead, what was that, what change was made by companies like Toyota? Teamwork, the insistence of quality from the beginning, stopping the line when things go wrong. We do the same sort of stuff in agile. Deming says, stop using price to give business. Right, don't reward contracts just on the price tag alone. Instead, talk about a long term vision. You've heard a lot of people around here talking about people like Bezos. Okay, and the idea of the long haul. Right. In agile, we also have that concept. Sustainable engineering. The idea that education and skill upskilling is important. Companies that are out there, I bet they're here too, that have, you know, the 20% rule, who works for a company that says like on Fridays, do what you want. And what happens? Okay, they're spending time on activities that they're interested in. Right, does that, what does the business get out of that? Right. And so what happens is that the people get involved in things that they're interested in, they grow in that Maslovian scale. Right, we start off at the bottom, you know, with physiological needs and work our way up, you know, the scale with love and trust and safety and all these things eventually come up to self actualization, which is what we do on Fridays. And then these people then bring this into the company. So those those kind of activities pay off very, very quickly. I hope you see find out. Okay, continuous improvement is important. Okay, Deming is talking about it in terms of production and service. Right, we talk about it. In terms of how do we improve our process? How do we improve our skills? We in a scrum world always do this like every other week. Right, and we take a retrospective. Interesting thing about retrospectives are the things that went wrong. Not the things that went right. The things that didn't work out so well. What was the root cause of those? Alright, let's not blame the person. Let's look at the system. Right, we saw this yesterday with red bead. Right, it wasn't just a matter of making more process to get better results. It was a matter of people saying, I think I understand why the and we don't know this when we start. Okay, we have to learn, learn about the products, right, one type of knowledge, learn about the project, project knowledge, how to do it, different things. And and once we do that and start employing a feedback loop, we can start solving the problem. Deming says Institute training for skills. Wow. For those people building forts, building cars. He's talking about people on an assembly line, which by the way is like skilled or semi skilled or unskilled or semi skilled labor. Right, he's saying these people need to be invested in. Right, well, if those need investment, then imagine what it should be for people that are working in a highly technical highly competitive, constantly changing workplace. Now, I don't know about you. But when we start thinking about the organization, and start recognizing this kind of equality, it has something to say about the way that we hire people. Right. Most people, when they apply for a job, company wants them to give them a resume. I've done this, I've done that, I've done this other thing. I did it here, I did it there. Here's why I did it over here. Right, company looks at the resume and says, ah, you're a good fit. Well, to me, that sounds like Taylorism again. Okay, we've predefined all the things that they can do. And then we apply them as little workers in that software assembly line. It's exactly the wrong thing to do. Right, what you really want to do is to look at the person, understand their capacity for learning, not just their capacity for delivering or making very nice looking resumes. Deming starts talking about the idea of leadership. Okay, and he says institute leadership for the management of people. Right. Not saying how to manage people, but how to lead people. They have to understand abilities, capabilities, aspirations. Wow, that sounds pretty soft. Those are the sorts of things he never says in here, you know, recognize how fast they are at producing code or how fast they are at working on the assembly line. Okay, the idea about this is to help people do better jobs. So we forget that Agile is really about leadership. I like the way that Fred George is starting to put this and talking about not having managers for people, not even having leaders for people, but describing them as concierges. Okay, how can I have somebody that can get things done for the team, make them more than just we used to term servant leaders, have the team employ them basically. Now, there's more to it than that. Okay, people that are out there that, you know, have a business card that says management on it someplace, have to learn what it means to lead, have to understand what leadership is. They have to learn how to coach, how to improve people along the way. And it's not easy. It's much easier to be taught how to give orders and how to measure compliance. Alright, that's an easy thing to do. I like the way that Wayne Strider puts this. He's a management type consultant. He says managers use people to accomplish work. I think assembly line workers. Leaders use work to grow people. Upskill them, make them more valuable, be part of this sustainable engineering that is everybody's business within the company, driving out fear and building trust so everyone can work effectively. This is probably the biggest reason that agile transformations fail. Now, they may not fail in words. We may still have things that say agile all over them. Right, but they fail in spirit. And the reason that they fail is actually because of this trust factor. When people are afraid for their jobs, and they're afraid they're being graded, and that they're, you know, they're looking for compliance, they want to make sure that you make a commitment. You made, you know, you keep to it. Right, that's the way that we grade people. Then, of course, they're going to respond by making sure that they give you estimates that are high. Okay, they're going to respond by not trying to reach for a brass ring. Okay, they're not going to try to do the things that will, you know, that will really make, distinguish us, but rather they're going to make safe decisions all the way along the line. So, this is one of the most damning problems that we have is building teams where people aren't afraid. And where does fear, by the way, show up in Maslow scale? Right, two levels up from the bottom. I mean, right above like breathing, and I think safety, like having a home. Okay, fear is a very potent thing, and it's bad. You see this hard. Yeah, I shouldn't have said this. The sorts of things that we talk about, you know, where the lies, how did Craig Lorman put this, turning reds into greens, the green shifting that occurs? Right, we do this to make ourselves safe so that our manager doesn't bang us on the head or whack us or whatever. Right, so those kinds of dashboards are like, gosh, you know, talk to me about truths, you know, don't make up lies in statistics. Let's keep on moving. Breaking down barriers, avoid, abolish competition, and start talking about win-wins. To me, all of this stuff has to do with the ideas of abolishing titles and establishing roles. Understanding that we need everybody on the team to be able to contribute so the ideal teams that we have will be generalized specialists. Where we don't have generalized specialists, what are we going to do? We're going to look to develop the people to give them the skills that the team needs. So if I have a QA person, I don't want to just stamp them like, QA, you do testing, that's all you do. Make sure that they start understanding their developers too. They're developing different things. They're using scripts maybe instead of C++, but they have the capability of learning, okay, and mentor them into better things. We need high performance teams. It's very hard to go out there and just buy that kind of talent, especially in a domain that's specific to you. The most amusing one, of course, has to do with demnings, talk about eliminating slogans and targets and whatnot. A walk into an organization and see, you know, things on the walls that say teamwork, performance, so on and so forth, all these inspirational posters, then you walk through the cubicles and you see a complete curated set of Dilbert plush animals. When I do that, I know that we're in trouble. We can't inspire people to have innovations on Monday morning. What we can do is create an environment where when those things happen, they're rewarded. Need to eliminate the goals, numerical quotas. This all has to do with metrics, right? Now, agile doesn't really have much to say about metrics. If you read like the manifesto and whatnot, there's really nothing in there about this. But that's not to say that metrics are bad, okay? Measuring are things that we need to do. If we're going to improve, we need to know where we are so we can understand if we got better. Okay, but the sorts of metrics that we use are not the sorts of things that just respond to a state or measure the wrong thing, right? I once worked, the first commercial product I did was extremely bug-ridden. We couldn't even release this to our friends, okay? And somebody had the bright idea of saying, oh, we'll incentivize this. Every time we find a bug and fix it, guy fix it gets $100. And instead of our defect count like trailing down, it went up enormously. You know, some brainiac just figured that out. But anyhow, true story. Joy, remove the barriers about, take that raw people of joy. Again, think back with the assembly line. Think back at some of the silent films, okay? Buster Keaton's. Okay, where they have like the mechanized world and there's some beautiful science fiction stuff in the twenties or metropolis about that. It's assembly line thinking got us into a lot of trouble. Instead, start thinking about creating outcomes, right? Let's not, let's not measure behaviors and reward on behaviors. Let's think about outcomes. Team has a good release. Team finds that, you know, that they can get the features in that the customers actually need and do it on time. Well, instead of going back and giving out individual, you know, $100 bills or equivalent. I used to say take the team to Disneyland, but the equivalent here. Now an interesting thing, I just work with a client in New York and they replaced a scrum master for whatever reason. I don't, I don't even remember why. Under the old scrum master, things were going well. The product owner came to me and said it looks like it used to be funner around here. And the new scrum master was kind of a task master. He wanted to take a agile project management tool and create more reports and more statistics and thought that that would be better. When we concentrated, did the coaching on making things funner in the office. We got much, much better results. Education, self-improvement. I've kind of said this a lot, talked about the difference between product knowledge and project knowledge. We're looking for more than commodity resources. We're trying to build high performance teams to get the stuff that we need done. Finally, everybody in the company has to accomplish the transformation. He wasn't talking about agile transformations, I am. It shows in your training. You don't have training for just the scrum master and expect that the entire organization is going to get fixed. Everybody comes in. The guy who started Starbucks, a general owner of a name of Schwartz, and he had a saying which was everybody in the company has to learn how to make coffee. So when leaders start understanding what the implications are of doing things, and the people that are doing things understand the implications of what the business is all about, you'll get much, much better results. So as you can see, we're looking at the end and available for questions and comments. I know that we ran over a couple minutes here. We have a way to start. We happen to connect with you guys. You can link in as a best way, and thank you very much.