Archive

Product development

Code for the Machines: The Rise of AI-Readable Programming

March 27, 2024
Agile, AI, Antimatter principle, Article, Attendants, Innovation, Product development, Software development
Leave a comment

Code for the Machines: The Rise of AI-Readable Programming

The Future of Coding: Embracing AI Readability

In the domain of software development, the concept of writing code primarily for artificial intelligence (AI) readability and maintainability is an intriguing prospect that will influence the future of coding practices. While human-readable code remains the standard approach as of August 2023, the rapid advances in AI technology suggest that a paradigm shift may be on the horizon.

The Rise of AI-Centric Coding Styles

As AI systems become increasingly sophisticated and integrated into software development workflows, the need for code that caters to the strengths of these systems may become more pressing. This could lead to the emergence of coding styles specifically tailored for AI readability and maintainability over (sic) human readability and maintainability, encompassing the following characteristics:

Increased Abstraction and Modularisation

AI systems may thrive on highly modularised and abstracted code, where individual components are clearly separated and encapsulated. This could result in a coding style that emphasises smaller, more self-contained units of code with well-defined interfaces, promoting better organisation and encapsulation.

Formalised and Explicit Syntax

While human programmers often rely on conventions and implicit understandings, AI systems may benefit from a more formalised and explicit syntax. This could involve additional annotations or metadata that make the semantics of the code more explicit, catering to the needs of AI systems for unambiguous interpretation.

Pattern Recognition Optimisation

AI systems excel at recognising patterns, so the coding style could be optimised for this strength. Consistent naming conventions, structural similarities, and other patterns that can be easily recognised by AI systems may become more prevalent.

Reduced Redundancy (DRY)

AI systems may be better equipped to handle and maintain code with minimal redundancy, leading to a coding style that emphasises code reuse, shared libraries, and other techniques to reduce duplication.Such techniques will likely make the code more or less illegible to humans, at least to unaided humans.

Documentation Tailored for AI Comprehension

In an AI-centric coding paradigm, the traditional concept of human-readable documentation and comments may become obsolete. Instead, the emphasis would shift towards creating self-documenting code that can be seamlessly interpreted and maintained by AI systems. This could involve incorporating structured annotations, metadata, and other machine-readable elements directly into the codebase.

The documentation process itself could be automated, with AI algorithms capable of parsing the code structure, analyzing the annotations, and generating comprehensive documentation tailored specifically for AI comprehension. This documentation would be optimized for pattern recognition, logical inference, and other capabilities that AI systems excel at, rather than catering to human readability.

Moreover, the maintenance of this documentation could be handled by AI systems, ensuring that it remains up-to-date and consistent with the evolving codebase. As changes are made to the code, the AI-driven documentation would automatically reflect these modifications, eliminating the need for manual updates and reducing the risk of documentation becoming outdated or inconsistent with the actual implementation.

This approach could potentially revolutionize the way documentation is created, maintained, and consumed, shifting the focus from human readability to machine interpretability, and leveraging the strengths of AI systems to streamline the documentation process.

The Hybrid Approach

While the prospect of AI-centric coding styles is intriguing, it’s important to note that a hybrid approach may emerge as a stop-gap or transitionary approach, where code is written to be readable and maintainable by both humans and AI systems. This approach could leverage the strengths of both parties, ensuring that the code remains accessible to human developers while also catering to the needs of AI systems. I suggest this duplication of effert will soon rankle.

Conclusion

As AI technology continues to evolve, the way we approach coding will undergo significant transformations. While the shift towards AI readability and maintainability is still a hypothetical scenario, it is an exciting prospect that could revolutionise the software development industry. Regardless of the direction this trend takes, one thing is certain: the future of coding will be shaped by the interplay between human ingenuity and the capabilities of AI systems. And we can finally discard the shackles of so-called agility, too – in favour of doing what humans do best: attending to folks’ needs.

Here’s a postscript illuminating the use of AI to write code in a style where readability and maintainability by humans is not the main focus:

Postscript: AI-Generated Code for Machine Consumption

In addition to the prospect of writing code specifically tailored for AI readability and maintainability, the advancement of AI technology also raises the intriguing possibility of AI systems themselves generating code in a style optimised for machine consumption, rather than human readability.

As AI systems become more sophisticated in their ability to understand and translate natural language into code, they could potentially generate programs that prioritise efficiency, conciseness, and optimisations over human-friendly constructs. This AI-generated code might forgo traditional conventions and practices aimed at enhancing readability for human developers, instead favoring structures and patterns that are more readily interpretable and maintainable by themselves and/or other AI systems.

Such AI-generated code could be highly compact, with minimal redundancy and a heavy reliance on abstraction and modularisation. It might incorporate complex mathematical models, advanced algorithms, and unconventional coding techniques that leverage the strengths of AI systems while potentially sacrificing human comprehensibility.

While this concept may seem counterintuitive to traditional software development practices, it could open up new avenues for highly optimised and efficient code generation, particularly in domains where performance and scalability are paramount, such as high-performance computing, big data processing, or cutting-edge scientific simulations.

Moreover, as AI systems become increasingly integrated into the software development lifecycle, they could potentially maintain and evolve this AI-generated code autonomously(?), with minimal human intervention. This could lead to a paradigm shift where the primary consumers and maintainers of code are AI systems themselves, rather than human developers.

However, it’s important to note that this scenario is still largely hypothetical and dependent on further advancements in AI technology and its practical applications in software development. Nonetheless, it highlights the potential for AI to reshape not only how we write and maintain code but also how code itself is generated and optimised for machine consumption.

Who Cares How We Code?

March 27, 2024
Article, Coding, Product development, Software development
Leave a comment

Who Cares How We Code?

The Premise

As developers, we’re a smart bunch. We know our stuff and can generally be trusted to choose the best approach to getting the job done, right? After all, the goal is to get that program up and running in production as quickly as possible. What could possibly go wrong if we cut a few corners here and there? A bit of spaghetti code never hurt anyone. And technical debt is a conscious and intentional choice, yes?

The Bitter Truth

Sadly, this cavalier attitude towards development practices is a recipe for disaster further down the line. While it may seem like a shortcut to production Heaven, it’s more akin to paving the way to Maintenance Hell – and Future Costs City. Let’s explore why we might choose to actually care about how we code.

Compromising Schedule Predictability

Messy codebases compromise team’s ability to predict how long something is going to take. The more the mess, the more unreliable the schedule.

The Future Payback Trap

We can compare writing sloppy, unmaintainable code as analogous to racking up maxed-out credit cards. It’s taking on inevitable future payback down the line, and just like financial debt, it accrues “interest” in the form of extra development costs that compound over time. That once-scrappy codebase becomes an ungovernable mess that’s exponentially harder to change, optimise, or extend. Before we know it, we’re spending more time untangling our own spaghettic nightmares than making meaningful progress.

The Collaboration Conundrum

In most cases, a codebase is a team effort across its lifetime. If you don’t maintain a minimum level of quality, good luck onboarding new team members or even having your future self make sense of the tangle a few months down the road. Sloppy code breeds knowledge silos and cripples effective collaboration.

The Debugging Debacle

Well-structured, self-documenting code that follows good architectural principles makes it infinitely easier to debug issues and safely update the software over time. In contrast, a patched-together “codic dervish” is virtually impossible to decipher or modify without potentially disastrous unintended consequences.

The Performance Pitfall

While your hacky script may seem to work for that small prototype or MVP, codebases that cut corners on fundamental coding practices and design patterns simply won’t be able to scale gracefully as usage and complexity grow over time. Code quality is paramount for managing performance under load.

The Futility of Quality Assurance

When we don’t make code quality a priority from the get-go, good luck getting meaningful code reviews or implementing a robust quality assurance approach. Code reviews become an exercise in futility, and QA turns into a fruitless game of DevOps whack-a-mole, constantly putting out fires in an inherently unstable, unpredictable product.

The Craftsmanship Principle

At the end of the day, consistently writing clean, maintainable code is one of the hallmarks of competence, as opposed to a mere hack. By treating our craft with care and prioritising technical excellence, we’re investing in the long-term success of our products, our teams, and our careers. But who cares about the long term?

The Metaclueless Developers: Inheriting Teams Unaware of Their Own Shortcomings

March 15, 2024
Article, Product development, Relationships, Software development, Teambuilding, Toxic behaviours
2 Comments

The Metaclueless Developers: Inheriting Teams Unaware of Their Own Shortcomings

The Back Story

One time, as VP of Engineering, I inherited a motley team of metaclueless developers and testers.

The Flawed Assumptions

From day one with this new team, it became clear my assumptions were way off base. My attempts to understand the existing codebase, dependencies, coding and deployment processes were met with confusing non-explanations from the senior developers. Proposals for changes, reviews, or other improvements were immediately dismissed with a passive-aggresive demeanour as unnecessary red tape. There seemed to be this ingrained belief that “we’ve been doing just fine” simply because they hadn’t suffered many major outages yet.

Peeling Back the Layers

But as I started really digging in, the reality was more problematic than I initially realised. The codebase was a disorganised tangle of inconsistent patterns and anti-patterns. Automated testing and deployement was sporadic at best. The deployment process involved brittle, undocumented scripts that only a few developers halfway understood. Institutional knowledge was scattered among individual brain silos.

The Destructive Hubris

Rather than a receptive discussion when invited to discussion on making things better, I faced a brick wall of defensiveness and hubris. The team was convinced they knew best – such that any invitations went unadopted. Every mention of improvement was met with circular justifications about “how we’ve been doing it for years” or “we haven’t had any serious issues yet”.

The Path Forward

Looking back now, I see that the situation revealed some universal truths about software:

First, we all get blindspots and make flawed assumptions over time – no matter how experienced we think we are. Maintaining a beginner’s mindset of continual learning helps.

Second, defensiveness and “ingrained way” thinking are toxic team pathologies that noone can solve alone. An environment of open dialogue and reasoned self-critique must be continually fostered.

And finally, the most dangerous hubris of all is assuming you already have all the answers rather than a humble openness to involving everyone in uncovering the real issues at hand, and ways forward.

The Executive Fuckups Crippling Software Development

March 11, 2024
Actionable Insights, Alien tech, Article, Business, Collaboration, Culture change, Management, Marshall Model, Organisational effectiveness, Product development, Quintessence, Software development, Toxic behaviours
Leave a comment

The Executive Fuckups Crippling Software Development

Let’s be honest, executives and seniors managers are forever fucking up their organisations’ software development efforts, big time.

Category Error

The Crux of the Problem

Let’s be honest, successfully executing software development initiatives is no easy feat for executives and senior managers. As the Harvard Business Review aptly states,

“The greatest impediment [to effective software development] is not the need for better methodologies, empirical evidence of significant benefits, or proof that agile can work – it’s the behaviour of executives.”

At the root of these struggles lies a fundamental “Category Error” – the failure to recognise collaborative knowledge work (CKW), such as software development, as a distinct category from other types of work.

Applying the Wrong Lens

Whilst leadership plays a crucial role in complex projects, executives often fuck up development big time by attempting to manage software development through the same lens as:

  • Factory work
  • Manufacturing
  • Traditional office work
  • Service work (e.g. call centres, help desks)
  • Individual knowledge work

However, collaborative knowledge work demands a radically different approach. Imposing management practices from other categories inevitably leads to “management monstrosities” – dysfunctional, ineffective tech organisations.

The Pitfalls of Misclassification

  1. Disconnect Between Business and CKW
    Executives struggle to bridge the gap between business objectives and CKW realities when software development is treated as akin to factory work or manufacturing.
  2. Unrealistic Expectations
    Viewing software development through the lens of production lines and factory work breeds cultural mismatches, unrealistic timelines and quality compromises.
  3. Resistance to Change
    Legacy systems persist due to inertia from treating CKW like the more understood office work.
  4. Resource Misallocation
    Without recognising development as collaborative knowledge work, resources for talent, tools and infrastructure are inadequate.
  5. Micromanagement
    An authoritarian command-and-control ethos stifles the autonomy and collaboration that development teams need.

The Crux of the Issue

The HBR quote exposes this truth – executives’ mindsets, shaped by misunderstanding the category of work, undermine methodologies and processes.

Unlocking True Potential

Overcoming “management monstrosities” requires understanding software development as collaborative knowledge work. This shift allows:

  • Fostering cultures of learning and evolution.
  • Embracing self managing, autonomous team models.
  • Aligning resources for teams of knowledge workers.
  • Building bridges between business and CKW domains.

With the right categorisation and mindset, executives can transform organisations into innovative powerhouses (fat chance of that happening in our lifetimes).

The Path Forward

The key lies in shedding industrial-era management thinking (they do think, don’t they?) and nurturing environments suited to this distinct category of work.

Open communication, adaptability and appreciating the complexities of collaborative development are vital. Escaping the “Category Error” unlocks outstanding delivery of software solutions and delight for all the Folks That Matter™.

How “Constant State of Ship” Drives Transformative Practices

March 11, 2024
Antimatter principle, Article, Automation, Business, Capability development, Culture change, Engineering, Familiar, Fellowship, Flow, Improvement, Learning, Memeology, Organisational effectiveness, Organisational Therapy, Product development, Quintessence, Self-organisation
Leave a comment

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.

Emotioneering the Eye of the Beholder

March 6, 2024
Article, Business, Emotioneering, Product development, Software development
Leave a comment

Emotioneering the Eye of the Beholder

Following on from my previous two posts on the theme of beauty…

Defining Aesthetic Ideals

The old adage “beauty is in the eye of the beholder” takes on new significance when viewed through the lens of emotioneering – the practice of systematically crafting product experiences to influence human emotions and perceptions, and increase the chances of people buying the product. Beauty brands and marketers have long recognised the power of shaping what we consider beautiful and desirable. But have you ever stopped to consider why you find certain looks, features or styles appealing?

The Myth of Universal Beauty

At its core, defining beauty standards is a powerful form of emotioneering. The marketing engines and cultural influences that promote certain physical attributes, fashion styles or body types over others directly mould our emotional associations with beauty ideals. Seeing the same narrow standards repeatedly reinforced triggers feelings of aspirational desire or even inadequacy for not meeting those idealised norms.

Mapping Subjective Influences

However, seasoned emotioneers understand that universal beauty is a myth. Perceived beauty is deeply personal, shaped by individual experiences, cultural exposures, and psychological predispositions. By tapping into these subjective influences, brands can emotioneering highly specialised and targeted versions of what “beauty” looks and feels like for different segments. What life experiences or influences have shaped your own concept of beauty?

Crafting Emotional Resonance

For some audiences, rugged, athletic physiques projecting strength and power evoke desired emotions. For others, approachable, lower-intensity looks feel more comfortably aspirational and beautiful. Smart emotioneers study intersections of influences like age, ethnicity, geographical environment, hobbies and belief systems to reverse-engineer the most provocative emotional territory to target.

This principle of crafting emotional resonance extends well beyond just physical appearance into other product realms as well. In the world of software and digital experiences, emotioneers carefully study how different user groups emotionally respond to various design elements, interaction patterns, and functionality.

For instance, an emotioneered secure file-sharing app targeting IT professionals may aim to instill feelings of control, robustness, and authority through its UI and messaging. Conversely, an emotioneered photo editing app for creative consumers might vibe maximalism, playfulness, and unleashed artistic expression. What emotional notes a product strikes shape whether a user perceives it as an innate problem-solving ally or an unsatisfying hassle.

From the interaction micromoments to the holistic user journey, thoughtful emotioneers map the emotional pathways that transform digital bits into resonant human experiences. Do certain software aesthetics, features, or processes amplify your sense of delight, confidence, or creative freedom? The most impactful players understand how to intentionally thread those emotional highlights throughout their digital products.

Imprinting the Beholder’s Eye

Ultimately, while the “beauty in the eye” idiom hints at subjectivity, the most sophisticated emotioneers appreciate that no perspective on beauty is untainted – emotional perceptions around beauty are constantly imprinted, whether by intention or environment. By meticulously mapping the influences and ingrained experiences that shape different beholders’ eyes, emotioneers attain power to systematically shift what emotional notes the idea of “beauty” strikes for any desired audience. Does recognising these influences make you more aware of how your own perceptions may have been shaped?

Further Reading

Lindstrom, M. (2008). Buyology: Truth and lies about why we buy. Doubleday.

The True Beauty of Software: Serving Human Needs

March 5, 2024
Alien tech, Antimatter principle, Article, Attendants, Compassion, Empathy, Philosophy, Product development, Software development, Value
Leave a comment

The True Beauty of Software: Serving Human Needs

“Beauty is only skin deep, but ugly goes clear to the bone.”

~ Thomas Overbury

When pondering what constitutes beautiful software, we might choose to look beyond the mere lines of code on the screen. For genuine beauty in software arises not from technical excellence, but from the extent to which it genuinely serves and aligns with the needs of human beings.

A Deeper Beauty

On the surface, we may admire software having clean, elegant code structure, adhering to best practices and exhibiting visual appeal. But the ancient philosophers taught that true beauty must run deeper than superficial appearances. For software, this deeper beauty emanates from how effectively it enhances human capabilities and experiences in the real world.

Power to Elevate

Well-designed software represents the harmonious weaving of digital capabilities with human need. Just as great art inspires by achieving a personal expression of universal themes, so does beautiful software illuminate core human needs through its delivery of cohesive, purposeful functionality. It allows us to appreciate software’s power to elevate and augment our existence.

Like the Romantic poets extolled, beautiful software can facilitate a transcendent union with something greater than ourselves. When developing with insight into human needs, programmers experience a state of flow, bridging the worlds of bits and people until there is no division between the created software and those it benefits. We become co-creators, using our skills to help bring into being solutions which empower.

Resonant

At the same time, beautiful software must resonate with the depth of human experience. As Buddhist wisdom teaches, true beauty arises through mindfulness, ethical conduct, and pacification of the ego. In beautiful software, we find the development team’s consciousness – their thoughtfulness in attending to folks’ needs, their restraint in avoiding the unneeded, their core values embodied in the system’s behaviours.

Inner Light

Moreover, beautiful software exhibits an inner light not of technical correctness, but of purpose – solving real human needs with clarity and compassion. Its beauty transcends being well-crafted to also being virtuous, ethical and generous in spirit. For its core purpose is selfless service to humanity.

Conclusion

So while we may appreciate the external trappings of high-quality software, true beauty runs deeper – into how well it elevates human potential and adapts seamlessly into the real needs of peoples’ lives. For therein lies the highest achievement, to create not just products, but solutions that illuminate, attend to, and empower the human condition.

The Why of FlowChain: Deliberate Continuous Improvement

February 19, 2024
Actionable Insights, Article, Business, Capability development, Culture change, Deming, Doctrine, Flow, Flow•gnosis, Flowchain, Improvement, Learning, Memeology, Metaflow, Organisational effectiveness, Prod•gnosis, Product development, Quintessence, Rightshifting, Software Delivery, Software development, Systems thinking, Value streams
Leave a comment

The Why of FlowChain: Deliberate Continuous Improvement

In my career, working with hundreds of companies, I’ve almost never seen organisations* take a truly deliberate approach to continuous improvement. It’s nearly always treated as an afterthought or add-on to business-as-usual (BAU). But real transformation requires making continuous improvement an integral and core part of daily work. This is the “why” behind FlowChain – enabling deliberate, in-band continuous improvement.

In other words, applying the same disciplines from product development, delivery, etc. to the business (sic) of delivering continuous improvements  – continuously improving the way the work works.

What Is FlowChain?

So what is FlowChain? At its core, it is a system for managing flow – both the flow of outputs and the flow of improvements to the way the work works, concurrently and by the same means. And by “flow”, I mean the steady progress of work from request to completion through all steps in a process. Flow is optimised when the right work is happening at the right time by the right people. Roadblocks, delays, and waste are minimised or eliminated.

Flow

Optimising flow delivers the following benefits:

  • Increased productivity – less time wasted, more work completed
  • Improved quality – fewer defects, rework minimised
  • Better customer service – faster response times, reliability
  • Higher employee engagement – less frustration, more joy

But achieving flow requires continuous improvement. Problems must be made visible. Waste must be reduced iteratively. Roadblocks must be cleared continuously.

This is why FlowChain incorporates improvement into its regular rhythm. Each cycle follows a deliberate sequence:

  • Plan – Select and sequence the upcoming work.
  • Execute – Complete the work while tackling issues.
  • Review – Analyse completed work and identify improvements.
  • Adjust – Make changes to improve flow.

Unlike most continuous improvement efforts – that are separate from BAU – FlowChain makes improvement an integral in-band activity. The rapid cycles provide frequent opportunities to reflect, gain insights, and act.

Compounding Benefits

Over time, the compounding benefits are immense. Teams develop a “flow habit”, where improving flow becomes second nature. Powerful capabilities like root cause analysis, A3 problem-solving, improvement katas, and change management are honed.

In my experience, this deliberate approach is transformative. Teams gain tremendous agency to systematically improve their own flow. The organisation as a whole cultivates a culture of continuous improvement. And customers experience ever-better service and responsiveness.

The “why” of FlowChain is simple – create focus, visibility, accountability, and agency to drive continuous improvement. The results – ever better flow, reduced waste, and sustainable transformation. Deliberate, in-band continuous improvement stops being an aspiration and becomes a reality.

*Ask me about the exception.

What is Rigour?

February 7, 2024
Actionable Insights, Article, Capability development, Caring, Culture change, Engineering, Fellowship, Organisational effectiveness, Product development, Quintessence, Rightshifting, Self-organisation, Software development, Standard work, Teambuilding
Leave a comment

What is Rigour?

Rigour refers to the strict precision and accuracy with which work is executed in fields like software engineering and collaborative knowledge work (CKW). It entails adherence to standards and best practices for needed outcomes.

The Importance of Getting it Right

Attentive rigour matters because carelessness breeds mistakes. Flaws in logic or bugs in code stem from a lack of rigour. This introduces unwanted surprises, and failures down the line. Rigour is an attitude of mind that zeroes in on getting things right the first time Cf. Crosby, ZeeDee.

The Perils of Getting it Wrong

However, the quest for rigour can go awry when imposed hastily or mindlessly. Establishing rigorous frameworks like requirements analysis, peer review etc. does carry overhead. Teams can get so bogged down chasing perfection that creativity, productivity and morale suffer. Or so much time is spent eliminating small defects that bigger picture progress slows. Like most things, balance is warranted.

The Laissez-Faire Extreme

At the other end of the spectrum from rigour lies the laissez-faire attitude. This French phrase meaning “let it be” encapsulates a laid-back approach where participants have broad freedom to work in whatever manner they choose.

In software and knowledge work contexts, laissez-faire environments feature very few enforced policies, protocols, or mechanisms for ensuring quality. Creativity and unhindered workflow takes priority over rigour. Peer reviews, quality assurance, and documentation are optional. Teams self-organise organically without work standards.

This spontaneity can spark innovation but has pitfalls. Lack of rigour tacitly permits cut corners, gaps in logic, unfinished ideas and sloppy execution. With an easy-going approach, easily preventable flaws accumulate and undermine end results.

In applied contexts like commercial software development, laissez-faire practices practically guarantee shoddy work products riddled with defects. User needs demand rigour not as an obstacle, but as an enabler of excellence. Finding the right balance is key.

The absence of rigour embodied in laissez-faire philosophies may promote freedom. But the ensuing chaos leaves the fruits of hard work easily compromised. Some structure and rigour ultimately serves applied collaborative knowledge work better in the long run.

While cutting corners is not an option, forced rigour without context can mean marginal gains at disproportionate cost. Rigour must enable, not encumber, the pursuit of excellence. Teams that foster a culture where rigour flows from all participants, intrinsically and voluntarily, tend to find the sweet spot. Getting there requires clarity of purpose, patience, and care. Do that and rigour lifts the quality of collaborative knowledge work substantially over time.

What does rigour mean to you and your team?

The Far-Reaching Impacts of the Law of Unintended Consequences

January 8, 2024
Antimatter principle, Article, Culture change, Organisational Therapy, Product development, Quintessence, Self-organisation, Software development
Leave a comment

The Far-Reaching Impacts of the Law of Unintended Consequences

The law of unintended consequences states that actions will have unanticipated effects, often counterproductive ones. This concept profoundly applies to software development, and collaborative knowledge work more generally. In these domains involving interdependent human and technical factors, even well-intentioned plans often go awry.

This post explores key unintended consequences that manifest in software develeopment and collaborative knowledge work (CKW):

Technical Debt

Technical debt refers to the deliberate choice to take shortcuts in order to expedite software delivery. Like financial debt, it can be beneficial if consciously taken on and repaid through refactoring. However, scheduled repayments often get deferred as teams race to meet deadlines. The “interest” accrues as ongoing maintenance costs.

Feature Creep

The lean startup mentality of minimum viable products and iterative development has advantages. However, an unintended consequence is feature creep – products become bloated as developers continuously add but rarely subtract capabilities. And as management finds more and more pointless or decreasing value work to keep their standing teams busy. The result is complex products growing like topsy.

Information Overload

Modern collaboration tools enable unprecedented information sharing. But an unintended consequence is information overload, which hampers productivity and decision-making. Each piece of information seems useful, yet the cumulative result is a distracted, overburdened workforce.

Tunnel Vision

In software development, teams focus on completing narrowly defined tasks. This tunnel vision means losing sight of the big picture. Pressure to deliver assigned work leads to task-oriented rather than solution-oriented thinking. This tendency is exacerbated by the widespread case of work assignments coming from management rather than self-organising teams. The unintended consequence is misalignment, reduced value, and lack of integration.

Morale Issues

Open information flow and accountability bring major benefits. However, the unintended consequence can be decreased risk-taking, and morale problems. With every action visible and judged, workers avoid mistakes that could impact performance reviews. Innovation suffers when people focus on safe, incremental tasks and protecting thir own arses (cf. CYA).

Busywork

When work is misaligned with overall goals and strategies, inevitable busywork is the result. People spin their wheels on tasks that provide no real value to customers or the organisation and its customers. Energy is frittered away on going through the motions versus really attending to folks’ needs.

Perverse Incentives and Focus on Productivity

Reward systems, especially those aimed at boosting individuals’ productivity, undermine quality and teamwork. For example, compensating developers based on lines of code incentivises quantity over quality. Emphasising individual contributors over collaboration is another common unintended consequence.

Loss of Tacit Knowledge

Capturing processes, best practices, and “how-to” knowledge in wikis and databases can provide some benefts. However, over-reliance on documentation loses tacit knowledge that comes from experience and learned skills. Key contextual information gets lost when veterans leave without transfering hard-to-document knowledge.

Technical Monocultures

Standardisation has advantages in terms of compatibility and skill transferability. But an unintended consequence is the risk of monoculture technology stacks vulnerable to single points of failure. If a widely used framework has a major bug, many downstream systems are suddenly impacted.

Integration Headaches

Connecting modern microservices architectures can provide agility. However, an unintended consequence is integration headaches when stitching together disparate systems and data sources. Overally product reliability can also suffer. Development timelines often underestimate the complexity of integrating components.

Zombie Projects

Organisations generally find it difficult or impossible to kill failing initiatives. There is a tendency for questionable projects to lurch forward as “zombies” that nobody wants to end due to e.g. sunk cost fallacy. The unintended consequence is opportunity costs – as zombies consume budgets, workers and that rarest of all resources – management attention.

Mitigation Strategies

With sufficient foresight and systems thinking, organisations can choose to institute mitigating actions:

  • A systemic focus on the Antimatter Principle (have all efforts directed at attending to the needs of all the Folks That Matter™ Cf. The Needsscape).
  • Institute product management disciplines to curtail feature creep (Cf. Product Aikido).
  • Promote diversity and constructive dissent to counter groupthink.
  • Prioritise attending to folks’ needs, including capturing (e.g. documenting) knowledge that serves folks needs for reference information .
  • Stay vigilant w.r.t. unintended consequences (often only obvious through hindsight).
  • Engage with Organisational Psychotherapy so issues can be surfaced, and reflected upon, early.

By understanding where the Law of Unintended Consequences applies, teams can take proactive steps to minimise disruptive friction and dysfunction. The result is better alignment, usable products, and organisations where the whole exceeds the sum of misguided parts.

Training For All The Wrong Skills

September 18, 2023
Article, Attendants, Product development, Quintessence, Software development, Systems thinking, Testing, Training
Leave a comment

Training For All The Wrong Skills

Are We Training People For the Wrong Skills?

In business and software development, we’ve got a misalignment. We’re so wrapped up in perfecting the technical, we lose sight of the human. Developers are trained to churn out code more quickly, code that’s faster, cheaper, and more reliable, but are they learning how to solve real-world problems? Testers are trained to find bugs, but not how to prevent them. The result: technically proficient software that either nobody wants or that arrives late and over budget, or both.

Technical Matters?

Yes, quality code is essential. Yet, it’s by no means the end-all and be-all. A developer isn’t just a code-writing machine; they’re attendants. The fixation on coding and computing skills above all else turns them into technicians rather than holistic thinkers capable of understanding and meeting folks’ needs. When developers are pigeonholed into this role, organisations miss out on the broader impact their expensive developers could be making.

What About Bugs?

Finding bugs is a red herring – what if we could prevent them in the first place? Testers are often pigeonholed into merely identifying issues rather than participating in a more proactive approach. This approach costs time, money, and may even reduce the software’s overall quality because the focus is on fixing, not preventing. The need for speed in bug-finding diverts attention from other valuable forms of contribution, like feature development and needs validation (making sure the product meets the real needs of all the Folks That Matter™.

What’s the Cost?

When we narrow our focus to speed, efficiency, and defect detection, we end up inflating costs and extending delivery times. Software development isn’t just about churning out lines of code or ticking off a testing checklist. It’s a more nuanced art that blends technical skills with an understanding of the needs of all the Folks That Matter™.

Where’s the User in All This?

In the chase for technical mastery, it’s easy to forget the end-user. Products, at their core, are intended to make lives easier, to attend to folks needs. When developers and testers are not trained to master these things, we end up with products that are high on features but low on utility.

So What’s the Solution?

If we’re to correct this misalignment, we need a cultural shift. We might choose to reorient our training and development programmes. For developers, this means less emphasis on speed and more on understanding who matters, and then discovering and meeting these folks’ needs. For testers, a shift from just finding bugs to a more holistic approach to quality via defect prevention (Cf. ZeeDee) would be transformative.

Where Do We Go from Here?

The technical aspects of software and product development are, without a doubt, essential. But they aren’t the whole story. By shifting our focus to include all the needs of all the Folks That Matter™, we can create products that not only work but makes a difference. The first step? Acknowledging that we’ve been training for all the wrong skills.

Are Managers Killing Their Golden Geese?

September 9, 2023
Antimatter principle, Article, Management, Organisational effectiveness, Product development, Psychology, Software Delivery, Software development, Toxic behaviours
Leave a comment

Are Managers Killing Their Golden Geese?

Cognitive Function Rules

Cognitive function encapsulates the mental processes needed for problem-solving, abstract thinking, and quick decision-making. In the realm of software development, high cognitive function is indispensable for understanding complex algorithms, creating efficient code, delivering quality, and solving intricate problems.

Why Does Cognitive Function Matter?

When cognitive function is at its peak, developers can perform their tasks not just quickly but also effectively. It enables them to come up with innovative solutions, debug issues proficiently, and contribute meaningfully to a project’s success.

How Do Managers Disrupt Cognitive Function?

Routine managerial practices like frequent check-ins, status reports, micromanagement, and unclear objectives can negatively impact a developer’s cognitive function. Added to this, loaded work schedules and harsh deadlines contribute to stress, which further degrades cognitive performance.

What About Toxic Behaviour?

Abusive and toxic conduct from managers goes beyond disrupting cognitive function. This behaviour often leads to severe emotional stress, causing long-term harm – including brain damage – that manifests as burnout, poor performance, and staff turnover.

What’s the Consequence?

When cognitive function suffers, the ripple effect is felt throughout the team and the organisation. There’s a decline in product quality, an increase in mistakes, and a noticeable lag in delivery timelines. In such a scenario, managers are essentially killing the very geese (developers) that lay the golden eggs (software).

Is There a Remedy?

Creating a more nurturing work environment can help. Managers might choose to adopt practices that allow for focused work, respect individual needs, and most importantly, eliminate toxic and abusive behaviours.

Will Change Happen?

The ball’s in the managers’ court. The cognitive well-being of their software developers—and by extension, the quality and success of their own wellbeing—depends on how they choose to adapt their management styles.

A Question of Flow

September 8, 2023
Article, Business, Flow, Flow•gnosis, Flowchain, Product development, Software development
Leave a comment

A Question of Flow

A New Take on Flow?

When we hear about flow, it’s often linked to a psychological state of focus and immersion. But flow isn’t just a psychological state popularised by Mihaly Csikszentmihalyi. There’s another kind of flow that plays a critical role in organisations. This type of flow refers to a well-coordinated series of actions, events, or processes that work in harmony – flow as a smooth succession of actions that take place within an organisational setting

Why Should You Bother?

Paying attention to flow in your organisation is not just an academic exercise; it’s a practical necessity. Improved flow means fewer bottlenecks, quicker turnarounds, and more satisfied employees. Given these benefits, can you afford to overlook the importance of achieving good flow?

Is Structure the Solution?

While structure might seem constraining, it offers a foundation upon which flow can thrive. Roles and responsibilities are clearer, and tasks follow a more predictable pattern. However, there’s a limit to the benefits of structure. Could too much structure curtail creativity and inhibit the capacity for innovative solutions? How much structure is “just enough”?

How Tech Can Contribute

Modern technology provides tools that make it easier to achieve flow. Automated systems can handle repetitive tasks, freeing humans to focus on complex challenges. Additionally, real-time data analytics can identify potential bottlenecks before they become major issues. But what’s the cost of getting your tech choices wrong?

Humans in the Equation

A finely tuned system isn’t just about technology or well-drafted processes. The human element—morale, motivation, and collaboration—also plays a pivotal role. When employees work well together, the flow is more natural and less forced. How can we foster a culture that encourages this kind of harmony?

What Metrics to Use

Choosing metrics for gauging flow involves more than just picking numbers to track. Do task completion times, takt times, employee engagement levels, or customer satisfaction rates resonate with your organisational goals? How do you know if you’re focusing on the right measures to sustain or enhance flow?

Ready to Make a Change?

Embarking on the journey to improve organisational flow is a complex but rewarding endeavour. It involves continuous assessment, involving multiple stakeholders, and making frequent adjustments. Are you willing to commit the necessary time and resources to achieve a state of optimal flow?

Flow, in this organisational sense, is a multifaceted concept. By asking the right questions and taking a balanced approach, you can create an environment where flow becomes a natural aspect of your operational landscape. So, are you prepared to rethink what flow means for you and your organisation?

A Question of Flow: Extending into the Software Realm

Does Software Development Redefine Flow?

In the complex landscape of software development, flow takes on nuanced dimensions. Beyond well-coordinated actions and processes, here it’s about managing interdependent systems, handling data, and synchronising multiple contributors. How does the concept of flow evolve when applied to software?

What Are the Stakes for Software Projects?

The relevance of flow extends far beyond general organisational theory when we delve into software projects. It’s not just about speed but also about code quality, user experience, and sustainable development. How does focusing on flow lead to more resilient and robust software systems?

How Does Architecture Influence Flow?

In software development, the architecture itself can facilitate or hinder flow. Modular designs and well-defined APIs can dramatically streamline the work process. How could architecture be leveraged to enhance flow, without compromising quality?

Are DevOps and CI/CD Flow Enablers?

DevOps culture and Continuous Integration/Continuous Deployment (CI/CD) pipelines are revolutionising the flow in software development. They merge development and operations, automating much of the workflow. Is the automation brought by these practices always beneficial, or could there be drawbacks?

Can Open Source Cultures Teach Us About Flow?

The open-source community often exhibits a unique kind of flow, built on collective intelligence and decentralized collaboration. Can traditional organisations learn from this paradigm?

What About Flow in Remote Teams?

The rise of remote work presents new challenges and opportunities for achieving flow in software development. How do time zones, cultural differences, and virtual communication affect flow? Can they be harnessed to enhance it instead?

Is Ethical Software Development Compatible with Flow?

Rapid development cycles and the pursuit of flow might conflict with the need for ethical considerations in software design, such as accessibility and data privacy. Can a balance be achieved where ethical imperatives don’t disrupt the flow?

Are We Ready for the Future of Software Development Flow?

As technologies like AI and quantum computing mature, they’ll inevitably impact the flow of software development. Will we adapt our notions of flow to these advancements, or will the concept of flow itself undergo a transformation?

By integrating these big-picture considerations, we can explore new frontiers of flow in both traditional organisations and software development landscapes. The question remains: Are we ready to adapt and evolve?

Cultivating Code

September 6, 2023
Article, Product development, Software development
Leave a comment

Cultivating Code

Creating an effective software development environment requires more than technical skills or product roadmaps. As developers and development leaders, our roles encompass a broad range of responsibilities. The following sections delve into these multifaceted aspects – aspects that contribute to an environment where software development – and software developers – will flourish.

The Distinction

Developing software and leading its development are fundamentally different. While the former focuses on the practicalities of building solutions, the latter revolves around creating a conducive environment for such work to take place.

But what makes for an environment particularly well suited to software development? Let’s dive in.

Fostering Communication

As developers, we often delve deep into code, sometimes forgetting the world outside – sharing ideas, discussing problems and collaborating on solutions. But communication is the linchpin that holds everything together. In a leadership role, we must create an atmosphere where communication is fluid, open, and encouraged. This includes not only daily stand-ups or periodic meetings but also an open-door policy where team members feel they can approach us with their ideas or concerns. We set the tone, the language, and the pace for how communication happens.

Autonomy and Responsibility

Developers perform best when given the freedom to make decisions related to their tasks. They need autonomy to implement creative solutions. Responsibility accompanies this autonomy; it drives developers to perform their best, knowing that their decisions have an impact.

One of the core drivers for any developer is the freedom to solve problems in unique ways. As development leaders, we should ensure that our teams have the autonomy they need to make decisions about the code they write, the solutions they design, the tools to use, the way the work works, and even the technologies they wish to implement. But with great freedom comes great responsibility. Our role is to instil a sense of mission or purpose – the organising intent – that complements this autonomy. We need our team members to lean in to and own their decisions, fully, leading to a greater commitment to quality.

Note: Organising Intent refers to a clearly articulated objective or vision that guides the actions and decisions within a software development team. A clearly stated organising Intent provides team members with the ‘why’ behind their tasks. By understanding the broader goals and implications, team members are better equipped to make autonomous decisions that align with the overarching aims of the organisation. This intent serves as a unifying principle, enabling more effective coordination and fostering a shared sense of purpose.

Emotional Well-being

It’s essential for developers to feel mentally and emotionally supported. An environment that actively addresses burnout, stress and provides a good work-life balance contributes to better productivity and job satisfaction.

Work isn’t just about ticking off tasks from a to-do list; it’s also about the emotional and mental state of the team. As leaders, it behooves us to create a supportive environment that acknowledges the human aspects of work. From attending to folks’ needs, through acknowledging achievements, however small, to actively addressing burnout and stress, we have to consider emotional well-being as an integral part of the development process.

Continuous Learning and Cognitive Functioning

As developers, we understand that learning doesn’t stop once we leave the classroom; it’s an ongoing process essential for staying relevant. As development leaders, fostering a culture of continuous learning is a two-fold task. On one hand, it involves providing opportunities for skill enhancement. On the other, it requires an understanding of cognitive functioning, ensuring that our teams can absorb new knowledge under optimal conditions.

Cognitive dissonance, the psychological stress experienced when confronted with new information that conflicts with existing beliefs, can be a powerful motivator for growth. Rather than shying away from this discomfort, we can use it as a tool to encourage team members to re-examine old ways of thinking and adopt new, more effective methods.

The human brain operates best under specific conditions. Too much stress, for example, can trigger amygdala hijacks, where the emotional part of the brain interferes with rational thinking. Such episodes can halt learning and creativity dead in their tracks. As leaders, recognising the signs of stress and understanding how to defuse it are vital for creating an environment conducive to cognitive functioning and, by extension, continuous learning.

Our role, then, extends beyond merely finding resources. We must also cultivate an environment that encourages personal growth, helping our team members navigate the tricky psychological landscape that comes with collaborative knowledge work. In this way, we create a fertile ground not just for learning new technologies or ways of working, but for fundamental personal and emotional growth.

Feedback Loops

Regular feedback is essential for both the product and the team. Leaders might choose to establish short feedback loops with customers and among team members, allowing for agile adjustments and quicker improvements.

Feedback is the compass that guides development. As developers, we often look for immediate feedback from our code compilers or debugging tools. But as leaders, we establish feedback mechanisms that encompass not just the product but also the team, and all the Folks That Matter™. Regular team reviews, client feedback, and even self-assessments are tools we can use to ensure we’re always moving in the right direction.

Summary

Leading software development isn’t about barking orders from an ivory tower. It’s about cultivating a field where the seeds of software development can grow into robust solutions which meet folks’ needs.

Being at the helm of software development is not about mere management, nor even simple leadership. It’s an act of cultivation. As development leaders, we’re gardeners tending to our social  gardens, providing them with the right soil, the right amount of light, and the essential nutrients they need to grow and flourish. From facilitating open communication to caring for the emotional well-being of our team, our actions set the stage for creating effective, sustainable software solutions.

Positive Relationships and Collaborative Knowledge Work

September 6, 2023
Antimatter principle, Article, Caring, Collaboration, Compassion, Fellowship, Management, Organisational effectiveness, Product development, Relationships, Software development
Leave a comment

Positive Relationships and Collaborative Knowledge Work

Why Relationships Matter in Collaborative Settings

In sectors such as software development, and management, where collaborative knowledge work is the norm, the quality of relationships isn’t just a social nicety—it’s a business imperative. Positive interpersonal connections amplify collective intelligence, increase productivity, and enhance the overall quality of work. In contrast, strained relationships lead to communication breakdowns, reduced morale, and compromised results. Hence, any team that aims for excellence might choose to focus, at least in part, on fostering positive relationships.

The Heart of the Matter: Caring Deeply

Before diving into the nuts and bolts of relationship building, it’s important to highlight a fundamental principle: genuine care for those with whom you’re working. In the context of collaborative knowledge work like software development, or management, compassion might not be the first thing that comes to mind. However, a deep sense of care and understanding for your fellows is what turns a group of individuals into a cohesive unit. Compassion fosters a supportive environment where people feel valued, not just for their technical skills but for who they are as individuals. This, in turn, leads to a sense of shared purpose and mutual respect, driving the team to higher levels of achievement.

For those sceptical about the role of compassion in a professional setting, the book “Compassionomics” provides compelling evidence. It delves into the science behind compassion and demonstrates how this emotional intelligence skill significantly impacts relationship building and, ultimately, success.

Having set the stage with the importance of deep care and compassion, let’s delve into the specific strategies to build and maintain positive relationships in collaborative settings.

Master the Art of Listening

Listening is more than just a passive act; it’s an active skill. This is especially crucial in collaborative knowledge work where understanding each other is key to solving complex challenges. Effective listening reveals not only what team members are saying but also what they’re thinking or possibly avoiding saying. Technical teams and management teams may choose to regard this deeper level of communication as critical for addressing challenges and finding solutions collaboratively.

Cultivate Self-Awareness

In a team setting, knowing oneself is as vital as knowing one’s craft. Being aware of one’s own strengths, weaknesses, and emotional responses can help navigate team dynamics more effectively. This level of insight allows one to contribute where most effective, and defer when deferral plays to someone else’s strengths.

Uphold Respect as a Core Value

In any collaborative effort, people bring a diverse set of skills and perspectives to the table. The concept of respect goes beyond mere tolerance of this diversity; it involves valuing and leveraging these different skills and viewpoints to enrich the project. In software development, where cross-functional teams often collaborate, respecting different disciplines—be it engineering, UX design, or quality assurance—is vital for project success.

Make Room for Personal Space

Even in high-stakes environments, it’s crucial to understand that everyone needs space to operate effectively. Overcrowding can lead to burnout, reduced productivity, and deteriorated relationship quality. Allowing for ‘breathing room’ can also offer team members the chance for independent thought, which they can later bring back to enrich the collective effort.

Be Consistent in Communication

Effective communication is a key element of successful relationship building. In a fast-paced, deadline-driven setting, regular check-ins can be the lifeline that keeps projects on track. This doesn’t just mean status updates, but also sharing feedback, insights, and even acknowledging small wins. It keeps everyone aligned on goals and expectations, reducing the room for misunderstandings or conflict.

Embrace Adaptability

The nature of collaborative knowledge work, particularly in tech, is dynamic. Flexibility and willingness to adapt are not just desirable traits but beneficial practices for maintaining positive relationships amidst change.

Summary

In collaborative knowledge work, the importance of maintaining positive relationships is amplified due to its direct impact on productivity and outcomes. By incorporating principles like effective listening, self-awareness, respect, personal space, consistent communication, and adaptability, you can lay down a robust foundation for a successful collaborative environment.

Further Reading

Trzeciak, S., & Mazzarelli, A. (2019). Compassionomics: The Revolutionary Scientific Evidence that Caring Makes a Difference. Studer Group.

The Deming Way to Measuring Software Developer Productivity

August 30, 2023
Article, Business, Culture change, Engineering, Management, Memeology, Metrics, Organisational effectiveness, Organisational Therapy, Paradigm shifts, Product development, Productivity, Software Delivery, Software development, Systems thinking, Teambuilding
1 Comment

The Deming Way to Measuring Software Developer Productivity

Many software folks pay lip service to Bill Deming and his work. Few if any pay any attention to the implications. Let’s break the mould and dive into how the great man himself might look at software developer productivity (a subset of collaborative knowledge worker productivity more generally).

This isn’t just a thought experiment; it’s an invitation to rethink our existing assumptions and beliefs about productivity.

Why Traditional Metrics Don’t Cut It

If Deming could peer over our shoulders, he’d likely be aghast at our fascination with shallow metrics. Lines of code? Bugs fixed? DORA? SPACE? These are mere surface ripples that fail to delve into the depths of what truly constitutes productivity. Deming was a systems thinker, and he’d want us to look at productivity as an outcome of a complex system. It’s influenced by everything from the quality of management practices to the clarity of project goals, and yes, even the standard of the coffee in the break room.

Aside 1

Let’s not get too hung up on staff productivity and the measurement thereof.

Deming’s First Theorem states that:

“Nobody gives a hoot about profits.”

A corollary might be:

“Nobody gives a hoot about software developer productivity.”

Which, drawing on my 50+ years experience in the software business, rings exceedingly true. Despite all the regular hoo-hah about productivity. Cf. Argyris and espoused theory vs theory in action.

Aside 2

While we’ve on the subject of measurment, let’s recognise that measuments will only be valid and useful when specified by and collected by the folks doing the work. I’ve written about this before, for example in my 2012 post “Just Two Questions“.

Aside 3

Let’s remember that the system (the way the work works) accounts for some 95% of an individual’s productivity. Leaving just 5% that’s a consequence of an individual’s talents and efforts. This makes it clear that attempting to measure individual productivity, or even team productivity, is a fool’s errand of the first order.

Here’s the Deming Approach

So, how would the statistician go about this? Hold on to your hats, because we’re diving into an eight-step process that marries statistical rigour with psychology and humanistic care.

1. Understand the System

First things first, get to grips with the holistic view. Understand how a line of code travels from a developer’s brain to the customer. This involves understanding the various elements in the software development lifecycle and how they interact.

2. Define Objectives

Random metrics serve no one. Deming would urge us to link productivity measurements to broader business objectives. What’s the end game? Is it faster delivery, better quality, or increased customer satisfaction?

3. Involve the Team

The people on the ‘shop floor’ have valuable insights. Deming would never neglect the developer’s perspective on productivity. Involving them in defining productivity criteria ensures buy-in and better data accuracy.

4. Data Collection

We’ve got our objectives and our team’s perspective. Now it’s time to roll up our sleeves and get to work on data collection. But this is Deming we’re talking about, so not just any data will do. The focus will be on meaningful metrics that align with the objectives we’ve set.

5. PDSA Cycle

Implementing the Plan-Do-Study-Act (PDSA) cycle, any changes aimed at boosting productivity would be introduced in small, incremental phases. These phases would be assessed for their effectiveness before either full implementation or going back to the drawing board.

6. Feedback Loops

You’ve made changes; now listen. Feedback from developers, who can offer a real-time response to whether the changes are working, is invaluable.

7. Regular Reviews

Productivity isn’t a static entity. It’s a dynamic component of a system that’s always in flux. Regular reviews help recalibrate the process and ensure it aligns with the ever-changing landscape.

8. Leadership Commitment

Finally, if you think increasing productivity is solely a developer’s job, think again. The leadership team must be as committed to this journey as the developers themselves. It’s a collective journey toward a common goal.

The Long Game

Deming never promised a quick fix. His was a long-term commitment to systemic improvement. But the fruits of such a commitment aren’t just increased productivity. You’re looking at more value for your business and greater satisfaction for both your developers and customers. So, let’s stop paying lip service to Deming and start actually embracing his philosophy. After all, a system is only as good as the assumptions and beliefs that shape it.

Reflection Demands Self-Examination

August 25, 2023
Article, Organisational Therapy, Product development, Quintessence, Retrospectives, Software development, Systems thinking
Leave a comment

Reflection Demands Self-Examination

Navigating the complex world of software and product development is a journey filled with twists and turns. When it comes to retrospectives, reflection and adaptation are more than just buzzwords; they’re essential tools. But there’s a hidden secret: reflecting without digging deeper into shared beliefs and assumptions is like trying to read a book with 90% of the the pages missing.

The Reflection Trap

Reflecting on what we’ve done is a vital step. Reflection, and acting upon those reflections, is how we learn from our mistakes and our successes. But if we stop at the surface, if we don’t ask ourselves why things happened the way they did, we’re missing a crucial part of the story.

The Missing Piece: Assumptions and Beliefs

Beneath the surface of every decision, every action, and every outcome, there are hidden assumptions and beliefs. These are the unseen forces guiding our choices. They can be our best allies or our worst enemies, depending on whether we recognise them or not.

Why We Need to Adapt

Adapting is more than just changing our actions; it’s about changing our assumptions and beliefs. To truly grow, we need to understand the why behind what we do. We must question our underlying beliefs and confront our assumptions.

Imagine you’re part of a team that keeps missing deadlines. You could tweak your schedules, but if you don’t question why it keeps happening, you might never address the root cause. It could be a belief that everything must be perfect, even if it takes longer. Without confronting that belief, you’ll keep missing those deadlines.

The Road Ahead: Surfacing then Reflecting. Understanding then Adapting

As you explore the world of software and product development, or any path you choose, remember that reflecting is only the first step. Go deeper. Ask why. Understand your assumptions, challenge your beliefs, and then adapt.

The process might be more complex, but the rewards are greater. By engaging with these deeper levels of understanding, you’ll find yourself more aligned with your goals, more resilient in the face of challenges, and more capable of innovative thinking.

Reflecting without understanding what’s beneath is like seeing only part of the picture. Embrace the full journey of reflect and adapt, and you’ll unlock doors to a more fulfilling and successful career in software development or whatever path you choose. It’s not about following a set path; it’s about understanding your path and shaping it as you go. Are you ready for the adventure?

The Software Crisis: A 50+ Year Conundrum Waiting for a Paradigm Shift

August 18, 2023
Agility at Scale, Antimatter principle, Attendants, Business, Culture change, Leadership, Management, Memeology, Organisational effectiveness, Paradigm shifts, Product development, Quintessence, Software development
1 Comment

The Software Crisis: A 50+ Year Conundrum Waiting for a Paradigm Shift

When the term “Software Crisis” was coined in the late 1960s, the software industry was grappling with issues of complexity, reliability, and maintainability. The rate at which technology was evolving seemed to outpace the ability to efficiently and effectively manage software projects. Yet, half a century later, we still find ourselves confronting the same challenges.

The Persistent Nature of the Crisis

Most industries undergo evolutionary shifts, which often transform the landscape and resolve the challenges of the past. However, the software domain remains an anomaly. Instead of outgrowing its initial issues, we find them compounded by the enormous scale and scope of contemporary software development. Despite more advanced tools and platforms, software bugs, project overruns, and scalability issues remain pertinent.

So, why is the software crisis still with us?

The Inherent Complexity of Software

Software is, in essence, abstract and malleable. Unlike constructing a building or manufacturing a car, where there’s a tangible product, software development involves attending to folks’ needs through weaving intricate patterns of logic. As the Needsscape evolves, it becomes increasingly challenging to untangle and reweave the strands.

Furthermore, software isn’t limited by physical laws. While you can keep adding lines of code, each new line tends to increase complexity in a non-linear fashion.(See also: #NoSoftware)

The Economic Incentives

There’s an underlying economic motive to maintain the status quo. Major software corporations, consultancy agencies, educational establishments, and even management gain from the ongoing software crisis.

  • Software Companies: Continuous updates, patches, and new releases mean ongoing revenue. “Perfect”, bug-free software from the outset would reduce the push for upgrades and extended support.
  • Consultancy Firms: A continuing crisis ensures a constant demand for experts to guide, integrate, and sustain various approaches. (Ever seen consultants hired to obviate the Software Crisis?).
  • Educational Institutions: The ever-evolving landscape necessitates continuous learning, translating to enrollment in courses, certifications, and further studies.
  • Management: The status quo often validates management hierarchies and roles. Shaking up the software development paradigm challenges established management statuses and command & control dynamics, which many in management roles find unsettling. Where’s the leadership??

The Need for a New Paradigm

While we’ve seen enhancements in methods and technologies, they don’t directly tackle the root causes of the software crisis. A paradigm shift is essential, but what should it emphasise?

  • People: Centralide the role of people in the software process. Recognise that while tools and technologies are marginally relevant, it’s people and teams who breathe life into software. We might choose to prioritise their well-being, motivation, and skills.
  • Relationships: Emphasise collaboration and communication. Siloed teams and heroic individuals exacerbate challenges. Cross-functional cooperation and fostering an environment where diverse perspectives converge can lead to better solutions.
  • Collective Assumptions and Beliefs: Challenge and revisit the shared beliefs and assumptions in the organisation. Often, outdated paradigms persist because they go unquestioned. By reassessing and updating these, we can pave the way for innovative approaches.

#Quintessence

The enduring software crisis mirrors the challenges inherent in software development and the economic frameworks that have crystallized around it. While vested interests might resist change, history reminds us that transformation is both inevitable and necessary. When the software industry finally experiences its paradigm shift, it will not only resolve its longstanding crisis but also unleash unprecedented avenues for innovation.

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/quintessence/ [Accessed 18 August 2023].

Unappreciated Product Development Skills

August 16, 2023
Article, Capability development, Experts, Management, Organisational effectiveness, Product development, Productivity, Recruiting
Leave a comment

Unappreciated Product Development Skills

Introduction

In the world of product development, hiring for the right skills is paramount. Yet, hiring managers and HR people often fail to appreciate the necessary core skills, and thus certain crucial skills often go unsought, overshadowed by more flashy competencies or specific technical abilities. While technical expertise is a nice to have, ignoring these unappreciated skills can lead to teams and departments that lack cohesion, struggle with efficiency, and miss out on a broader understanding of the development landscape.

Top Ten Overlooked Skills and Their Consequences

#SkillHiring Consequences
1The Importance of the Way the Work Works, incl subsidiarity.Teams lack a holistic view, leading to systemic issues and an inability to see beyond their immediate tasks.
2Risk ManagementTeams are reactive, rather than proactive. This leads to crisis management scenarios and frequently derailed release schedules.
3Role of VariationProjects may frequently miss deadlines or go over budget due to a lack of preparedness for uncertainties.
4Flow OptimisationTeams face frequent bottlenecks, resulting in uneven workloads, delays, and heightened stress levels.
5Feedback LoopsProducts misaligned with user needs or market demands due to a reluctance or inability to seek or respond to feedback.
6Systems ThinkingTeams operate in silos, leading to redundant efforts, inflated costs, delays, poor quality, and a fragmented product experience.
7Value Stream MappingMisaligned priorities, arising from a focus on tasks without understanding their overall product value.
8Make Things VisibleLack of transparency resulting in miscommunications, overlooked issues, and poorly informed decisions.
9Limiting Work in Progress (WIP)Overall productivity and work quality decrease due to excessive multitasking and constant context switching.
10Attending to Folks’ NeedsNeglecting this skill results in disengaged or unmotivated teams, decreasing engagement, discrationary effort and productivity, and increasing turnover rates.

Conclusion

To create a well-rounded and effective software development team, hiring managers migh choose to look beyond just technical proficiencies. By recognising and valuing these often-unappreciated skills, companies can increase the likelihood of building and maintaining cohesive, efficient, and innovative teams equipped to tackle the multi-faceted challenges of modern product development.

As the product development landscape continues to evolve, sadly, appreciation of the essential skills required to navigate it does not. Is it yet time to give these unappreciated competencies the recognition they deserve in the hiring process and beyond?

Offer

If your organisation suffers from any of the maladies listed under “consequences” in the table above, get in touch today for clear, independent advice on steps you can take to tackle the skills shortfall: bob.marshall@fallingblossoms.com

Applying Auftragstaktik in Software Development: Fostering Fellowship Over Hierarchy

August 7, 2023
Article, Nonviolence, Paradigm shifts, Product development, Productivity, Quintessence, Self-organisation, Software development
Leave a comment

Applying Auftragstaktik in Software Development: Fostering Fellowship Over Hierarchy

Auftragstaktik, an organisational philosophy originating from the Prussian military in the 19th century, and more recently the USMC, has found resonance in various spheres, from combat planning to corporate management. At its core, Auftragstaktik focuses on the principle of needs-oriented leadership. It’s the idea that leaders should define goals – the “commander’s intent – and provide the necessary resources, but leave the “how” to subordinates, thus enabling those subordinates’ creativity, flexibility, and autonomy.

However, an emerging question is how to apply Auftragstaktik in environments that seek to de-emphasise hierarchical management structures and instead foster a sense of fellowship. Specifically, in the world of software development, the traditional reliance on junior officer analogues such as team leaders, Scrum Masters, senior developers, or middle managers is evolving. There is an increasing push to build a more egalitarian and collaborative culture, which can sometimes appear at odds with the military hierarchy from which Auftragstaktik emerged.

Here’s how we can reconcile these two approaches and effectively apply Auftragstaktik in software development environments that prioritise fellowship over hierarchical roles:

Foster a Culture of Ownership

The beauty of Auftragstaktik is that it promotes a sense of ownership among team members by providing them the freedom to approach work in ways they find most effective. In a fellowship-oriented culture, this sense of ownership becomes even more profound. Fellowship empowers teams to not only implement solutions, but also identify problems, propose assignments, and provide feedback to others. This fosters a sense of mutual respect, collaboration, and shared responsibility that is central to a high-productivity culture.

Value Collective Intelligence

A fellowship-oriented culture values collective intelligence above individual contribution. Similarly, Auftragstaktik can be implemented in a way that emphasises the strength of the collective team. By articulating clear needs to be attended to (cf. the Needsscape) and allowing the team to collaborate on the means to meet these needs, you draw on the diverse skills, experiences, and perspectives within the team. This maximises innovation and problem-solving capabilities.

Encourage Continuous Learning

For Auftragstaktik to work effectively within a fellowship model, an organisation might choose to promote and value continuous learning. Teams may choose to cultivate their ability to assess their strategies, learn from their mistakes, and continuously adapt. This invites the organisation to provide space for reflection, constructive feedback, and iteration.

Promote Transparency and Trust

Trust is the bedrock of Auftragstaktik and a fellowship-oriented culture. The organisation might choose to trust their teams to devise the best strategies, while team members need to trust each other to carry out their respective parts. This trust is cultivated through transparency in communication, objectives, expectations, and feedback.

Equip Your Team

Finally, for teams to take responsibility for the “how,” they need to be adequately equipped with the necessary tools and resources. This includes not only tangible assets, such as software tools, but also intangible ones such as information, knowledge, skills, budgets, and support.

Summary

In conclusion, applying Auftragstaktik in a fellowship-oriented environment requires a slight shift in focus from the traditional approach. Instead of concentrating on hierarchy and rigid roles, the emphasis should be on mutual trust, transparency, and the empowerment of the team. Such an approach would not only harness the power of Auftragstaktik but also foster a culture of camaraderie, collaboration, and collective ownership, which are at the heart of the fellowship model.

Further Reading

For a complete book detailing the convergence of Auftragstaktik and Fellowship (and Aikido, too), look no futher than my awesome book, “Product Aikido“:

Marshall, R. W. (2013). Product Aikido. Retrieved from /wp-content/uploads/2013/04/productaikido041016.pdf