I’ve spent much of my 20-year career enabling teams to iterate and learn by shipping. I’ve had the pleasure of working with passionate, high-performing development teams, and I’ve trained and coached many more in Scrum and Agile. And each time, I’ve seen the value outside perspective can give to smart but struggling teams.
I was inspired by the book Accelerate: The Science of Lean Software and DevOps and all the stories it provides of the absolute top-tier of functioning IT organizations. Unfortunately, for too many, those stories are aspirations so far in the future that it’s hard to know what positive steps forward would look like. So how healthy is your development organization? What does the next step toward consistent, efficient, and confident development practices look like for you?
I created the following Development Capabilities Model to help folks answer just those questions. Check out this article, and if you’d like more help figuring out where you land in the model, grab free assessment tool that will provide specific, research-based recommendations for your exact situation.
This model is broken out into four major sections:
Measurement
Reliable measurements in software development can be challenging to identify and maintain. Advancing in this area often means automating or surfacing reliable measures that occur naturally from your process—manual effort should be avoided as it causes ongoing effort and is easily stopped or missed.
Where do you think your organization stands in this model for Measurement?
- Nascent
You are tracking little to no metrics, or your metrics are considered to negatively impact organizational health. You’re not currently using measurements to inform decision-making. You have no empirical understanding of how decisions and changes impact your organization.
Your teams and leadership rely solely on intuition and gut instinct to make future decisions and determine what has been successful in the past.
Your measurements and how you use them often harm organizational health.
- Tactical
You have insight into the work you’re completing, but your measurements are not providing insight into how you’re doing to solve problems. Your measurements are specific to processes and tools and oriented toward output, instead of outcomes.
Your teams and leadership may track progress with measurements, but those measurements do not inform future decisions or help you determine what has been successful.
Your measurements or your use of them can often harm your organization’s or its members’ health.
- Strategic
You might have some effective organizational measurements that allow you to change how you work and see the impact of those changes. These measurements might be hard to gather and are not part of the natural process, and there might be better measures that you could use.
Your teams and leadership find measures generally helpful in decision making, but some measurements may be harder to gather or are not part of the natural process.
Your measurements or your use of them mostly improve the health of your organization and its members.
- High-Functioning
You are currently using effective measurements that are tied into your process. These metrics are focused on global outcomes of the organization, and they are gathered through your natural processes. Metrics are regularly updated, and they are actively used to make informed decisions.
Your teams and leadership have easy access to up-to-date measurements. You use your measurements to inform decision-making and to evaluate what has been successful.
Your measurements are used to improve the health of your organization and its members.
Technical Processes
Long, isolating technical practices which create opportunity for risk hurt teams. To advance your technical practices, we recommend setting your goal to be delivering small, iterative changes with confidence. Look for ways that automation and insight can allow you to move quickly and confidently with frequent integrations and feedback opportunities.
Where do you think your organization stands in this model for Technical Processes?
- Nascent
Your technical practices are mostly manual and create a significant opportunity for error. Your practices differ widely between teams working on the same code base. Your technical practices do not include automated testing or an automated build and deploy pipeline.
Your feature deployment is usually delayed to accommodate quality checks. This results in a large batch of changes in each deployment. Your build and deploy pipeline is mostly or entirely manual and error-prone.
Your team is not focused on, encouraged toward, or self-motivated to improve technical practices.
- Tactical
Your technical practices include some automated practices, though there are still significant steps that are manual and error-prone. Your practices sometimes differ between teams working on the same code base. Automated tests and a build and deploy pipeline are being created but are either not yet reliable or do not provide much confidence in the health of the system.
Your feature deployment is often delayed to accommodate quality checks. This results in large batches of changes. Your build and deploy pipeline is mostly manual and error-prone.
Your team is not focused on high-quality technical practices. Those technical practices that might otherwise benefit delivery are done in name only or to appease leadership.
- Strategic
Your technical practices rely on automation, which quickly provides confidence in quality. Your practices still sometimes differ between teams working on the same code base, but your teams are actively working toward improving these. Automated testing and a build and deploy pipeline are mostly reliable and provide good confidence in the health of the system.
Your mostly automated build and deploy pipeline delivers functionality frequently and effectively to a pre-production environment, but production deploys are infrequent. These production deployments are predicated on manual reviews that occur over a large swath of the product.
Your team feels ownership of the entire delivery process, and they’re continuously looking to improve. Distinct lines of responsibility may impede their ability to adopt new practices or improve existing ones.
- High-Functioning
Your technical practices rely on highly valued, fast automation for most repetitive tasks, and the team is confident in the outcomes. Your practices are cohesive between teams working on the same code base, and your team is continually looking to improve their practices. Automation, including testing and a build and deploy pipeline, provides high confidence that the system is healthy.
Software deployment can happen at any moment because the build and deploy pipeline surfaces the quality of the software, making the team confident. The teams can deliver at their own pace and are not reliant on each other to deliver.
Your team feels a sense of ownership over the entire delivery process, and they’re continuously looking to improve. Very little impedes the team’s ability to adopt new practices or improve existing ones. Your team has common patterns of interaction with everyone and has a clear understanding of the software’s health.
Architecture
While collaborative insight during planning and feedback is important to shipping valuable work, you don’t want it to hinder your actual delivery. When advancing your architecture, look to create seams in your system that allow teams to deliver unencumbered. The goal is for your teams to be able to execute and deploy on their own time cycle.
Where do you think your organization stands in this model for Architecture?
- Nascent
Your architecture is a hindrance, and your teams are constantly fighting it to get features out.
You can only deliver individual features by touching or changing many parts of the system, and this may cause ripple effects throughout the entire system. Deploying is often feared and delayed because it is a difficult or complex process.
Your teams are unable to work on only their part of the software because a change in one part of the system often results in unanticipated or uncaught issues in other parts of the system. Debugging in any part of the system requires knowledge of the whole system and historical background. Teams must use the tools that are already in place, even if they are not the best tool for their problem.
Your testing practices require that the entire system is running in order to test any new changes. It’s unclear how changes in one part of the system may impact other parts of the system.
- Tactical
Your architecture is well organized, but your teams are fighting with the dependencies between parts.
You can deliver individual features somewhat independently, but tight collaboration and communication are needed. Deploying is often feared and delayed because it is a difficult or complex process.
Your teams are working with one another, and each system has a clear owner. However, a lot of collaboration and communication overhead is needed to deliver new functionality. Team tools are dependent on agreement across teams.
Your testing practices require that the entire system is running in order to test any new changes. Some tests are automated and give some confidence in the health of the system.
- Strategic
Your architecture is flexible, but your teams still need to coordinate to deliver changes.
You can deliver features as part of frequent but scheduled deployments. Your system is becoming more decoupled, allowing most deployments to happen with confidence and without tight coordination—but not all of them yet.
Your teams can mostly choose the tools best suited for their part of the system.
Your testing practices allow some (but not all) parts of the system to be tested independently and on-demand. It is mostly clear how a change will impact other systems.
- High-Functioning
Your architecture allows the software to move at the pace of business, and your teams can integrate changes quickly as they are needed for users or for the business.
You can deliver features frequently and on-demand. The system is decoupled so you can deploy changes with confidence and without tight coordination between teams.
Teams are able to bring in tools that will solve their unique problems. New teams can work on the project without needing to know the whole system or all the historical background in order to contribute to the overall system.
Each part of the system can be tested independently and on-demand. It is clear how a change will impact other systems.
Security
Software security is under more scrutiny than ever (with good reason). To advance, plan software security practices at the very beginning of a project and integrate them into the day-to-day processes of software delivery.
Where do you think your organization stands in this model for Security?
- Nascent
InfoSec is a reactionary afterthought. Your team does not actively pursue InfoSec as a part of the software delivery process.
Your team relies on InfoSec tooling or frameworks when issues arise, but they are not investing in secure development practices to improve InfoSec.
- Tactical
InfoSec is considered at the end of the release process after the software has been built, possibly as a pre-release check.
Your team might have an awareness of InfoSec, but they do not include secure development practices early and often in the software delivery processes. InfoSec is not considered as part of the software architecture or development practices. Instead, your organization likely pursues penetration testing.
- Strategic
InfoSec is considered often at various stages of your software delivery process. Your team might have an explicit, documented InfoSec strategy that is applied to the software delivery process.
Your team considers secure development practices when building experiences, but security is not always thought of as a part of each individual feature or piece of functionality. InfoSec is usually considered as part of the software architecture or development practices.
- High-Functioning
InfoSec is considered all the time by your team. Your team has an explicit, documented InfoSec strategy that is applied to the software delivery process.
Your teams use secure development practices to build secure experiences and have clear insight into the security of their systems all the way to production. Your team is continuously improving their understanding of InfoSec through training, tools, and techniques.
Want More Specific Advice?
Grab your free copy of the Development Capabilities Assessment—learn where your organization is today and the best next steps to see the benefits of a healthy, thriving development organization.
Sparkbox’s Development Capabilities Assessment
Struggle to deliver quality software sustainably for the business? Give your development organization research-backed direction on improving practices. Simply answer a few questions to generate a customized, confidential report addressing your challenges.
