Introduction to DevOcho and the Podcast
0:14
Hello, my name is Kenny Pyatt. I am the founder of Devocho and I am the host of the Devocho Way podcast. If you got a chance to watch our last episode, I spent some time telling the story about how the company was founded and kind of what we were doing there. I talked about living on a sailboat for 5 years and sailing the Caribbean, which apparently was the thing that people were most interested in because I got a lot of comments about that. This week, we're going to talk about something different. I am very opinionated about the way that you build software and software projects because I've done this for 25 years now. I also am am really opinionated about who needs to be in the project and who needs to be involved involved at each step. So for this podcast I'm going to give away all of our secrets basically of how we build software the devocho way and also where we're putting AI in the process now and and the different tools and things that we're using. I promise in this conversation I will share 90% of what we do. The last 10% I'm going to keep because it's it is trade secrets for us. I'm going to get a little bit technical in a few parts, but I'll I'll do my best to keep it technical in the fra- the sense that if you're technical, you've got something to Google, but I won't go so far into the weeds that if you're a CEO trying to decide about building out a a technology team or building out software, or if you're a CIO that just recently got promoted, or if you're in the process of like fixing a broken process in your team, I won't go so deep in the weeds that your eyes would glaze over. But I I'm going to be pretty specific.
1:52
So what is the Devocho way? So over the course of 25 years of hiring internal teams to build software, offshoring teams, nearshoring teams, I've learned this works and this doesn't. And
The DevOcho Way: Building Software Effectively
2:06
I when I came to start this company, I decided I was going to try to engineer a process that would fix all the things that really drive me crazy when I'm trying to get something delivered. Cause every company I was an executive in, we would plan out three to five goals, five to seven goals that we were going to complete that quarter. and my name would be on half of those and it would be like on the other half because everybody needs technology and and especially in the companies I was working in. And so I had to deliver. I had no choice. If I didn't deliver, other teams, other parts of the company couldn't do their job. They couldn't hit their goals. So I very frequently have been in the seat of having all the pressure. And I like it. I I don't have any problem with that. it's some kind of weird personality problem that I have that I don't mind being responsible for things or taking those on. But how do you build a company like a like Devocho, a custom software company where we can have people show up that have that pressure and we know that we can build software and we can hit the deadlines and we can make the the thing work and how do we take the risks out of, you know, going offshore? That's what we're going to talk about today. The first thing I was trying to do with our company, I was trying to think through when I would hire an offshore team, what would go wrong? And one of the things that that would happen to us is we would hire a company to build something. So what they would do is they would take the statements of work, they would sign, yay, and then they'd panic, go to their HR team and say, go to your database of résumés and hire people that have this skill set. And I didn't want to be in a spot where I had to make that same idea. So we started from the very beginning creating a a training program where we could train our employees. And we built this whole resource around DevOps developers, UI/UX, QA, and Scrum Masters. Those were the first five courses that we wrote. I actually spent almost 18 months building out these courses and getting that stuff set up. But basically in a month or two somebody goes through our course and they're up to speed. They know our process and for me that fixes that problem instead of like I get a statement of work who is going to do this. We've got a we call it Devocho University. So the Devocho University students are there. They're finishing their course. We already know they're able to do the work. They just learned how we do it and we've got a chance to see work from them. Those are the people that we pick up and put on your projects.
4:40
So for me that was one of the things that we we needed to fix. So part of the devocho is not just how we build software, it's how we build our company and how we build our team. So how does that apply to a CIO or somebody that like is trying to do this on their own? I I would tell you
Creating a Skilled Team: DevOcho University
4:57
the first thing that I would do is I would write a single document of this is the technology we use, this is our process, and I would have a document that explains all that. And when you hire a new employee, have them work through that. If you've worked for me and any of the companies I've worked in, that eventually is something that I did in a lot of companies. I would realize that I had a group that they're good, they're talented, they're smart, but they're not together. And so I would host a book club. We'd find a book on a methodology. We would talk about like when microservices became hot, I went and found a book and we would have a book club about microservices.
5:34
So education and training and those things needs to be ongoing and that helps you solidify your team. Another another problem that we saw frequently when we would hire offshore teams was just communication. So the way we handled that was basically a technology situation. We set up a specific set of technologies that everybody has access to that includes chat.
5:57
It includes obviously email and it also includes a very specific way that we use ticket tracking and ticket systems. Um for what we do, we build projects. Almost all of our customers come to us for projects. We have a few that come just give me an engineer. I'll take care of it and and that's fine. But but what we typically recommend is hire us for projects and we can put fractional people on projects. So you can have a part-time scrum master, a part-time UI/UX designer, and that that helps your budget, but it also improves the quality. So for communication, we use a ticket tracking system that allows us to laser focus in on just the tickets in that project just for the duration of that project. We track story points and completion times and stuff across that. And so we take a statement of work, we'll work with you to build a statement of work, and then we break that down into tickets. And everything we do follows a similar process.
6:52
It's it's the agile scrum methodology but with some opinions. The definition of done is very important to us like when does it meet dot and for us that includes um a full CI/CD process. There's automated deployments if the customer will allow us to do that. If not, we're going to go as far automated as we can up until the handoff. So we might go up until we built a Docker image and then we ship the Docker image to the customer. So for you, how does that apply? If if you're not hiring Devocho and you're trying to build this in your world, I I would say the same thing. You need to to work on intentional communication. For us, a ticket is a source of truth. Everything that's needed to do the work needs to be on the ticket. If it's a front-end feature, there's a mockup.
7:38
There's annotations. There's an explanation. If it's a back-end ticket, there's an architectural document. There's something that explains this is what we're trying to do. In almost every project, we start with the customer. We we do the initial like sales portion where we plan out the statement of work. We get pretty detailed and then we will either vibe code or we'll use cloud design or or a tool that we can rapidly prototype and then we get conversations going. So this is our idea.
8:07
What do you think customer? Give us feedback, make changes from there. We cut those into our user stories. So for your users and and this is what I see every time I'm brought in to like do a
Communication and Project Management Strategies
8:19
turnaround or fix a company. You hire super smart engineers and super smart engineers sit in front of the computer and their super smart brains will make the most complicated interface possible. So the the fix to that is UI/UX. You have a designer or someone whose job is think about this from the user's perspective. Don't let that super brilliant guy design it because he's too smart and he can't think of simple things. So let the the designer come up with a simple interface and then hand that off to the engineers. So they're building from a design. A lot of engineering teams don't do that or that person is separate in a different department. And in my experience it's best if you build small teams and on that team is a person that does that work. They will do a great job. So when I went offshore, I did this at the beginning of my career. I just need programmers. All I need is programmers. Give me all the programmers. Um I remember Microsoft, Steve Palmer, developers, developers, developers. Like it's not enough. But we all think that going in like, well, I just need more engineers. It's a it'll be built faster. I would hire just engineers. I'd hire QA from another group. I'd have a person in my office that would be the the product owner or scrum master and they would run it and it would be a hot mess because this group would blame this group and this group would be saying can't get anything from these stupid people and it would just always be a hot mess when I'd offshore the whole project or outsource the whole project and they had the complete team. So you're talking a leader of some kind, we call those scrum masters. that person paired with someone on the business side that knows the work, a product owner. That is an awesome combination. Then you put the developers in the room. So they're hearing the planning, they see what's going on, they get access to the documentation, they know how to build it. UI/UX to make it functional, pretty, a QA to make sure it all works. I know that Amazon made it famous not to have QA and I have watched a hundred companies. We're going to do that. we'll take the QA money and we'll hire another engineer and everything is broken all the time. Have a QA person. Have a detailed oriented person that looks through the work and make sure it's working, especially with AI coding agents. AI coding agents are awesome. We use them, but you need to have a QA step in that process. And then ultimately, I also think it makes a lot of sense to have a DevOps person in the team because you got to deploy the thing. It needs to be secure. So we we take our DevOps/DevSecOps kind of role and we teach a person our process of how to test, how to deploy, how to build out that CI/CD pipeline. We have like processes and templates that we follow. And so to me that's a team. If you outsource to that team, they are going to deliver great software. If you hire that guy on Fiverr and you send him a a loose speck, he I'll give him like a 40% chance. Bro is going to deliver something awesome. I'm gonna give it a 60% chance. You're going to be frustrated. My recommendation is hire the team. You will thank me. I promise it works. Having that leader that pairs with the business person is valuable. Having a QA to make sure it works is valuable.
11:37
having three or four developers or at least two. I always recommend don't start with one,
The Importance of a Complete Team
11:42
start with two because what if you hire an idiot and you don't know because he sounds smart. Always hire two. The devotion away for us is that it is having the people in the right place, the people involved in the process. Again, we do that fractionally. Very rarely do we lease a whole team unless it's a really big project. We will lease a third of a scrum master, 25% of a UI/UX.
12:03
Typically, we do three to one QA to developers. That's kind of a good rule. And then we will do um one DevOps, but normally those are also fractional depending on your project and how difficult. We might do them full-time the first couple sprints, then we'll go to 30% and then we'll go back to full-time right before we launch. And that's how we do it. If you're building out multiple teams, that ratio should hold. One DevOps should be able to keep two or three software teams going. You don't need necessarily one DevOps per team. The next thing that I tried to fix with the Devocho way was around we now have these crazy tools. I didn't always have these, but now I can
Utilizing Modern Tools for UI/UX Design
12:45
sit down with the UI/UX, give her claw design. We can say this is the features I want. I might write three, four paragraphs and give that to my UI/UX. He or she will um go in and immediately start working on that thing I gave them. They'll pick the brand colors of the customer or ours if we're building for ourselves. They will pick um general like style guidance to the AI. They'll hit a button and then boom, we will have a mock and then we'll sit down and we'll I'll give notes. They'll iterate and we take the mock into like right now we're using cloud code. That's kind of our cloud design down to cloud code and they'll iterate in cloud code. And so instead of going to Figma or Pinpot or Photoshop or Pencil or whatever your tool of choice is to create mocks, we're just vibe coding those and taking that design. And then what we do is we'll take the screenshots out of that. We'll make that available to the engineers. And so they've got a very high fidelity design that they're working from. And in our experience so far, AI puts way more on the screen than you need. AI for some reason assumes things that don't make any sense. It just you probably wanted this random percentage on the screen because it looks pretty like so you just have to clean those things up a little bit and then through the iteration through the design you can plan an entire feature now in about a half a day. So we do that in our sprint zero.
14:12
We'll sit down with a customer we will do our user interviews. We'll capture all that information. That all becomes context to the AI as we're building out the design. We take the statements of work. We take any documentation the customers have provided and then we um we build a mock and we try to plan two sprints ahead of the engineering team. If you plan too far ahead, you're making a mistake. The mistake is you're learning as people use the software. The other trick is we demo every sprint and we try to deploy every sprint. There are times where it's not possible, but if it is possible at all, we're going to deploy the software so the customers are touching it and you're feeling it and they're feeling what it's like to use it because sometimes the software is very complicated and the teams over commit because they're wanting to get a bunch of stuff done and we're late on some of our deployments to customers in the process. That's a mistake.
15:12
I call it out. If we make that mistake here, when our scrum masters aren't deploying every two weeks and the customers aren't touching the software every two weeks, you end up with a lot more bugs at the end of the process because the customer didn't get to feel it. So my encouragement to you, follow the scrum process, retro and demo every two weeks. Deploy, deploy, deploy, deploy. And once we've gotten through sprint zero, we are normally set up for continuous delivery. So we can deploy the software throughout the sprint as we're fixing bugs or adding features. We're deploying to environments that customers can log into and they can see it. During sprint zero, we set up the CI/CD pipelines and the deployments. We set up our tickets and all the things that
Sprint Zero: Setting Up for Success
15:56
we're going to do out of statement of work to kind of create that initial two sprints backlog. And then we go to work mocking features and we're doing user interviews and mocking features. So the first two weeks of our projects are really busy, really aggressive. The reason that we do that was my experiences. I would hire a company. They would go to work building out a document and we would end that first two weeks with here's your plan. It's just a document. I can't touch it, taste it, or feel it. And with the tools that we have now, there's no reason to wait to see screens. Screens help you understand what's being built. So we try to get there as fast as we can. in that that first sprint. Then at the end of the sprint, we go for approvals. Um when the customer approves it, those tickets are added to the next sprint. I we'll we'll add a graphic to the screen here, but you can go to the Devocho website to see this. We do two loops. The planning sprint and then we do the building. So sprint zero is a planning sprint to kind of prime that loop. And then sprint one we build. During sprint one, the UI/UX , the Scrum Master, UI/UX, those guys are planning what will be built in sprint two. And so we keep that process moving so that everybody's the plans ahead of the stuff. We try to have two sprints, like I said, planned ahead of time so that at any moment if the team finishes early, there is a backlog that's ready to go, it's refined, everything's definition of ready, they can grab those and pull them into the sprint. That way, if there's extra bandwidth, we don't miss anything with that. We've got it to go. The again with the tools we have now that is incredibly reasonable. When everything had to be built out in Figma or pinpot we could do it but you would spend a lot more money and time in the UI/UX side and now the UI/UX can spend more time thinking about how is Susie going to take three steps out of her very complicated process. That's where you want the UI/UX spending their energy. How do we make this better? How do we make this smoother? How do we make it more polished? like that's the time that you want to invest in your software. So that's the other part of the devocho way is is how we handle the very first sprint. Um our sprint zero. Um one of the things that we do as well is kind of different. I don't take every project that shows up. I don't accept all projects. I want to understand their investment. I want to understand their decision. How do they approach buy versus build? In our last uh meeting week, we we talked in depth about this, but but generally speaking,
Buy vs. Build: Making Strategic Decisions
18:30
in that last podcast, I laid out a framework for if it's core to your business, you probably should build that in-house. If you have a technical team, if you don't have a technical team, like your business is too small or nobody in your company knows anything about technology, then then you shouldn't build it in house because that would be a disaster. But if you have a technical team, you want to build core things in house. You want to outsource anything that's ancillary to that core group. Internal tools a lot of times can be really great projects to outsource. You need this thing. It's going to make you more efficient. It's not necessarily customer facing. Those are great projects to outsource. If you don't have a technical team, I think you have no choice. You need to outsource. But I don't typically recommend the fundamental parts that make your business special. That needs to stay in. You guys will treat it with so much importance to your business.
19:22
So I don't recommend that. I do recommend anything that bolts on, anything that integrates, anything that you if it touches other systems. Those are all wonderful opportunities to outsource and save your team to focus on things that are critical. Another um part of that buy versus build decision is for me an ROI. I want to understand if we build this, what's the return on investment? I don't want to just build something and never talk to you again. I want to build something and you love me and you wanted me to build the next thing and keep working or enhancing that. So, it's better for our business to have that opportunity to know there's an ROI. You're going to do a good job. Your business is going to have an opportunity to grow if we do this work and you're going to love us and keep working with us. So, I try to understand that you as a leader in technology absolutely need to understand the ROI. Do not fall into the trap of this is cool technology. Oh, wouldn't it be awesome to build this thing? Don't do that. It's so easy to do that, but you need to understand what is the business value of the thing that we're building. And that's important to me. Another thing that the Devocho way encompasses might surprise you, but even how we price our deals and how we offer guarantees. When I was hiring offshore companies, the most frustrating thing in
Pricing and Guarantees: Reducing Client Risk
20:41
the world to me would be we'd hire a company, they would want to sign a three-month gig, a six-month gig, or whatever. And I get it, they're trying to pay payroll. I promise we are also trying to pay payroll, but I don't want to go into the business with the company and find out 30 days in or 45 days in they can't do the work and I'm stuck. I've already signed this long-term contract. So, what we do in that, we offer a 30-day money back guarantee. So, during that first 30 days, if we haven't impressed you with our planning, our ability to set up environments and get all that stuff working, and that first sprint demo where we build stuff, then you can fire us. I'll give you your deposit back. And it'll be sad. We haven't had to do that yet. Like, knock on wood. But yeah, we will 100%. I'm not going to trap you. That's not what I'm trying to do. And I'm sure at some point that might happen. I hope it never does. But by doing that, it changes the incentives for us. We don't want to give that money back. We don't want to miss. So, we kill ourselves for the first 30 days of every project to make sure the project is set up correctly and that, you know, you're going to get what you're after. That 30-day money back guarantee also takes all of the risk out except for time. Your risk becomes time. Our risk is the people, the resources, the skill, and the money. If we deliver, we get the money. If we don't, you've only lost 30 days. You go hire the other guy that you were talking to about building the software. The other thing we do is we build
Building Software with Transparency
22:14
out very detailed statements of work. So, it's really obvious what we're going to charge, when we're going to charge, when we're going to build everything. So, you can kind of kind of watch in milestones and see where we're at. And so what does that matter if if we sign a statement of work that says it's going to take 10 sprints, 20 weeks, you're committing to 20 weeks and I only offer you the first 30 days. That doesn't make any sense. So we do month-to-month contracts at any 30 days. You give us notice after the the initial, you give us notice, you can cut us loose. That means we have to deliver every month. We have to always be delivering for you. I like that pressure. As I said at the beginning of the podcast, I think having that pressure makes us do a better job. The old analogy of diamonds are formed in a mountain under the pressure of the mountain. It's coal being compacted into the diamond. We're going to deliver better software if there's always that threat of this customer can just call and fire us. So, we take that very seriously. One of the other things that I I'm going to talk about as as is loosely part of the Devocho way. The reason that it exists, it's basically I've had to recover projects a lot of times. I've been called in to like people have hired a different company or they've hired an internal team and key people quit like things like that and there's a project that's some percentage of the way finished and how do you recover that? What do you do in that situation? So, we typically will will do a short consulting gig where you pay us to review the code, the progress, and give you a no BS assessment.
24:00
This is where we're at. And then we will build out a statement of work from here to finish. I like turning around projects. If you had a a CIO quit and the team just fell apart, we love coming in and trying to help clean that up. The way we do that, like I said, is we'll review the code. We'll go through everything. We'll we'll make gap analysis from where it is to where it needs to be.
24:23
We'll do user interviews. We'll get an idea of what the company needed. I have a really great example of that from before I started Devocho. I was hired in a company where I guess the CEO and the CIO had kind of gone to war against each other. The CEO quit. I'm not sure exactly why. I wasn't there yet. And then the CIO quit like 10 minutes later. So the two leaders of the company just walked and the owners hired a new person to come in and take over and they hired me to kind of come in and repair what had happened. But by the time they hired me, it had been months. Almost the whole team had quit. So it was a complete rebuild from zero scenario. I had to hire a whole bunch of people, get the projects back on track, find out what the direction of the company needed to be, all of those things. And so as I was planning out our process and what we do here, I was trying to think through what helps. Like if your teams have all quit and you're back in charge, you need a person that you can call that has the team sitting on the bench ready to go that you could just drop in and start building again. In parallel, rebuild that internal core team to own your core products.
25:34
So I wanted to build a company that could do that. We can't and I'm proud of that. That's part of our Devocho way idea. You can ask for help and we can make that happen. Now, I'm going to get into the weeds on how we actually build software. We built a tool stack that largely uses
The DevOcho Way: Project Recovery and Management
25:52
open source software so that we can redeploy that tool stack for each project and each customer. So, we have a ticket tracking system, CI/CD, a lot of uh code repositories. We have the same tools everybody else uses for security scanning in the DAST and SaaS testing for security. So code quality, code security, finish deliverable doc like docker images, we scan those for security.
26:20
We have that as a template and we use it on every project and we've picked tools that work with every tech stack effectively. I mean I'm sure there are tech stacks that it doesn't work with, but they're are going to be obscure. You need to have those same tools in place. You can pick Jira. It's fine. We don't use Jira because we have a very project focus and normally Jira is better for forever projects in my opinion. And also Jira's just become the everything tracker.
26:50
So it's it's kind of cumbersome and kind of it's easy to over configure I guess is what I would say. Here's their 37st step scrum board. You know, you don't need 37 steps but that's a temptation. You need a ticket tracking. You need some kind of continuous integration, continuous delivery. You need security scanning, code quality scanning. You need that. You need some kind of u end toend tests on any platform that you build. So, I'm going to give you our tech that we use for that. Uh the system is called Tygga. Um it's a it's really good at only managing custom software projects in the agile framework and we like it for that reason. It does the story points the way we like to. It's got stories and subtasks. It's has epics. It has attachments to tickets, all the things that you'd expect. And it's got really clean, simple burndown charts. It helps you track stories for the whole story points for the whole project and story points for each sprint. So, it really gives us an idea of where we're at and it just it works the way we work for CI/CD. Right now, we use Jenkins in a Kubernetes cluster that we host on servers in our office.
27:58
Jenkins just works. You don't have to do a lot to it. And we have a couple of customers that are ultra paranoid about things being on GitHub. So we we can't use GitHub GitHub actions with those customers. So for us, Jenkins internally checks the same boxes. For the same reason, we actually run Git T in the office and GitHub outside the office for code repositories. For quality, there's um I think you say it simgrp and sonar cube are two tools that we use to do code quality testing.
28:32
I like the sim group in CI/CD because it's super fast and super easy and you don't have to have a whole server set up to get a report. And with AI right now, you can feed you can have the AI run that and iterate against itself to fix issues. So it's kind of a very powerful tool. We also use Trivy to scan Docker images that have been built already oasap for web applications and we've got some other tools for mobile that we use. But I I'm not like I said when I started I don't want to get so far into the weeds. I it's more interesting to me that you understand you need things in all of these areas. The Devocho way that's just what we do. This is part of who we are and how we build for the agile process. Our scrum setup is exactly the same as the standard scrum.org
Agile Processes and Tools for Success
29:19
set up. We have a feature uh planning meeting at the beginning of a sprint. We do dailies. We ask three questions. What did you finish yesterday? What are you going to do today? Is there anything blocking you? And if you're uh we call them scrum zombies if you don't have an answer to those three questions, we're going to shame you until you come back to the meeting with those answers. It's important that you're engaged in these meetings and that you understand the value. We do a demo and a retro. Those are the normal meetings. We add two for our customers. We do a feature planning meeting where at the beginning we will set up and show them these mocks that we've built. We'll talk through their project. We try to get information. Um so that's the the feature planning and then with the end we do what we call feature approval. So we start a sprint, we gather information at the beginning, at the end of the sprint we present that information and try to get approval. If we don't get approval, we'll iterate another meeting to get approval. Most of the time after one or two sprints, we've learned how to work with the customer. They've learned how to work with us. Those meetings are quick and sometimes their emails. Anytime you can do an email meeting, it's the best meeting. So, we we try to do that. So, those are our two kind of deviations from the standard scrum.org. On a large enough project where there's multiple teams, we have a much more elaborate process. This is part of my 10% that I'm not going to share, but I will tell you if you go to scrum.org and you look up like scrum trains and conductors and and that idea. There's some really good ideas there. So, if you're trying to run scrums of scrums and groups of people, multiple groups of people on teams, that's a really good model to start with. The last thing that I I think we're going to talk about um today, and this I think is something else while we're talking, you really need to focus on on the business outcomes, not the technical deliverables. I hinted to this, but as a new CIO or CTO, you don't want to go to your your executive leadership meeting and say,
Focusing on Business Outcomes
31:18
"We're building three microservices." They don't care. The CFO doesn't even know what that means. Like, you don't want to focus on that in the way you talk and communicate to business leaders. This is is kind of a little bit outside of just perfectly the Devocho way, but it's something we teach our scrum masters as they're interacting with customers. You want to talk about the business outcomes. So, we're going to build this feature because it offers this capability for our company and this is the ROI if you can calculate it or this is the efficiency gain that we're going to make from this. As you're planning and communicating and talking about building software, you want to talk about the outcomes. I think that really does a good job of like framing how to communicate around projects and software. Um I do have these five items that can derail a project and and how the Devocho way kind of helps stop those our software process. One of the the things is like fears that one of our customers could have or a pro a prospective customer or fears that you might have as you're going into a project. Nothing gets done but meetings. This was my fear.
Avoiding Project Pitfalls
32:28
At the beginning of a project, we'd have like 53 meetings and I'd feel like, where's the code? What's happening? Why can't I see anything? And so, our sprint zero is how we fix that. But there is a crazy story where I was hired to come build software. And at the time, I'm actually just an engineer. I'm I'm being hired as kind of the first engineer to come in and start building out a team to build software for a company. And this company has hired a Harvard MBA to plan software. This was in the early 2000s. I show up and the Harvard MBA literally I say, "All right, what do we have as far as the plan for the software that we're building? I've heard the owner talk about it. He's kind of explained what they want, but you've been here for 6 months. What's your plan?" And I'm not kidding. The guy had this roll of butcher paper and he goes into a conference room with me and he pulls out this butcher paper and he lays it down and he rolls it across the whole table. It rolls off the end the conference room table rolls off in the table and it keeps rolling on the floor.
33:34
He goes, "This is the plan." And I'm like, "You've spent like months and your plan is handwritten on butcher paper like like gosh, what are we doing?" And and what was even worse about it, and I'm just going to be completely mean to this person who's a very nice person, but that plan was completely useless. There was nothing in there that I could understand, even what he was trying to accomplish. Not a single this goes on this screen. And I remember like back then everything was like, "What's on the homepage?" He couldn't explain it. He didn't know what needed to be on the homepage. He just he was he had written only outcomes. And so he was like, "But what do we build to get the outcome?" he couldn't explain anything. The ne next fear that you might have is quality drift. So it's really easy if you don't have a rule around, you know, test coverages, automated test coverages, things like that for the stuff that you build in the beginning to get broken by the stuff you build in the middle on that project. And so in our process, we have like a set of kind of strong rules about things like unit test coverage. So, I'll I'll share one of my trade secrets. You don't have to follow it exactly, but you should sort of follow it. We start a project with zero test coverage on projects. We're going fast and test-driven development is awesome if the risks are really high. If you make a code change and you could cost $100 million, slow down. We're doing test-driven development. If you're in a hurry and the faster you can get to market, the better the results of the outcomes are for you. We don't ever do test driven development. We write tests later. So we'll build, we'll build, we'll build, then we'll test. So our rule at the end of sprint zero, we don't have any tests. At the end of sprint one, we're targeting 10%. If if the the whole thing lines up perfectly to 10 spreads, we're going to do 10% additional test coverage every spread. So 10% goes to 20, goes to 30, goes to 40. Projects don't always line up like that. So we've got some basic rules. Then we have a rule that we hit 80% coverage. We're not going to continue to increment that to 90 or 100%. And and there's a lot of reasons we have that. We want to test the most important things.
35:52
We want to test the core things. And then there's other things that are important, but they're not critical. We don't try to test for those. So I feel like those tests are they're going to slow the process down and waste time. So that's how we avoid quality drift. That's our number one way. The other way that we avoid it, our QA team is trained to build out an unbelievably detailed regression test. The software that we use allows us to create stepbystep, click byclick, fieldby field regression tests. And so the team does, the QA team manages that set of regressions on every project we do. So any QA like if a QA person were to go on vacation another QA can come in log in that same software and follow that same regression plan. Then we automate we automate with playright is the tool we use most of the time and we typically do it in Python but you can do it whatever but we'll we'll take that stepby-step detailed written regression plan and we automate it. So now when we're in our CI/CD pipeline, if somebody makes a mistake, the playright test will fail and you catch it and that protects you from this was working and now it's broken. Actually had a project recently that didn't go awesome. It's going to be completely transparent. We built it very quickly. I'm going to say we got 95% of the way there and then we just had some some math errors. The software is a very math heavy piece of software. Basically, we took a very heavy Excel spreadsheet process and we turned it into software. And it went great all the way up until just a handful of math bugs. And what would happen is, you know, we had four developers on that project. One would make a change and break something on somebody else's screen because each screen in this process was kind of interconnected. And so the solution to that was I said, "Where's our test coverage? We're at the end of the project. We should be at 80%." And the response back was, "Ooh, we're only at 30% test coverage." So we didn't follow our own process. So after a brief moment of come on guys, what are you doing? We sat down and we went after it. And now we wrote something like 700 tests, we have 80% test coverage. We've almost completely ended that issue of fix it here, break it there. And now if that happens, we write another test so that those things don't break each other. And that's that's how you avoid quality drift. That's really the only way. A good QA process and good automated tests. The third one, when we started, everything was chaos. My gosh. Um, this is why we do sprint zero and we have standards. We have specific standards around code, code code quality, like I said, unit test coverage. So, that's what fixes that. Scope creep. Oh my gosh, I could do a whole podcast on scope creep by itself.
38:35
You start custom software, we bill you for our time. It's like an attorney. If you go back to the attorney and you want to add another like six sections to a contract, he's going to bill you for that. Software works the same way. If you ask us for more, it's going to cost more. But it also works that way if you're building software internally. If you've got a team inside and you keep asking for a little feature change, little tweak, little this, little that, costs go up. This just how it works. And so how do you rein that in? The way that we do that in the Devocho way is we've learned that there is a percentage that almost every customer will ask for changes. So we I hate to use the word pad because the second I say this, everyone that negotiates with me will be like, "Hey, uh what percentage did you put on that? Let's take that off. We won't ask for any changes." And and I know that's not true. You're going to ask for changes. You're going to have great ideas while you're building the software. So for us what we do most of the time we try to ask for contingency. Now you're going to hear my percentage. So we will it depends on the scale of the project. The bigger we ask for slightly more the smaller we ask for slightly less. But normally I I come in 10 to 15%. I'm going to tell you so let's say just making up numbers. Let's say it's you know 10 sprints $100,000 project. I'm going to tell you, plan for another sprint and another $10,000 for all of your great ideas because you're going to have them. Everybody has them.
40:06
And that way, you're not surprised. Your software is better because you've had good ideas to improve it. And then you don't feel like the cost and the scope creep have exploded. We have a a slightly different process in the Devocho way here as well where we will do the initial project with you. But up front we'll tell you what we expect our like ongoing support. We call it baseline support would be and in baseline support we're doing things like security updates as software changes, bugs are found in the libraries that we use. Do you need to upgrade those? We need to sometimes make code changes. So we give you a price for those with some enhancements and it varies based on the project how complicated it is but you can know that after your initial budget this is going to be your monthly budget. So some of those feature asks that are are awesome but they're lower priority kick those into that baseline project the baseline process after we've deployed make a running list work with your scrum master and ask him I keep a list of all these lower priority features that would be awesome we had a a customer one of my favorite projects very difficult project they are two of the most operationally focused people I've ever worked with in my career and They they had like 10,000 good ideas and we were trying to integrate all 10,000 of them and then by the time we get towards the end of the project, we're running out of time and you have to go back to the customer and say, "We're hitting your statement of work. We can't add any more of your feature requests. We've passed our padded. We've passed everything. We've got nothing left. You're either going to have to pay more or you're going to have to stop." And some customers will be, you know, if it's got an ROI, I'm paying more. We're doing it. Some customers are budget sensitive. They can't do it. So the Devocho way we ask for an intentional upfront this is your scope creep budget and then we try not to need it. To be honest the scrum masters are told you know work to the statement of work number. Try not to engage that 10%. Um because we know our customers are happier when things are on or under budget. But if you had a lot of great ideas you hopefully told your CFO and you've got that 10% aotment. Um, I hired a company that was out of Eastern Europe and
Ensuring Clear Communication and Flexibility
42:22
I did experience this to some degree. We didn't really understand what they were doing and why we were paying them. There was no outcomes that we could see and so we quit fairly quickly. The way that we don't deal with that in our process is we basically I just told you our entire methodology.
42:40
It's a clear progress based process. So, you know there's milestones in every project. You know that we're hitting it or we're not. We also allow you to make changes. Changes in what you're asking for. If we're in a 20we engagement and on week three you get a call from a customer that says, "Oh my gosh, we need to change everything." We will work with you and we'll try to adjust the scope to still be within the statement of work. Sometimes we can't, but we try. Um, sometimes it's just kick one or two smaller features out and there'll be room for that feature. So, we we'll work with you on those things. We don't lock you in. Okay. I think I said a million things. I am supposed to ask you to follow us on all our social medias which will be posted somewhere in the description or or on the screen. And I I appreciate you listening. If you listened all the way to this point in the podcast, you're interested in this topic and so am I. So if you want to shoot me an email, my email is [email protected] . I love to talk about this. So feel free to shoot me questions or give me Kenny, you're making a mistake in your process, you need to do this other thing. I also love feedback. So, please feel free to shoot any kind of communication with me that you'd want. If you need custom software, we're happy to have that conversation. We do statements of work for free and we plan in pretty good depth, so you should see value even just engaging with us for that. Thank you very much. You guys have a great day.
