Fast software delivery in the DoD: Avoid these innovation shortcuts
The DoD software community should avoid getting caught up with innovation shortcuts, and instead, do the hard work to deliver software fast…forever.
The Marshmallow Test is a psychological test that is directly correlated with success in life. The test is quite simple - you ask a child “Do you want a marshmallow now, or do you want 2 marshmallows an hour from now?” The kids who want the marshmallow now tend to be the ones that want shortcuts and aren’t willing to do the hard work; they want the quick kill. The kids that hold out and wait for the 2 marshmallows realize they can double their outcomes if they don’t take the shortcut.¹ Avoiding the temptation of instant gratification will reap a 2x, 5x, 10x reward in the future.
How does this apply to a DoD digital transformation? Studies tracked these marshmallow test children into adulthood and the ones who chose not to eat the marshmallow tended to be more successful, had higher incomes, lower divorce rates, and obtained a higher status in society.
The “don’t eat the marshmallow” mantra can be applied to digital transformation as well.
Below are the 5 main “marshmallow” traps to avoid during your digital transformation journey.
- Getting drunk on continuous delivery
The CI/CD pipeline and the modern software delivery tools that support the CI/CD pipeline have made it relatively easy to get a single application into production. Getting drunk on continuous delivery means becoming so enamored with achieving continuous delivery for a single application that you repeat the same single app processes again and again without thinking about enterprise interactions. Following this anti-pattern, you will be left with a continuous delivery hangover when you go after a legacy system deprecation or system-of-system scaling.
Hard work required: Understanding the current system integrations, data model, and legacy interactions early. For any new software introduced into the ecosystem, push for early automation in regression tests and system integration tests. And, if needed, automate performance comparison tests against a legacy system vs. new capabilities. - Getting drunk on User Centered Design
Applying a UCD approach is a critical piece to avoid waterfall development. Its is an amazing process for building fast feedback loops with your customer, understanding the end-user journey, and rapidly obtaining “little r” requirements for your application. Getting drunk on UCD means that using UX design techniques for your entire requirement process and putting too much pressure on your discovery/framing, event storming, and continuous user feedback processes to get it right at both the local level and the enterprise level. Building enterprise software requires the orchestration of multiple applications (both legacy and greenfield) working together across an entire value stream to deliver end user outcomes. You cannot pull off this complex orchestration with UX design alone, and you cannot iterate yourself into building a new software ecosystem.
Hard work required: Do the hard work early to gain a deep understanding the current enterprise-level value stream before you can truly impact it. UX design does not replace the need for software architects, defining non-functional requirements (NFRs), building domain driven design (DDD) context maps, or creating your enterprise data model. - Setting up water-scrum-fall
The opposite of getting drunk on UCD is setting up water-scrum-fall processes. The instant gratification trap associated with water-scrum-fall happens when organizations revert back to their previously learned behaviors and think they can achieve digital transformation without complementing it with an acquisition transformation. A lot of teams state they want to go fast and be more productive, but when is comes to actually implementing agile processes they don’t change their own behaviors. Organizations revert back to their comfort zone and start building out a detailed systems requirements document (SRD) before any software is developed. Jez Humble defines water-scrum-fall the best: “Tons of upfront planning. Iterate. Tons of post code testing and deployment”.² Instead of this, software architects, systems engineers, and UX designers need to work together to create a system’s guardrails based off NFRs, DDD map, and a common data model; these should be treated as strategy and not iron clad requirements that have to be perfect before building things can start.
Hard work required: A digital transformation strategy which incorporates all aspects within your organization: engineering, acquisition, contracting, testing, cybersecurity, documentation, and oversight. The team will have to do the hard work of unlearning waterfall management processes and learn new agile management processes to successfully implement a digital transformation strategy. - Going new-new
It’s naive to think we can achieve enterprise level digital transformation without tackling legacy IT head-on. Going “new-new” is the strategy of greenfielding everything within the ecosystem. The instant gratification trap associated with going new-new happens when organizations think if they ignore legacy software it will simply go away on its own. Going new-new is what is implied when DoD leaders compare DoD digital transformations to Uber or Lyft; this analogy is like comparing apples to oranges. It’s true that Uber successfully implement a pure greenfield approach to ride sharing, but ride sharing is not as complex as DoD weapon systems. Uber resides within one classification domain, has a heterogeneous set of seniors (cell phones GPS data), a less complex fusing of -INTs challenge, less complex rules of engagement, requires depreciation of a legacy software system to scale, and only operates in two domains (land and space). And Uber has an operational budget of $14B/year to achieve its dominance! Lt Gen Haugh recently stated, “Our ability to get out from underneath our infrastructure is probably our biggest challenge.”³ If you chose to only go new-new for your DoD digital transformation, you will meet these IT challenges sooner than you think. Do the hard work early to identify these challenges so you can build a strategy to eliminate them.
Hard work required: To get out from underneath our existing infrastructure, we need a deep understanding of the current of mission and technical value streams. Understanding these values streams will help you identify where the bottlenecks with your ecosystem live. Current DoD enterprise software bottlenecks are tied to legacy IT: poorly defined interfaces, proprietary systems that prevent a centralized support structure, poor network speeds that drive on-site IT operations, etc. If you chose to only go new-new for digital transformation, you will meet these bottlenecks sooner than you think. Do the hard work early to identify these bottlenecks. This will ensure investment decisions will globally optimize the ecosystem vs. locally optimizing a part to claim a quick win. - Pushing the SaaS easy button
The “as a service” approach is an amazing business model to leverage for services below the value line. For DoD software development, I’m defining below the value line activities as necessary services for IT operations; and above the value line activities as necessary services for mission operations.
The “as a service” model is a double edged sword for above the value activities. Hitting the easy button to get pre-built modern software capabilities quickly comes with a great sacrifice of ownership at multiple levels: development, support, and potentially the data the capability produces/processes; this is a bad recipe for wartime success.
To win the next war, our digital force will need to adapt the mission capabilities it brings to the fight faster than the enemy, otherwise we will lose.
Hitting the “SaaS easy button” for mission capabilities will slow us down in wartime, because it will create black boxes inside our software ecosystem that only contractors understand. Additionally, we will never achieve Dr. Roper’s vision of owning the technical stack if we become over-reliant on contractors at mission level⁴.
Hard Work Required: The DoD needs to invest money it would spend on “above the mission line” Saas in creating a digital workforce. Creating a new generation of digital warfighters that organically understand the technology they bring into the fight will not be easy but it will a differentiator on the battle field.
Organizations needs to create a digital transformation strategy where near wins compound into long-term success.
To achieve this goal, the DoD should avoid the temptation of instant gratification and focus on a digital transformation strategy implementation.
If your organization needs help getting its digital transformation off the ground, Rise8 can help. We have a dedicated group of engineers and change agents to co-innovate with you. mnelson@rise8.us
- https://www.youtube.com/watch?v=47DmUM7MW7s&feature=youtu.be
- https://twitter.com/agilealliance/status/598910669170290688?lang=en
- https://breakingdefense.com/2020/10/aging-air-force-it-biggest-challenge-to-jadc2-progress/
- https://www.af.mil/News/Article-Display/Article/2350344/acquisition-chief-calls-for-disruptive-agility-new-digital-paradigm/
