In this episode, Jeffrey discusses why so many teams are not happy with the pace of software delivery. Situation Most software teams we see are not moving at the pace their companies would like. One of the Clear Measure Way tools is a self-assessment. It's easy to find on the Clear Measure website. One of the subjective questions included is "are you happy with the pace of delivery of your software team?". Most respondents are not able to answer YES. We're going to talk about that. Mission- Many businesses have decided to have internal software development teams. Companies that are tech companies, have to. For others, it's a judgment call. Over the last 25 years, many non-technical companies have outsourced the creation of software. They lost a lot of money, didn't get what they thought they were going to get, and they have shifted to operating software engineering teams in-house. They still consider custom software to be strategic for them, but they want more control by hiring their own employees. But they are then frustrated that they don't actually have more control. They might have more visibility, but many are frustrated that having the in-house team doesn't actually increase the pace of delivery or solve every problem. The goal of this video is to go over the common categories of time suck that saps the capacity of software teams everywhere. My hope is that once you understand where all your team's time is going, you can make decisions to change that and redirect the effort to justify the progress you want. Execution- There are five categories of work for a software team: - Working on new software - Diagnosing or fixing or reworking past work we thought was done - Diagnosing or fixing the software as it runs in a production environment - Administrative, non-software work - Time off Working on new software This is where we want to maximize the effort. We want all of our team to be working on new software. This is where to build new features, make important changes, and enhance features so they work even better. This is all our internal and external customers ask for. They think our team spends all of its time in this category. In reality, some teams struggle to get time to work in this category.This category includes everything in the software development lifecycle. Talking about the vision for a new feature is part of this category. Doing architectural prototypes for options for new changes is in this category. Doing routine maintenance on our software is in this category. Yes, renewing a security certificate is in this category. It's expected important work. It's work we can see and work we can forecast. This is the type of work that software engineers and architects sign up for. The other categories are work that the team has to do in order to get back to work in this category. Diagnosing or fixing or reworking past work we thought was done This is the first type of waste work. This is where we realize that something is broken. Something we thought was done is not actually done. Software that was supposed to work in a certain way doesn't. Something is missing. Or we are surprised that now that thousands of users use our software, our computing performance in some areas is terrible. We didn't count on some database tables growing to the size they have grown to. We are spending time figuring out why we have a problem. Then, once we have reproduced the problem, we are trying to redesign something in the software so that we fix the problem. We lament that we didn't catch this problem earlier. Or perhaps we just made a change and something else in a seemingly unrelated part of the software just broke, and we don't understand how they could possibly be related. Diagnosing or fixing the software as it runs in a production environment This category is all about production issues. No feature bugs or build breaks or bug reports from UAT testing. This category is for all the time spent investigating an issue in production. A user submits a trouble ticket. Or a piece of our software system goes down and has to be restarted. Or a user has a question that was escalated to second-level support. Not only do we need to spend time to figure out if it's just user education that accidentally made it to the software team's queue, but we also have to spend time learning about the part of the issue that may be a genuine defect. Part of this category of work is properly equipping our own company's customer support team with a better knowledge base so that they can handle more basic customer issues. Not all of them should be coming to the software team. Part of this alerts that the production environment is sending to the ticket queue. Also part of this is when executives or salesmen call for special support because they want to do a customer or investor demo and they need some extra data pushed into a production or test environment so they can do the demo. In general, this is the category for any time spent because...
