You oversee software development as an executive, investing a lot of money, but you are not getting the desired results, and you don’t know why. Can you relate to this?
Your software team may talk about methodologies like Agile and Scrum, but you don’t see them hitting planned milestone dates. The team misses or changes commitments they have made on short notice and there are few excellent answers why.
Software seems like a “black box”, and only people inside the software team may understand any of it. Your pushback is met with the spoken or unspoken message of: “You just don’t get it. This stuff is complicated. We can’t just get it done tomorrow. It’s gonna take more time.”
When you ask, “When will it be done?”, you get answers like, “I can’t tell you.” You need to find out what they can tell you, and implement a fail-safe way to determine the answers. Or you risk losing your project funding. Or worse—your job.
Software Leadership Webinar Series
Thought Leadership + Interactive Events
Oversee Software Development by Getting Down to Basics
The answer is simple and does not require a magic method. Software teams have used every methodology under the sun well and every methodology poorly. There are many methodologies that do well at a conference or in a book. Some teams have exceptional industry success stories and attribute it to using a particular approach. Another team may use the same methodology but fail because of poor leadership and an unorganized process, resulting in a disastrous project.
So, if you find your team in one of these situations, go back to basics. You are a business leader, and you have overseen very complicated initiatives involving lots of people and many moving parts. You know what should happen.
When you oversee software development, you must get down to basics.
Any team that is charged with producing some large outcome breaks that outcome into smaller pieces and then measures how much of that large outcome is delivered each hour, each day, and each week.
Think of a sales team. The sales team is supposed to close several million dollars in sales within a certain period. It’s not all done in one fell swoop. It’s broken down. For example, average deal size, number of deals needed, pipeline size, number of potentials in the pipeline, activities that lead up to getting a potential opportunity in the pipeline … It’s a big outcome that must be broken down.
With software development, it’s the same thing. If you have a large software project, chances are you already have an extensive list of features and a backlog of features to be built. So, to get a sense of it, you need to break it down just like you do in any other department.
Gathering Data is Essential to Oversee Software Development
Here is the process for gathering data when you oversee software development.
First, you need to understand what your current capacity is. Take a count of how many people you have dedicated to the software project. You have some number developers, some number of analysts, some number of various specific competencies … maybe data professionals, data engineers, and an architect. Whatever skill sets you have, take stock of what the capacity is so you know the total number of man hours. If it makes sense for your situation, break that number down into developers, designers, and other subsets of skills.
Next, figure out your baseline throughput with the capacity that you have funded. Just take it week by week and figure out how many items were delivered. Delivered means someone is using the software, not just that they have marked the item as “code complete.” Count the number of items that went into active usage last week, put it on a spreadsheet, and do that for each week for which you have data.
Now you have a weekly throughput metric and a capacity metric. Your capacity metric can be translated into cost because you know your hourly labor costs for the capacity based on salaries and contract price.
Once you have the throughput and capacity, you can calculate metrics such as hourly throughput, labor hours per unit of throughput, or dollars per unit of throughput. The unit of throughput is a new feature. Because you have so many features, just ignore any estimates that the software team has placed on it.
Executives Oversee Software Development by Analyzing the Process
Now that you understand your capacity, your throughput, and the number of hours or dollars it takes to get a unit of throughput, which is another feature, start analyzing your process. Get some outside help and start tweaking the process.
Here is a scenario that I’ve seen happen more likely than not. You take the average throughput over the last month and you extrapolate the data. Maybe you have 100 or more items in your backlog that need to get done in the next three to six months. Then you realize, moving at the current rate, you will not get all this done in six months. This will take two to three years!
Just doing that analysis will be a huge wake-up call. Some people on the software team probably already know this in their gut. They just don’t have the wherewithal to do the quantitative analysis to put some numbers to it.
This is the foundation of the software schedule forecast you need as you oversee software development. The project manager should make a forecast and scorecard to keep the project on schedule. It should include:
- weekly throughput,
- and revised forecasts based on changes in throughput.
With that, you can do several things.
- Trim the scope
- Increase capacity
- Make process changes that increase the number of hours per unit of throughput.
Maximizing the throughput per unit of labor is the goal, so you can optimize every throughput-based process.
So, if you assess your team and don’t think you have the skill set to accomplish these things—do what many companies do. Consider engaging a fractional CTO or software consultant that can jumpstart the optimization of your processes.
Increasing Software Delivery Speed is the Result Executives Want
One way to increase speed, or increase throughput, is by adding software architecture to the feature analysis process before coding.
One attribute of a slow-moving team is assigning features to programmers before the team understands how to approach that item. This is especially true if it’s new, something they have never coded before. Instead of the programmer working on it and building it, they sit there doing research. Plus, it’s most likely done by a person who is the least capable of figuring out viable options.
So, identify that work and put it in the hands of an experienced person—a software architect—who can evaluate the options and produce some simple proofs of concept. You should expect a software architect to: look at the big picture to minimize the amount of work needed to be done and minimize the amount of effort needed to deliver the functionality.
Then this approach can be given to the developers. This will alleviate the need for your developers to spend time trying to figure out how to approach the problem. Thus, creating greater throughput.
Do you want to empower your software team
to be effective:
moving fast with high quality?
This is How an Executive Should Oversee Software Development
You might not be aware of how much of the team’s capacity is not being used to build the software. The team diverts a certain percentage of its capacity to fixing bugs from the features that are being used in production. So, you think you have a certain amount of capacity going to software development, but you probably don’t.
Until you’ve quantified the amount of your capacity that is being diverted to break fix, then you’re not going to be looking at it with a clear picture. Your project manager should report weekly on the percentage of capacity being used for feature development and bug fixes.
Your software team may lack experienced leaders in engineering and software architecture. This results in lower build capacity because of programmers attending analysis meetings. It diverts a percentage of your capacity from development to fill other gaps in your organization. You want to quantify what that is so that you can decide what to do about it. That is why the weekly project scorecard is important.
These are the things you should expect from any project as you oversee software development.