Overnight, every company in the world became a software company. Those companies are either on the journey to becoming a world-class software company or they are going extinct. One key step in a successful journey requires connecting the daily work done by software teams to corporate goals and embracing autonomy with alignment.
Software development is a business differentiator that requires strategic investments to improve the bottom line. Having worked in all aspects of the software development lifecycle, I know most people in the industry think in terms of two types of deliverables – creating new features and fixing bugs. In reality, that’s too limiting. I hear management complain that developer productivity is down simply because developers are responsible for what appears to be everything now and may spend less than 50% of their time writing code. The amount of time a developer has available for coding is tracked, but many other activities are hidden and considered “tax” of the organization, like caretaking the pipeline, fixing problems with your environment and helping testers.
Developers want to write code. The business wants them to write code. Customers want the solutions their code provides. That means we need to understand where developer time is actually being spent and give them an opportunity to write code for time-consuming manual activities that can be automated.
Four fundamental development categories
For product management to be effective, four types of work need to be visible, supported, and funded.
Features. Delivering cutting-edge features is the fun part of a developer’s job. Creativity takes time and delighting customers isn’t easy in highly-competitive markets. Resources need to be invested in developing new or improved functionality, usability, flexibility, and other customer-friendly features.
Defects. I’ve heard it said that today’s features are tomorrow’s bugs. Fixing defects, bugs, and other issues is a routine part of software development. Releases often go out with bugs, so your team may be putting out fires related to your releases and those of your vendors and partners. Identifying and eliminating problems that hurt the customer experience is important, but they need to be weighed against other priorities.
Risk. Risk-related activities represent the majority of the hidden work that developers do. Improving the software engine to produce more reliably involves setting up guardrails and security for better deployment. DevOps practices push for complete automation of manual checklists that have been used to validate items, including whitesource library checks, open source license validation, testing, deployments, and code analysis. Developers WANT to automate them, and implementing code that does the checks is fun.
Technical debt. As soon as something is built, the need for modernization is a possibility as the world changes. The technology gap between modern standards and legacy systems grows over time, so it’s important to regularly assess the tradeoffs between investing in patches or updates and rethinking the design given new learnings and needs. This includes build vs buy decisions.
Balancing development work investments
Peter Hyde of Gartner defines a work profile as, “The proportion of each type of work item delivered in a time period by the software value stream.” Too much focus on one area can throw the organization out of balance, making it harder to deliver customer value. For example, if too much time is focused on features/defects, you’ll end up with a fragile development environment straddled with technical debt, ultimately killing its ability to deliver new features.
Start by identifying the percentage of your resources going into adding features, fixing defects, reducing risk, and addressing technical debt to understand your current work profile, which is also known as your work distribution. This may take some digging if visibility is lacking, especially if everything is currently being categorized under features or defects. This will give you a baseline for analysis and allocation of future spending, which is based on your goals.
If the goal is to make significant future investments into sets of components, continual modernization of the technology base (technical debt) and refinement of the software delivery engine (risk) will reduce the overall “cost” and time of delivering new features or fixing bugs. Investments into risk may also increase the ability to obtain certifications, improve agility to react to outages, reduce MTTR, and boost customer trust.
Ultimately the team, typically driven by product, must make tradeoffs with the limited resources they have. The team needs a way to tradeoff investing into better security automation vs improving the technology stack vs just adding features and fixing bugs.
Connecting value stream management and outcome mapping
Outcomes are the core of delivering value to the customer, and every outcome can be supported by one of the four types of work. Teams should think hard about the outcomes they are working towards. They need to clarify why items are important, identify obstacles, explore how to learn more, and identify how to measure progress towards the outcomes.
The work of product management is central to translating the outcomes into the core work types. Ultimately they are responsible for justifying and defending investment decisions. Value stream management helps in this journey by providing the data and associated visualizations connected to outcomes.
Investment strategy advice
Balancing work is essential to effective product management. Start with your outcomes, but communicate in terms of the work distribution. You know the strategy you’re trying to accomplish from a business perspective. Translate that for your individual product managers, so they can connect those business outcomes to actual work that has to get done.
To keep everyone on the same page, train your executive team on how to translate outcomes to the work profiles, and proactively sell why the tradeoffs were made in the first place between the various types of work. Finding the right balance will make a developer’s job more enjoyable while also improving customer value.
The post Beyond features and bugs: Expanding how to evaluate development investments appeared first on SD Times.
from SD Times https://ift.tt/i310ykN
Comments
Post a Comment