How “Constant State of Ship” Drives Transformative Practices

Introduction

In the relentless pursuit of delivering value to customers, with unparalleled speed and reliability, the software development world has yet to widely embrace a revolutionary principle – the “Constant State of Ship”. This state, where software artefacts and products are perpetually poised for release into production environments within just 15 minutes’ notice, has emerged as a driving force behind best practices that enable true continuous deployment. Remarkably, this groundbreaking concept formed the foundation of the pioneering “Javelin” software development approach, a visionary approach conceived by FlowChainSensei (Bob Marshall) at Familiar circa 1996 and onwards, foreshadowing the industry’s even-now-yet-to-be-realised embrace of these practices.

The Power of “Constant State of Ship”

The “Constant State of Ship” serves us as an unyielding forcing function, inviting teams to adopt and adhere to a comprehensive set of best practices that catalyse the seamless flow of software into production. Let us explore how this principle reinforces each of thirteen fundamentals of Continuous Delivery (hat tip to Dave Farley):

The 13 Fundamentals Enabled

1. A Repeatable, Reliable ProcessWith the ever-present possibility of an imminent release, teams may choose to establish a well-defined, automated pipeline for building, testing, and deploying their software. This process needs to be repeatable and reliable, minimising the risk of human error and ensuring consistency across releases.

   The “Constant State of Ship” mindset suggests that teams have a streamlined, automated release pipeline that can be triggered at any moment. Manual steps and ad-hoc and emergency exception procedures become liabilities, as they introduce variability and increase the chances of mistakes during deployment.

   To achieve this repeatability and reliability, teams are supported to invest in build automation tools, automated testing frameworks, and deployment automation pipelines. Every step of the release pipeline can be codified, documented, and thoroughly tested to ensure predictable outcomes each time.

   Moreover, the “Constant State of Ship” principle fosters an environment of continuous learning and improvement. Any failures or issues encountered during a release are promptly analysed, and the release process is refined to prevent future occurrences. This cycle of continuous feedback and optimisation ensures that the release pipeline remains reliable and efficient, even as the codebase and systems evolve over time.

   By operating in a “Constant State of Ship” mode, teams are invited to treat the release pipeline as a critical component of their software development lifecycle, investing the necessary resources and effort to make it repeatable, reliable, and capable of delivering changes to production environments at a moment’s notice.

2. Automate All the ThingsIn a “Constant State of Ship” paradigm, manual interventions become significant bottlenecks and risks, hindering the required velocity and reliability. Automation becomes imperative, spanning every aspect of the delivery pipeline, from code compilation to infrastructure provisioning. The threat of an imminent release leaves no room for error-prone manual processes that could delay or derail a deployment. Teams must automate build processes, test execution, environment provisioning, deployment steps, and release orchestration to ensure consistency and minimise the risk of human error.
3. Maintain a Releasable StateThe core tenet of “Constant State of Ship” requires that the codebase and associated artifacts remain in a perpetually releasable state. This principle invites teams to address issues promptly, maintain a high level of code quality, and vigilantly consider the accumulation of technical debt. Any defects, bugs, or instabilities in the codebase could potentially disrupt an imminent release, leading to costly delays or failures. Teams must adopt practices like continuous integration, automated testing, and ensemble programming to ensure that the codebase remains in a stable, deployable state at all times.
4. Focus on Robust (Real) Quality Assurance

   In the “Constant State of Ship” paradigm, where the possibility of demand for an immediate release is ever-present, quality assurance cannot be treated as an afterthought. “Constant State of Ship” invites the integration of quality practices throughout the entire development lifecycle, ensuring that quality is baked into the software from inception to deployment.

   While testing plays a role, it is merely one facet of a comprehensive quality assurance strategy. Teams may choose to adopt a holistic approach that emphasises quality as a continuous, pervasive practice woven into every aspect of the development approach.

   This begins with cultivating a culture of quality-driven development, where every team member participates in collective ownership and responsibility for the quality of their work. Practices such as clarity of (quantified a la Gilb) requirements, ensemble programming, peer code reviews, adherence to coding standards, and continuous static code analysis can help identify and mitigate potential issues early in the development cycle.

   Furthermore, “Constant State of Ship” invites teams to embrace principles of iterative and incremental development. By breaking down complex features into smaller, manageable, well-bounded increments, teams can more effectively manage quality risks and ensure that each increment and subsystem meets the required quality criteria before progressing to the next.

   Continuous integration and deployment pipelines play a pivotal role in this quality assurance strategy, enabling teams to continuously validate and verify the software’s functionality, performance, and stability with each incremental change. These pipelines automate the execution of various quality checks, including unit tests, integration tests, and performance tests, providing real-time feedback and enabling teams to address issues promptly.

   However, quality assurance extends beyond mere testing alone. Teams have the opportunity to adopt a holistic approach that encompasses design practices, architectural decisions, and operational readiness. By considering quality implications at every stage of the software development lifecycle, teams can proactively identify and mitigate potential risks, ensuring that the software remains in a releasable state at all times.

   “Constant State of Ship” elevates quality assurance to a core discipline that permeates every aspect of the software development effort. By fostering a culture of quality-driven development and adopting continuous quality practices, teams can attend to the needs of all the Folks That Matter™, with confidence, knowing that their software meets the highest standards of reliability, stability, and performance.

5. Implement Robust Deployment PipelinesAchieving a “Constant State of Ship” necessitates the implementation of robust deployment pipelines. These pipelines automate the entire process of building, testing, and deploying software changes, ensuring consistency and minimizing the risk of errors. With the ever-present possibility of an imminent release, teams cannot afford manual, error-prone deployment processes. Automated deployment pipelines provide a standardised, repeatable path to production, reducing the likelihood of failed or inconsistent deployments.
6. Monitor the PipelineRegular smoke testing of the deployment pipeline is crucial in a “Constant State of Ship” mode. This practice helps catch issues early, before they can impact production environments, ensuring the pipeline’s reliability and preventing costly downtime. The possibility of an imminent release amplifies the importance of having a thoroughly validated deployment pipeline. Smoke tests act as a safety net, verifying the integrity of the pipeline and identifying any potential issues that could disrupt a deployment.
7. Integrate ConstantlyThe “Constant State of Ship” mindset encourages teams to integrate their changes frequently, often multiple times per day. This practice surfaces issues early, reduces merge conflicts, and ensures that the codebase remains in a releasable state, ready for deployment at any given moment. Infrequent integration can lead to divergent codebases, making it harder to identify and resolve conflicts, which could potentially disrupt an imminent release. By integrating frequently, teams can maintain a stable, unified codebase that is always primed for deployment.
8. Evolve the ArchitectureMaintaining a “Constant State of Ship” over time invites the continuous evolution of the system’s architecture (see also: Reverse Conway). Are teams prepared to refactor and adapt their architectures to accommodate new requirements, technologies, and scaling needs, without compromising the ability to release rapidly and reliably? As products grow and evolve, architectural decisions made early on may become hindrances to continuous deployment. The “Constant State of Ship” principle invites teams to proactively evaluate and evolve their architectures, ensuring that they remain flexible, scalable, and conducive to rapid releases.
9. Leverage Data EnvironmentsWith the constant possibility of an imminent release, the ability to provision and manage data environments becomes critical. Teams may choose to adopt practices like database versioning, data seeding, and data masking to ensure consistent and reliable testing and deployment across environments, minimising the risk of data-related issues in production. The “Constant State of Ship” mindset invites a robust data management strategy that enables seamless and repeatable deployments, regardless of the data complexities involved.
10. Mirror Production EnvironmentsTo minimise the risk of issues arising from environmental differences, teams operating in a “Constant State of Ship” mode may choose to ensure that their development, testing, and staging environments closely mirror production environments in terms of configuration, data, and infrastructure. This practice helps identify and address potential issues before they impact the live production system. The possibility of an imminent release heightens the importance of having production-like environments, as any discrepancies could lead to unexpected behavior or failures during deployment.
11. Codify InfrastructureManually provisioning and configuring infrastructure for each release becomes a significant bottleneck when operating in a “Constant State of Ship” mode. Adopting Infrastructure as Code (IaC) practices, where infrastructure is defined and managed through code, enables teams to provision and tear down environments rapidly and consistently, minimising delays and reducing the risk of configuration drift. The “Constant State of Ship” principle invites a high degree of automation and repeatability in infrastructure management, making IaC a beneficial practice for ensuring rapid, reliable deployments.
12. Foster Collaborative OwnershipAchieving a “Constant State of Ship” invites a high degree of collaboration and shared ownership among team members. Siloed responsibilities and knowledge become obstacles to rapid delivery. Teams may choose to adopt practices that promote collective code ownership, cross-functional collaboration, and shared understanding of the codebase and delivery processes. The “Constant State of Ship” mindset invites a culture of collective responsibility, where all team members are empowered to contribute to and understand the entire delivery process, enabling seamless and efficient releases.
13. Continuous ImprovementOperating in a “Constant State of Ship” mode exposes inefficiencies and bottlenecks in the delivery pipeline and processes with uncompromising clarity. Teams may choose to embrace a culture of continuous improvement, regularly reviewing their practices, identifying areas for optimisation, and implementing changes to enhance their ability to deliver value rapidly and reliably. The constant presence of imminent releases acts as a driving force for continuous improvement, encouraging teams to continuously refine their processes, tools, and practices to achieve higher levels of velocity and quality. FlowChain was designed to systematise this very purpose.

The Visionary “Javelin” Approach

The “Javelin” approach (initally named “Jerid”) pioneered by me and my teams at Familiar from 1996 onward, was truly ahead of its time, recognising the transformative power of the “Constant State of Ship” mindset. By enshrining this principle as a cornerstone from its inception, “Javelin” has paved the way for the modern continuous deployment practices that have since become poised to gain industry standard status. This pioneering approach, along with FlowChain and e.g. Prod•gnosis, Flow•gnosis, Product Aikido, etc. exemplifies the spirit of continuous improvement intrinsic to the “Constant State of Ship” principle, ensuring its enduring relevance and impact.

Deep Cultural Implications

Reshaping the Culture and Mindset

Adopting the “Constant State of Ship” principle suggests a profound transformation that extends way beyond technical practices and processes – it hints at a seismic shift in the culture and mindset of software development teams and their parent organisations. This metamorphosis permeates every aspect of the organisation, reshaping shared assumptions, beliefs, and ways of working. However, navigating such a profound cultural shift can be a daunting challenge, often met with resistance and inertia.

This is where the discipline of organisational psychotherapy plays a pivotal role. By applying principles from psychotherapy, sociology, and group dynamics, organisational psychotherapy facilitates teams’ cultural and mindset shifts required to embrace the “Constant State of Ship” paradigm smoothly and effectively.

A Culture of Ownership and Accountability through Empowerment

The “Constant State of Ship” mindset fosters a culture of collective ownership and accountability. Organisational psychotherapy techniques, such as participative decision-making and fellowship, empower team members to take responsibility for the quality, stability, and deployability of the codebase and overall product. This sense of empowerment cultivates a culture of shared ownership, where individuals proactively address issues, collaborate across boundaries, and collectively strive for continuous improvement.

Embracing Transparency and Trust

Maintaining a “Constant State of Ship” requires a high degree of transparency and trust among team members. Organisational psychotherapy practices, such as surfacing shared assumptions and beliefs, encourage open communication and facilitate the identification of problems and risks early. By fostering an atmosphere where team members feel comfortable expressing concerns, sharing mistakes, and seeking help, a culture of transparency and trust emerges, enabling teams to collectively address challenges and ensure the software remains in a releasable state.

Prioritising Continuous Learning

The “Constant State of Ship” principle instills a mindset of continuous learning and improvement. With each release, teams gain valuable insights into their processes, tools, and practices. Embracing new shared assumptions becomes essential, as teams must continuously refine and adapt their approaches based on feedback and lessons learned. This culture of continuous learning fosters an environment of experimentation, where failures are embraced as opportunities for growth, and success is measured by the ability to deliver value rapidly and reliably.

Aligning Towards a Common Goal

Ultimately, the “Constant State of Ship” principle unifies teams around a common goal: meeting the needs of all the Folks That Matter™ with unparalleled speed and reliability. This shared mission transcends individual roles, responsibilities, and technical disciplines. It creates a sense of collective purpose, where every team member’s contribution, regardless of their specific function, is valued and recognised as essential to achieving this overarching objective.

By leveraging organisational psychotherapy techniques, organisations can accelerate and streamline the cultural and mindset shifts required to embrace the “Constant State of Ship” paradigm. This discipline not only makes the transition quicker and easier but also more cost-effective, as it addresses the root causes of resistance and inertia, facilitating a smoother and more sustainable transformation.

By reshaping the culture and mindset of software development teams, the “Constant State of Ship” principle cultivates an environment conducive to continuous deployment success. It fosters a sense of collective ownership, transparency, continuous learning, and shared purpose – traits that are indispensable in today’s rapidly evolving software landscape.

Embracing the Future

When the ability to swiftly adapt and innovate is paramount, the “Constant State of Ship” principle emerges as a beacon, guiding software development teams towards a future of quiet competence and competitiveness. By embracing this mindset, as exemplified by the visionary “Javelin” approach, teams can unlock the power to attend to folks’ needs with unprecedented speed, reliability, and quality – solidifying their organisation’s position as industry leaders in the software development arena.