 How many of you work for a small software development company? Quite a few of you. Okay, show of hands again. How many of you use Agile Scrum? Okay, you don't have to show your hands this time, but I want you to think about this. Does it work straight out of the box? Are you running into issues with allocation, task switching, difficult clients, and disengaged employees? Good afternoon fellow Drupalcon enthusiasts. Over the next 45 minutes or so, I'm going to discuss these items and many more. Then we'll have time for questions and answers. My name is Tone Garrett, and I work for Astonished Design. I'm going to share with you some of our secrets. They're not really secrets per se. I like to think of them the same way I think of open source. Like open source, if we can collaboratively build and share software, then why cannot we do the same with processes? At Astonished Design, we do not follow Scrum religiously. It did not work for us out of the box. Instead, we undertook to understand why the ideal is the ideal and then deviate from it intentionally, deliberately in a pragmatic way. One of the main major complaints I hear over and over again is that few people do true Scrum. There will always be those purists out there. Some call it cowboy Scrum, some call it other derogatory remarks. But I heard another comment and that I have embraced and I wish I could remember who said it. I believe it was Jeff Sutherland. Do you all remember who Jeff Sutherland is? The guy said, you don't have to follow every ritual exactly to get some of the benefits from Scrum. And so let's get down to brass tacks, shall we? In a small software shop with multiple projects and limited resources, can we build a lean, scalable, sustainable business model based upon Scrum so as to garner key benefits of iterative software development? I say yes. At Estanage Design, we have found such a business model. So let's go through some of these topics that will lead us all toward being successful software companies who build inspiring software products. Let's start off this show with core values. Do you have them? These are ours. To be successful, I believe you have to have these. Why are you in business? What is your purpose? What gets you out of bed in the morning? These are the questions you must answer. We are not here to write software. We are here to champion a cause. We just happen to do it through the writing of software. So these are the buzzwords you hear all the time. Strategy, culture, vision, core values, transparency, client facing. They seem overused and yet these are the building blocks of success. You need to have the right fit with regard to partners. Do you adhere to your core values even when money is at stake? At Astonish Design, we have turned down clients. We have fired clients and the key operative here is the word clients. We differentiate between a client and a partner. A bad fit can occur when the client is only in it for the money. The client is abusive, points blame, doesn't accept the role of product owner. A bad fit can mean developer burnout, compromise ethics, and stress. Does anybody have any stress out there? Okay, three of you, alright. So then I ask the question, is a bad fit client worth the short term gain? And I say no. Let other people deal with the clients and we here will handle the partners. With regard to employee fit, you don't hire for skills, you always hire for attitude. You can always teach skills. Was Southwest Airlines, Herb Keller, was Southwest Airlines, are they successful? Yeah, yeah, very successful. So do you believe this? I do. You must have all realized by now that everyone in this room has the same access to the same talent pool. There's no special tricks in the book for getting good employees. At Estanage Design, we specifically hire for fit into our culture. Now I went through an intensive interview process myself. It spanned a month and there were three parts to it and I passed, thankfully. I am now heavily involved with the hiring process myself. Yes, we all open positions for a specific need, but every candidate should not get through your process unless they fit the culture. And the culture is defined by your core values. We recently hired a young woman who was a perfect fit for our culture. She happens to be in the room today, but I'm not going to point her out. She's smiling, however. We didn't know exactly where she would fit in, but in a short amount of time she is already proving herself. So I'm excited to see exactly where she will go. From what I can tell of True Scrum, you have one project and you have one dev team. Your dev team is, what, seven plus or minus two members? You have a Scrum master, you have a product owner. You do not have a project manager. Everything just kind of blends together. There's communication and everyone is happy. In real life, however, we have smaller teams who span multiple projects. And with real life processes, you have real life problems. Perhaps the single greatest complaint I hear on a daily basis is about context or task switching. You all know what task switching is, right? So are the developers just whining? The research suggests no. The research suggests that the most efficient way to get three projects done, as depicted in this slide, is to do them one after the other. Total focus on A, total focus on B, total focus on C. But we do not do that. Why? Deadlines and firefighting and also there's the mistaken belief that people need to be busy in order to be productive. Do you remember that from the 80s? Yeah. So the managers just pile it on. So I'm not going to go through each of these bullet points. But I will recommend the book Slack by Tom DeMarco. And in this book he said, there is never less than a 15% penalty due to time sharing a knowledge worker between two or more tasks. Are developers knowledge workers? Of course they are. What's really key about this slide? Never less than 15%. So I've seen this myself many times. Similar situation. In our office we have a phone. Anybody have a phone in their office? Of course you do. And I know this is going to sound really offbeat, but when the phone rings there's the expectation that someone will answer it. It's that human touch. But time and time again I see a developer engrossed on what they're doing, their eyes slowly coming back to reality, that glazed look on their face. Do you know what I'm talking about? And what is it? The third, fourth, maybe the fifth ring by the time they're back, they run over to the phone, they pick it up, and it's too late. And the damage has already been done. But we all know that that developer is going to go right back to their desk, to their computer, and get re-engrossed and start working again, right? The guy up front is laughing. What's he going to do? He or she? What would the developer actually do? 15, 20 minutes. They go to the bathroom, they go get a cup of coffee, or what's worse? They go and talk to another developer and interrupt that person. Productivity declines very quickly. Let's talk a little bit about resource allocation. When I began working at Astonish Design we worked in silos. You know what the word silo means in this context? Very narrow. I worked on one project, another developer worked on another project, very little communication. We just kind of, you know, it was very similar to when I was an independent software consultant. Then we switched to teams. And there were immediate benefits. I mean immediate. Collaboration really started to happen. The projects took off. We modeled ourselves after Scrum, the self-organizing team. You've heard that phrase, yes, self-organizing team. Do you allow it to happen at your company? Or is it allowed for you to do it? So there were no specific requirements on how the team would work. The developers would choose how they would do it. However, I call your attention to the slide, the upper left-hand corner. We still had each developer had a quota of 35 billable hours. And you notice the three projects colored purple, green, and I believe that's orange. 60 hours per week would be allocated to each project, which is the sum of two developers. 35 and 35 is 70, and we call that 10 hours wiggle room. Now we can allocate to the partner. Two different design teams emerged. In dev team one, we have pair programming. We have two projects. They have the purple, and they have the green, and they may divvy it up between weeks one and two. And they work on the same project at the same time all the time. So what are the benefits of pair programming? Well, first and foremost is that each developer is well-versed in every aspect of the architecture of each project. And what are the detriments? Well, you've got two people billing for the same time for the same line of code. Sometimes you have to consider that. Now I have a friend who works in town, works for GM. He has two developers who work concurrently on the same project simultaneously. He feels that they give 300% for two employees. Well, that's just good business. On the other hand, if there is not a measurable productivity increase, it's a cautionary tale. What about dev team two? We have a front-end developer, and we have an API developer. And they work, notice here, they work on one project per sprint. One works on front-end only, one works on API only. What are the benefits? Each developer does what each developer does best. But what are the detriments? You've heard the thrown under a bus. Well, I guess that's not exactly it. But let's say Ringo here, the API developer, gets hit by a bus. What happens? That whole entire section has to be relearned. Or what if Amy gets a job offer somewhere else? So, there's no exact answer to this, and we're still evolving through this process. How does discovery and design fit into the picture? Now, I know what you're thinking. We haven't really talked about Scrum just yet. And we're already how many minutes into this, 15 minutes into this, but we'll get there, patience. As I mentioned in my session description, Scrum is not a prescription. You need to have key constructs in place before you can get anywhere. And this includes a process for discovery and design. Before you can do Scrum, you have to gather the requirements. You have to extract business value from your product owner. At Astonish Design, we create a clickable prototype or an interactive prototype for the prospective partner. This integrates requirements and design into a workable facsimile of what the end product will do. Then the partner can decide, yes, I want to go further, or no, thank you, everybody. If they go with us, now we have a blueprint of exactly where we're going to go. And if we did this right, we will also have assets that can be used in the actual product. So, discovery and design is not really so different from the way we've ever done it in the past. A lot of you have heard the term waterfall. We're still not Scrum here. This isn't iterative. This is the gathering, the requirement stage. So now we finally get to Scrum. And this is the epicenter of the speech. And I'm going to talk to you about something that we can actually use. Again, at Astonish Design, we undertook to understand why the ideal is the ideal, and then we interpreted it in a very pragmatic way. At a project management workshop that I attended here in Austin a few months ago, someone called Scrum the Delicious Center. I think it was someone from Four Kitchens. I apologize. I don't remember who it was. But I love the term. Now what we do is we start with the waterfall, the design and discovery. We have the Delicious Center here, and then at the tail end, closure, maintenance, however you want to call it. So looking at the Scrum ceremonies for a two-week sprint. We currently use two-week sprints at Astonish Design. We're experimenting with a three-week sprint. Why would we experiment with a three-week sprint? We want to reduce the number of meeting hours per actual development hour. We're very sensitive about that. We want to be cognizant of our partner's time. I'll get into that in a moment. These are the guidelines for Scrum meeting lengths for a two-week sprint as per a website I came across some years ago called CollabNet by a certified Scrum trainer, Michael James. And for a two-week sprint, these are the durations he recommends. I want to call your attention to the bottom two. The bottom two meetings are additional ceremonies that are not part of True Scrum. However, you've probably heard of the backlog refinement meeting. Even Michael James says, hey, it's not part of True Scrum, but it's so valuable that we include it. We call it pre-planning. So we have pre-demo, pre-planning, and neither of which is client-facing. Now, that's fairly significant. And now, why would we have a pre-planning and a pre-demo meeting? And I say this, an ounce of planning is worth a pound of cure. So the bar graph on the right gives an overlay of what we actually do versus what Scrum suggests. Does that all make sense, the bar graph, the number of hours, the light blue grade? So our meeting durations are much shorter. And even when you add in the extra two meetings, we're still considerably shorter. So let's get back to the why. We do not want to waste our client's time. Now, waste is a very strong word there. But when you have two devs, your Scrum master slash project manager and perhaps an account manager in the same room with the product owner and the meter is running, that's a whole lot of kaching. That's a whole lot of money. And we are very sensitive and cognizant to the amount of money we are charging our partners. To be a true partner and a proactive steward of our projects, we do not want to overbill. And being a proactive steward is one of our core values. You see how I tie this back to core values. Tailing Scrum part two, artifacts. One additional step that we do is we have developers pre-write user stories. And that's different from pure Scrum. The devs divvy up the features and they do their best guess for how these user stories should go. Oh, sure, maybe they'll be off. Maybe they'll get close 70, 80% of what the product owner really wanted. But that's enough. And this is all in a non-product owner facing meeting. So with pre-written user stories, we have something to show the product owner. And that aspect of it still fits in the spirit of true Scrum. In the inspect and adapt. So yes, we're deviating a bit, but it's not really that far off the mark. One final difference from Scrum is our devs, our guys, do not pull stories into a sprint backlog. We use yesterday's weather. Do you all know what yesterday's weather means? It's another term for velocity. Everyone know what velocity means? No. Velocity is basically how many user stories you finish the previous sprint, your time average over sprints. So we know if they did 30 user points, user stories in the previous sprint, then we can anticipate that they will do roughly 30 in this next sprint. Why is that important? We need to set expectations with the product owner. So now, and this is kind of an important thing for me anyway personally, where did we get these ideas? Trial and error of course. But a lot of these ideas come from the developers themselves. I began a brown bag lunch technical talk initiative. You didn't have to go. Anyone could go or not go. It was purely up to them. And the guys, I wanted to teach a little bit of the scrum principles. And remember, I told you about CollabNet, Michael James. He had these little videos and I would show this short 15 minute video. And then we just sort of round robin talk about it. And all of a sudden, what was a tech talk transformed into a policy generating engine. There was an emergence. And there's a psychology involved when the developers themselves create the policy that occurs at the company. It's a psychology. It's a buy-in. Very powerful stuff. Highly recommended. Moving on to best practices. I do have permission. I found this picture on the web somewhere and I emailed one of these gentlemen and they gave me permission to use it. I have no idea which guy it was. So best practices. Pair programming. One of our teams does it 100% of the time. I have done it. It is a quick way to learn a new technology, a new framework, or even just a new architecture of a project. It's way better than digging into Stack Overflow. Anybody dig into Stack Overflow? Okay, a couple of you know what I'm talking about. I mentioned my friend who gets 300% out of two guys. That's fantastic. Again, though, I recommend that if there's not measurable productivity increase and there's no actual reason to do it like people's lives would be at stake if a mistake occurred, it's a cautionary tale. Think about it. Option B, I don't have a lot of time to get into the specifics of automated deployment but I highly recommend Verker. Check it out. Same is true with automated provisioning. Check out Ansible. Highly recommended. Testing, however, I do have some time because I am a huge tester. I love testing. I hardly embrace testing. I believe all of your devs should too. And the framework doesn't matter. It could be unit test, PHP unit, Q unit, it doesn't matter. Whichever framework makes sense to you. I find that tests are way better than documentation for showing just how code is intended to run. It is basically a blueprint. And one last point that I would make about testing is this. It's the best way I have found for figuring out legacy code. Any developers in here ever inherit somebody else's mess? Oh wow, yeah, okay. So for me, testing is invaluable. Automated testing, we have a rule. We have a one test minimum per user story and we are dabbling with test driven development currently. Now finally, I'm going to call your attention to the more, we'll call it intangible of the best practices on the list, continual improvement and continual learning. These are defined by a culture rather than a procedure. There's no process that shows you we're going to continually improve by God. However, I feel that in a company, in today's market, absolutely positively has to have continual improvement and continual learning or you simply will not be successful. With this economy, with this day and age, it's just a must. Let's chat a little bit about project management. Project management is nearly synonymous with communication. You've probably heard the number, 85% of a project manager's job is communication. I'm not sure if that's directly from PMI or if it's in the PIMBOC. There was a time in which I wanted to become a project manager. I became a certified scrum master. I took different courses on project management. I learned about Gantt charts. I learned that pert charts exist but no one uses them. So I know a little bit about project management but I am by no means a project manager. At Astonish, we do scrum for all of our new projects yet we still have a traditional project manager. The scrum literature says you don't need it. They say you have your dev team, your scrum master, your product owner and you do not have a project manager, not the traditional kind but in the kitchen, who is it that wears the apron? It's the product owner. And the project manager shouldn't need it especially if you do things early and you do them right. So the product owner is supposed to run the show. They own the product backlog and communication is just supposed to happen. But this is real world. Our product owners are partners. They're external generally and they need a little help. So at Astonish, we have a project manager who doubles as a scrum master and keeps the product owner on track. He handles allocation, budget, expectations, scope creep. As my project manager, Chris, calls it he is the keeper of pain. They are coach, mentor, sounding board and conscience. So imagine the scenario. Project manager gets a phone call from the product owner. You want this, you want this, you want this, you want this. Absolutely, we can do that. Do you want to increase budget or do you want to decrease scope? Those are the tough conversations that have to occur and that's what our project manager does. So who does what? Our development atom consists of three teams, three dev teams. One dev team is comprised of two to four developers and you notice the darker purple product owner, the overlap there. Our second dev team looks like, or the same dev team, but the second project. So project one, project two. Then in the center, we have a core nucleus of support. This is our UX designer, our UX architect and the infamous project manager, scrum master, of whom I told you, the keeper of pain. If you look at the green, does it look green to you guys? Maybe it's yellow. The green area on this shows exactly how many of our people touch any given project. So now how do we scale for the future? And I apologize for changing my idiom. Instead of the development atom now, I'd like you to think of it as a squad. I was going to go with the development molecule, carbon chains. It was all going to be fun, but I didn't want to get lost in the weeds. So looking at the military, you have three squads. We'll build a platoon. Three platoons builds a company. Three companies builds a battalion and onward and upward. So it's scalable and it's sustainable. So we use the power of threes to scale for the future. So in conclusion, today's ambitious software design requires a new set of processes. This session considered a holistic view of software development from the standpoint of a small software development company with scrum at the heart of the center. The Drupal community, you guys, are great at contributing to open source code. So let's continue to contribute to processes. Let's be open about them. Let's change the way the world tackles software design. We have a chance today to make a difference. Now, if you have ideas or thoughts, my email address is right there. I want to hear. Do you have any questions? I got you in that a half hour. You got time. So we work in a really small shop. It's basically myself, another developer, and then my direct report, who's kind of been a project manager role. And then we've got content editors at satellite locations. Do you see that this kind of model would fit with us since we're a lot smaller than what I've seen up here? So what I was trying to get at with my presentation is that you can have small teams to do scrum. But in some cases, it's also a consideration, does the project fit scrum? Do you have, you know, iterations where you want to have thin slices of shipable code every two weeks? Do you have issues with needing to protect yourselves from external sources? When I was an independent software consultant working on my own, there was no need for scrum. I was the one-man show. So sometimes if you have only one or two people, it's not necessary. Does that answer your question? Yeah, it does. Thank you. I know something about waste, so the meaning in your process or the things you do and where you identify you have the waste on the process. What do you mean by waste, exactly? All the things that add value to the process. Things that don't add value to the process. Okay. You always get the most interesting questions at these events, don't you? Well, things that don't add value to the process would be when collaboration does not occur, when communication is at a problem. And that's one of the points of scrum is to facilitate communication. That's why you have your daily stand-up. That's why you have insurer accountability for your devs to talk to each other. So I would say communication is probably the most important aspect of this, that when you don't have it, everything falls to the wayside. And that is where waste would occur. Hi. I'm just going to go back to the early part of your presentation you were talking about. We're in a shop similar to what you're talking about where you have developers and you're bouncing from project to project. We're not actually scrum yet, but we're considering it. Just kind of go ahead to the end when you had your atoms and squads. Are those teams doing the ideal situation you described at the beginning where they're working on one project and sort of a consecutive faction? Or are they doing multiple projects depending on what the stage that given project is in or if you're waiting for a client to get back to you or all those stages where there's a little bit of a downtime in the project? How do you manage those? So we do... I'll go back to this slide, which answers the other gentleman's question a little bit as well where waste occurs. Waste occurs when you do a lot of context switching. And we still do our projects piecemeal like this. We do slice them up into individual projects. But we give the developers the chance to choose how they're going to plan their week as long as they get their 60 billable hours in for that particular partner and that project. We don't mind if they do two days of project A and then say four days of project B and then go back to A and B. But there is waste in this and it would be really, really nice if we could just go ahead and have one dev team work on one project but you just can't do that with a small software company. A bigger company can handle that. Someone like GM has multiple scrum teams who devote all of their attention to one project. That's the purpose of this speech is to really look at it from a pragmatic standpoint. We still have pain points. This is not an ideal process. The scrum process itself if used ideally probably would be painless but even so that's why we're here today, right? Did that answer your question well enough or is there anything else that I could delve into? Yeah, I was just wondering if you could, that's great. I'm just wondering if you could skip ahead again to your Adams and the team overlap to just see how those people move around a little bit. A lot of slides here. Yeah. This one? Yeah, so your development team. Your development team works on multiple projects. Correct. Okay. We do try to limit it to two projects. But I mean, again, this is real world. You have projects coming down the pipe and you don't want to throw away a business opportunity. And so what do you do? Sometimes you need to have somebody doing three projects. And so we often augment that with contractors. We're hiring so that's definitely something that we are addressing but we do have certain pains there. Software development is pretty much synonymous with the word pain, don't you think? There must be other industries where you could just make a lot of money without doing anything. I haven't found it yet but there's certain value to software development though. I think we all agree otherwise we wouldn't stick with it. Any other questions? Any other comments? We do scrum for projects that seem to follow the pattern and also for projects that don't seem to follow the pattern. And the reason why is because we kind of like self or identify the core of scrum to be, we want to be agile because as we learn we can switch or we can shift perspective. We can reprioritize things versus just iteration. Every two weeks we need to have a product. Is that an oversimplification of scrum? I know this is too personal but are we adding bureaucracy for no reason to some of these projects? What's your general feeling about projects that don't exactly fit the pure version of scrum? Well I'm all for that because we get back down to what the possibly Jeff Sutherland said is that you don't have to use all of the principles of scrum to gain benefits of it. And I believe in my heart that iterative software design is important. Why? Because too many times you get to the end of a project and you're doing all the garbage work that was on the list that you, the proposal and it's not really important anymore. So to me the product backlog is a severe and important improvement in software development. You realize that the product backlog you can only do the top one, you can't prioritize two things at the same priority. So then getting back to do we do sprint after sprint? You have a sprint and even if everything you did in that sprint was completely wrong you only lost two weeks. Whereas if you had the waterfall all the way to the, all the planning and the design etc. And you're doing the eating a lot of pizza at the end because you're trying to burn the midnight oil to get this product out the door. And at that point are you really putting your heart into the product? You just want to ship this thing. So then you're going to get the bugs and all of that other stuff. Then you might throw away two years of work. How many projects die at the end? How many projects actually make it? I forget the numbers but it's really disheartening. Whereas with Scrum you really have the option of well here another sprint, well we'll throw this whole thing away, we'll try this, we'll try this and if the product owner doesn't like it then they can go away and they're not out millions of dollars. So for me personally I believe in this stuff. That's why I went down this track. I hope that answered your question. On this slide here you've got the product owner as part of the development team. Are you appointing an internal product owner or are you including the client in the development team? Well technically I'm not sure if you can see that on the, the dev team has kind of a darker circle just around the technologies but so right here is a darker circle. And so that's really the dev team. The product owner, all of our product owners, pretty much all of our product owners, yeah all of our product owners are external partners. And so they're not really part of the dev team but they are part of the project. Yeah sorry about that right there, that's our two to four persons. Hi. Hi, so our company is just getting into Agile and we're trying to figure out all our pain points. And I think most of the, and I'm a developer in most of the training that's been given has been given to project managers. And the process that we're, I guess being given is called Agile. But I can tell or things that I've read seem to say that Scrum, although an Agile process is like a subset of Agile, can you differentiate between the two? What makes Scrum sort of different from Agile or what sets it apart? Okay, I'll do my best. I'm most familiar with Scrum but another Agile process I believe is Kanban, which derived from Toyota. And it's just a different way of addressing how things work, how the process works. Kanban tries to limit work in progress whereas Scrum has thin vertical slices of potentially shippable code per sprint. Tim, does Kanban doesn't have the concept of sprint, does it? No, just swim lanes. Swim lanes. So to answer your question, Scrum is an Agile process. There are other Agile processes like Kanban. It really depends on what your particular project is, whether or not you would do it. Now Kanban would work great in a, like Toyota, where you have a, what do you call it, a line, production line. Whereas for software, I believe Scrum is pretty much the best that you're going to come across. So going back to, so our project managers have been trained with Agile and one of the pain points that we keep feeling is the, not that this shouldn't be this way, but the initial focus of generating the user stories are solely on the business value and the product owner and what has been left out was the development process and what I'd like to see in the beginning of your slides was the clickable wireframes that you generate before it seems like you even get into generating the user stories. Did I interpret that right? Is that what you're doing? Are you generating user stories from your clickable wireframe that you generate in the beginning? Okay. So this is still in progress, but our clickable prototype is handled by our UX designer and our UX architect and they may prototype this in UML for example or they may actually create actual CSS but the clickable prototype is something that's done completely outside of Scrum so at that point there are no user stories. That information however is documented in like a UML document or as much of Matt and Nick's information in their heads goes into as much documentation as we can and then the developers get involved and then that's when the user stories start. And of course that's subject to change. Everything that I'm telling you today, if you come and I present this in a week or two, well, stuff changes. Any other questions? Anything else that... Yeah. So how would you handle multiple product owners? Multiple product owners in the same project? Yeah. Okay. So then I would say you have to pinpoint which one is the product owner and call the rest of them stakeholders. It sounds like you've got a bit of pain there. When you're talking about switching, so you have a development team that has, that's working on more than one project. Who makes the decision about when to switch between, like I'm assuming you have a Scrum and then the developers figure out which kind of tasks mean the project they work on in that time. Is that right or...? Mostly. So what our project manager does, he also sets up allocation. So that takes the business partner's needs and allocates hours to a development team. And so if we have one particular partner who needs 60 hours, then they will get that. The team lead and the devs on that will kind of decide what project they work on and which day. But they always have that number, that goal that they need to get to. So it's kind of up to the developer to switch if they come to a stopping point or...? Yes. Okay. So the developers go through the user stories. They pick off the highest priority one that they can handle. They start going through it. They try to minimize work in progress, but they also are watching their own time clock. If they put in enough for project A, it's time to switch to project B, and then they do the same there. So technically, we don't run one sprint. We run multiple sprints concurrently per team. Time slicing. All right, great. All right, well... Okay, and this is probably going to be helpful for the smaller companies out there with trying to get clients initially to understand this process. And it seems like... And again, it may be the smaller shops that are starting to get into the bigger stuff, into the $50,000, $100,000, $200,000 projects, is what's the best way to really walk a client through this or propose this and say, hey, I know that Jimmy down the street and the other two firms gave you a fixed rate and they told you to get all your features. And the sales guy was really nice and he said, all right, but here's how we do it. We want to actually build an experience. We want to make sure that we're transparent along the way and we're really working with you to build what you expect. What's the best way to introduce a client to that that may not be very open to that initially? So basically what we have is we have someone in our company who educates the potential partner. And they have kind of a spiel like I went through today, only more geared toward this is how it's going to be done, exactly what you just specified. And so it really comes down to educating. Now, I've heard this, we don't do this in our company, but I've heard tell of companies who will actually send a potential partner to get their certified product owner, certified scrum product owner certificate, CSPO. You guys know about, you got your CSM as the scrum master, you got the CSPO as the product owner, you got CSTs, the teacher. I think there's a CSD now called it for the dev. And now I went through the process and I highly recommend that you have at least one or two people who have gone through the process who are certified scrum, simply from the standpoint that you learn so much in these classes that you just can't get from a book. When I did it, I went through this on my own nickel in Las Vegas and I read one, two, three books beforehand, Jeff Sutherland, one with Ken Schwabbert. He wrote a couple of books on the subject. I've watched a bunch of the Mike Cone videos. If you know scrum, you know Mike Cone. He's a mountain goat software. And so then I went to this class and it's not just $1,200 and you get a certificate. It kind of is, but it isn't because if you get the right teacher, they're going to fill in so many of those blanks. Anyways, I got off on a tangent, but the point is that you have to have somebody in sales who knows the scrum process. You have to have someone who believes in it and is able to impart that to the product owner. And we happen to have somebody who's absolutely terrific at it. He just happens to be the CEO also. Oh, and for the record, you can't hire him. Anything else I can help you guys with? Alright, no one has ever shot someone for finishing a session early, have they? It was a pleasure.