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.

What Fuels Top-Performing Software Companies?

The secret sauce of top-performing software companies often lies in their willingness to explore and implement ideas that fall outside the mainstream. Unlike many companies that stick to orthodoxy and status quo practices, these high-performers embrace the works of thinkers like Deming, Ackoff, Buckminster Fuller, Goldratt, Drucker, Seddon, and Trybus. They find value in methods and theories that many businesses either don’t know about or choose to ignore. This approach fosters a culture of continuous improvement and innovative problem-solving, setting them apart from their competitors.

Why Aren’t These Ideas More Widely Adopted?

There’s a paradox here: The ideas from these thought leaders are available, and their effectiveness has been demonstrated, yet few companies make the leap to implement them. This is usually not due to a lack of resources or information but stems from organisational inertia compounded by ignorance. Companies often feel safer sticking to conventional methods, even when evidence suggests that non-mainstream ideas could lead to significant improvements. This risk-averse mentality can create a barrier to adopting transformative approaches.

How Do Beliefs Impact Productivity?

The collective mindset or shared beliefs within an organisation can serve as either a catalyst or an obstacle to productivity. In high-performing software companies, you’ll often find a culture that not only welcomes but also thrives on unconventional wisdom. This creates a fertile ground for out-of-the-box methods to take root and flourish, driving the company forward in ways that more conventional organisations can’t easily replicate. If you’re curious, my recent book “Quintessence” catalogues and maps over seventy of the unorthodox memes of these top-performing companies.

Can We Simply Adopt Another Company’s Methods?

Transplanting methods from one company to another might seem like a straightforward way to boost productivity. However, those methods were developed within a unique ecosystem, shaped by specific challenges, goals, and culture. Attempting to graft them onto an organisation with differing assumptions and beliefs leads to misalignment, cognitive dissonance, resistance from team members, and even failure of the adopted methods to deliver the expected benefits. “Agile” is a classic example in this regard.

Has Benchmarking Any Value Here?

Many companies rely on industry-standard metrics to gauge their performance, but this approach has its limitations, particularly when comparing against top-performers who use unconventional approaches and thus metrics. These high-performers often evaluate success based on measures specifically tailored to their methods and organisational beliefs. This makes traditional benchmarking ineffective and even misleading when trying to measure up to these high-performing companies.

How Do You Close the Productivity Gap?

If you’re looking to close the productivity gap, tweaking existing methods won’t be sufficient. What’s required is a fundamental shift in organisational beliefs and assumptions that pave the way for consideration and implementation of radical, unorthodox ideas. Companies that are willing to examine their own culture critically, and to challenge the industry status quo, stand a much better chance of making significant strides in productivity.

What’s the Cost of Inaction?

Ignoring the widening gap between your company and high-performers comes at a steep price. As these leading companies continue to innovate and improve, companies that stick to conventional methods risk stagnation. In a worst-case scenario, they become increasingly irrelevant in their industry, losing out on both market share and talent to more forward-thinking competitors.

Remuneration policy reflects an organisation’s culture. It’s a calling card for your company and a key element of employer branding. Given current recruiting challenges, it also determines who wants to join or stay with your company.

What Is A Salary Model?

A salary model, or remuneration policy, is a system of guidance that an organisation uses to determine each employee’s remuneration (a.k.a. package). A typical salary model takes into account things like merit, length of employment, and pay compared to similar positions.

Everyone’s Approval?

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.

~ John Lydgate

Salary models are almost always contentious, and the source of frequent fractious arguments and ill-will. Few people favour being treated just like everybody else, seeing themselves as individuals. Yes, fairness has a role to play – humans and capuchins both being acutely attuned to the notion of fairness. But who adjudicates what is fair when it comes to salaries and other remunerations?

At Familiar, and now at TheQuintessentialGroup, we seek to treat people as adults, and encourage adult-to-adult interactions. Accordingly, we believe that only the individual in question is at all placed to decide what is fair, and thus to determine their personal individual salary or other remuneration. Our experiences at Familiar showed this idea as entirely workable, and helped us learn the amazing up-side to such a salary model.

This perspective also aligns with the Antimatter Principle: “Attend to folks’ needs”. Who else but the individual can truly decide what their needs are, salary-wise? Needless to say, the Antimatter Principle stands proud at the heart of TheQuintessentialGroup’s approach to community-building, and to business.

So, for clarity, this salary model states:

Each fellow decides his or her own salary (or other remuneration, depending on engagement model). Each fellow is free to change salary or other remuneration levels as and when – and as often as – they see fit.

Note: This particulalr salary model is the salary model of choice for TheQuintessentialGroup.

Wrinkles

One wrinkle that did emerge at Familiar, given the totally alien nature of this salary model, was the difficulty some folks had in deciding on the specifics of their package. We discovered that support and dialogue amongst fellows (along with full transparency for all) helped greatly with resolving this difficulty.

Another, more general wrinkle is the collective assumptions and beliefs of the decision-makers and those that sign off – or don’t – on the salary model. The headline of this post is about winning everyone’s approval. Managers and executives that have a sublimated Theory-X view of the world probably won’t approve of this salary model. Which I find sad, for the people and for the performance of the workforce (and thus, of the organisation).

– Bob

Afterword

“Has everyone’s approval” seems to me a pretty low bar. I’d prefer to see a salary model that “everyone loves and raves about”. How about you?

If you’re an expert, there’s little satisfaction or joy in trying to change people such that they begin to adopt the things you know they need to do. They won’t understand nor embrace new ways of doing things, nor new ideas. Not because the expert tells them to, anyways.

You may be lucky and stumble across someone or some group that, by happenstance, has become curious about doing things differently. But in most cases, your expertise is for the birds.

So, taking a job or position in organisations as an in-house expert is most often a stupid punt. Almost exclusively, in my experience.

And in the realm of software delivery, there’s pretty much zero likelihood of decision-makers understanding why doing things differently is the only gateway to better performance.

Obduracy

In my post “Obduracy” of several years ago, I wrote:

“The things organisations have to do to make software delivery successful are well known. And equally well known is the fact that organisations will absolutely not do these things.”

And this ain’t gonna change just because an expert or two gets involved. 

What To Do Instead

The above was observably true back in 1996, when we decided to apply our expertise for our own benefit, baled from any more consulting, and started Familiar.

And it remains true today, some 26 years later. Which is why we’re embarked on a similar venture, second time around. 

Instead of endless frustration in trying to help others move the needle in software delivery, we are, again, picking up the gauntlet and getting jiggy with moving the needle ourselves, through The Quintessential Group.

If you’re an expert in software delivery, I invite you to apply your expertise in starting your own delivery business (we’d be delighted to help). Or, you might like to join us at The Quintessential Group and taste the quintessential experience.

– Bob

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 24 Apr. 2022].

Y’all may like to know that Ian Carroll (of Solutioneers fame) and I are launching a new venture named TheQuintessentialGroup, offering a range of services in the software delivery space. First out of the gate will be “Quintessential Teams“. You can find out more at our shiny new website: TheQuintessentialGroup.com.

Note: We’re looking to revolutionise the world of software delivery, along quintessential lines, and we’d love for you to consider joining us.

First Time Around

Back in 1996 we* found ourselves with the opportunity to demonstrate what we had been telling clients for years – that our** approach to software delivery was way more productive than:

a) the industry norm

b) their current approaches

c) what they could ever believe possible

*myself and some colleagues at the Java Centre within Sun Microsystems UK, along with some mutual friends.

**the company we named “Familiar”.

Second Time Around

Now, we*** find ourselves in the same situation once again. Our**** approach to software delivery is again way more productive than:

a) the industry norm

b) our clients’ current approaches

c) what our clients and prospects could ever believe possible

***Ian Carroll and myself

****the company we’re naming TheQuintessentialGroup

Nothing Like Agile

The first time around, commencing circa 1996, our approach could be described as an Agile approach (Scrum-like, albeit risk-based).

The second time around our – distinctly different – approach can be described as the Quintessential approach (nothing like Agile, Scrum, etc. – albeit still very risk-oriented).

Alien Tech For Human Beings

And this second time around, we again lead the industry in breaking the mould and demonstrating the validity and sheer awesome power of the Quintessential approach.

The Quintessential approach is no secret. It’s all laid out, in detail, in my book(s). And yet we defy anyone to replicate this game-changing alien tech. At least, until they have thrown off the shackles of outmoded and crippling beliefs about work and how work should work.

And that ain’t likely to happen any time soon. Although TheQuintessentialGroup.com can help with effecting such changes, too – see my book Memeology, for starters.

If you’re at all interested in the quality, cost, timescales, and predictability of software delivery, you might like to take a look at our newly launched website: TheQuintessentialGroup.com. We have big ambitions and big plans – and we’re hiring too!

Yes there’s more than a little déjà vu here at Sensei Towers at the moment. Familiar was an outstanding success, vindication, trailblazer and golden goose back in the late 90’s. We have every expectation that TheQuintessentialGroup will surpass even that outstanding benchmark.

Putting a dent in the Universe.

– Bob

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 22 Apr. 2022].

Marshall, R.W. (2021). Memeology: Surfacing And Reflecting On The Organisation’s Collective Assumptions And Beliefs. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/memeology/ [Accessed 22 Apr. 2022].

Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. [online] leanpub.com. Falling Blossoms (LeanPub). Available at: https://leanpub.com/heartsovediamonds/ [Accessed 22 Apr. 2022].

Twenty eight years ago (i.e. 1994) almost no one was interested in doing software development differently. Waterfall and the V Model ruled the roost. And structured methods (SSADM, Dataflow diagrams, etc.) were de rigeur. I was fortunate in finding the ear of the Finance Director of Barclays Bank, who had two urgent projects he needed to see completed in double-quick time, and with no wiggle room for missing the delivery dates. He felt he could no afford to go down the traditional (slow) route.

Of course, in 1994 the term “agile” had not then been applied to software development (at least, in the way the Snowbird folks appropriated the term circa 2001),

After successfully delivering Barclay’s projects, I moved on to Sun Microsystems’ UK Java Center and brought my “new” approach (then being called “Jerid”) with me.

Having transferred my approach and ideas into several of Sun’s corporate client base (mainly banks and other financial institutions in the City), I moved on to found “Familiar” circa 1996. (Being then the first 100% Agile software house in Europe). Jerid served us well, and continues to do so – now named Javelin – up to the present day.

28 Years On

Twenty eight years on and history repeats itself. Almost no one is interested in doing software development differently. This time around, I find myself the guardian and steward of the Quintessential approach. Another step forward at least as great as Jerid was in 1994.

Sigh. And deja vue.

– Bob

I’m minded to write something positive for a change (!) so I thought I might share how much fun a quintessential development organisation can be to work with. (I say work with, because we had almost no power structures, no managers, no bosses, and everyone was a colleague, a fellow.)

Familiar was a software house and consultancy, based near Reading UK (some forty miles west of London), which I started and led circa 1996-2000.

The years at Familiar was, for many of us, enormous fun. We were doing great things for our clients, bonding as a group, and learning loads about how to become a Quintessential organisation. The social side was just as much fun as the business side. Indistinguishable, really. We placed a lot of emphasis on the social aspects of the organisation:

• Company-funded weekends away in plush country hotels – for the folks in the company along with their significant others.
• Regular dIning out as a group, on the company’s expenses. 
• Collaborative sessions (sprint planning and the like) in each others’ homes.
• Other group social events (e.g. exhibitions).
• An office configured for socialising – and learning – as much as for work (lounge, sofas, library, books, kitchen, etc.).

This was all made possible by the success we had commercially – a virtuous circle where fun led to great work for clients led to high margins led to funds for more fun… 

It was the kind of win-win-win (clients, us, suppliers) that quintessential organisations regard as normal.

If you have any questions, I’d be happy to answer them.

– Bob

The Starting of Familiar

It often seems that folks automatically assume that all useful software development innovations come out of the United States. And innovations (and innovators) from places other than the US have little merit. Yet specific innovations have a tendency to pop up, more or less simultaneously, in various places:

“The concept of multiple discovery (also known as simultaneous invention)  is the hypothesis that most scientific discoveries and inventions are made independently and more or less simultaneously by multiple scientists and inventors. The concept of multiple discovery opposes a traditional view—the “heroic theory” of invention and discovery.”

~ Wikipedia

I rarely bother to mention Familiar’s independently inventing something very much like Scrum (we called it Jerid, now Javelin) back in the 1994-1996 time frame. Not inspired by Nonaka and Takeuchi’s New New Product Development Game, nevertheless Jerid featured:

• Two-week interations
• Time-boxing
• Sprint planning and sprint retrospectives
• Self-organising teams
• Focus (through e.g. quantification of objectives)
• A risk-based approach
• (Later on) Flow

I have no wish to tarnish or undermine Jeff and Ken’s achievements with Scrum. Nor the somewhat later accomplishments of the Snowbird folks. Just putting down a marker for us Brits. And other nations too.

Aside: The Lean manufacturing community has largely forgotten about Frank George Woolard, a Brit whose work preceded and some say inspired the Japanese, notably Eizi Toyoda.

– Bob

Further Reading

Don’t Look For Inventions Before Their Time ~ Matt Ridley
The Back Story – Finding a Lost Classic ~ Bob Emiliani

Familiar Limited was a Reading-based software house/consultancy that I started with a colleague in early 1997.

One question I regularly get asked is “How did the name ‘Familiar’ come about?”

I had thought I’d already answered this question, but upon looking for that explanation can’t find it. So here it is (for the record):

I’ve long favoured ambiguous or multi-meaning words (homonyms). We chose the name “Familiar” on that basis. Here’s the three meanings we sought to present:

Familiar as in: well-known, easily recognised.

Our approach to software development was way different to what clients had come to expect from software house suppliers. We were decidedly unfamiliar in our approach, but took pains to appear familiar and comforting from the point of view of our clients interacting and doing business with us.

Familiar as in: Of the Family

We used the family as the metaphor for structuring the company. “Family” were close-knit, and each had equity and a say in the running of the company. “Friends” were (only) a little less invested.

Familiar as in: Witch’s Familiar

What we did for our clients was, for them, largely indistinguishable from magic. Or at least, that was our aim. Our “magic”, our technology, was how we did things. In other words, channelling the Arthur C. Clarke quote:

“Any sufficiently advanced technology is indistinguishable from magic.”

~ Arthur C. Clarke

Note also the coquettish reverse “F” in the name, intended to evoke a quizzical, playful spirit (looking a bit like a question mark).

You might like to read my other posts about Familiar too, if this post has piqued your interest.

– Bob

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

• Control Document
• Articles of Understanding
• Glossary of Terms
• Statement of Purpose
• Case for Action
• Vision
• Folks That Matter and their Needs
• Risk Parade
• Top Risks
• Functional Requirements
• Non-functional Requirements aka QQOs
• Critical Success Factors
• Feature Schedule
• Quality Plan
• Test Plan
• Change Control
• Cycle Plans
• Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).

Javelin

For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

[Note: I regard this post as unfinished – I’m publishing it now in the hope that some kind readers will help me in bringing it to something nearer completion. Also, you might like to check in now and again for possible updates.]

A Conversation

Here’s a transcript of a conversation that didn’t take place, but could have, in the vicinity of Reading, England, circa 1999.

Sam: Thanks for allowing me to get some insights into Familiar and what makes it different from other software houses.

Bob: Thanks for showing an interest. We feel the UK software industry would serve society better if more folks had some exposure to what we’re doing here, and maybe take on board some of the principles that have guided us so far.

Sam: I’d like to start with the one thing that intrigues me most. The way you set salaries here. I’ve heard you allow people to set their own salaries? Is that true? Can you explain why you do that?

Bob: Surely. When we set up Familiar, some three years ago now, we all decided we wanted a company that felt more like a family, both for the folks working in the company, and for all the other folks involved – our suppliers and customers, for example. That’s reflected in one aspect of the name “Familiar”, of course (I won’t go into the other aspects of the name, just now). At the time, I was reading the book “Families and How To Survive Them” by John Cleese and Robin Skynner. That book led me to Eric Berne’s work on Transactional Analysis. Berne’s work got me thinking about building a community where Adult-Adult interactions and relationships were the norm.

Sam: So how does having folks set their own salaries play into that idea?

Bob: Well, our approach to salaries – and the same with equipment, working times, locations and the nature of the relationship between the community and the individual – is to have people choose for themselves. If we want folks to behave more often like adults, it makes sense to us to treat them like adults. Folks capable of making their own decisions about the things that matter to them, and to the community as a whole. Moreover, who is at all equipped to decide what salary, etc., suits their needs – other than each individual?

Sam: That sounds really out there. How do people find it?

Bob: It’s true it’s not without its challenges. Firstly, people just starting with us often haven’t thought very much about their commercial value. In other words, at what level they might set their salaries. What might be “fair”. And if someone asks for any given salary, cap-in-hand like, I push back. As far as I’m concerned – and speaking on behalf of the community, too – it’s not a negotiation. Someone announces their intent to bill at a certain rate, or get paid a certain monthly stipend, and that’s what happens. I see it as a positive, all round – for them, others, and the community as a whole – for someone to think about what they charge. You might say “what they’re worth” – but that’s too crass a phrase for me. And then there are other challenges, too.

Sam: Such as?

Bob: Folks billing or getting paid too little. Strange as it seems, our overall staff costs are rather lower than we expected for a software house such as ours. Nobody’s complaining, really. But I’d like to see folks reap greater financial rewards, not just the – less tangible but no less important – rewards of community, fellowship and interesting projects. Americans call wages “compensation” – I guess folks here don’t have to receive as much compensating for the crap as in other companies.

Sam: So you don’t get anyone “trying it on”?

Bob: Not to date. We subscribe to McGregor’s Theory-Y, which invites us to believe that employees are internally – or ‘intrinsically’ – motivated, enjoy their job, and work to better themselves without a direct (financial) reward in return. We’ve found this to be a valid assumption in our case. We strive to make Familiar a place when folks love to get together and do interesting, meaningful things. As our Credo states: “Familiar exists for folks to come together and explore what ‘fulfilment’ means for each one, individually”.

Sam: And as for the other things folks can choose? You mentioned equipment, locations, working times, and the nature of the relationship with the community?

Bob: Again, we want folks to feel like we regard them as adults, with the capacity to choose what’s best and most suitable for them, and thus for the (extended) community too. So everyone gets to choose their development computer(s), monitors, keyboards, etc., and development platform (operating system, tools, languages and such). Some folks have their own kit, and for others Familiar buys some or all of the kit. Some interoperability considerations apply, of course, and the customer often has some requirements relating to the operational/production environment. Project teams organise themselves to factor all this into the mix as part of their development process.

Sam: And locations?

Bob: Everyone works where they feel most comfortable, convenient or productive. Different issues affect different people. And folks are invited to vary their location as they see fit – and as suggested by the nature of the task they’re involved with at a given hour or on a given day. We have our office here, of course, with the public cafeteria, bookable meeting rooms, and our private community office space divided into bullpen, library/lounge with couches, a number of personal offices and the kitchenette. But folks work from home – and each others’ homes – as often as not. We also make a point of getting out as a group, both for meals and drinks in local restaurants and pubs, and for longer weekends away at comfy hotels. One chap who would otherwise have a long commute has a satellite office nearer to his home location. Again, “everybody’s different” – and capable of making their own choices.

Sam: Working times and the relationship with the company/community?

Bob: Folks work the hours that suit them, with the only proviso that the clients’ schedules get consideration. We have some early birds, some late birds, and some bird-of-a-feather (folks who like to regularly pair or work in sub-groups). The latter means they coordinate (self-organise) their schedules and locations, to some extent. As for relationships with the community, I’m talking about what some other companies might describe as the “contractual relationship”. We have some hour- and day-rate “contractors”. Some weekly paid and monthly paid “employees”, and a couple of folks – like myself – whose relationship falls outside those categories. And while we’re talking about pay, I guess I could mention the bonuses. We don’t have any formal bonus scheme as such, but when a particular project goes well, folks get together to consider the costs and revenues and decide if a team bonus is appropriate and what level and split would suit.

Sam: Would you do anything different if you found yourself involved in a different community in the future?

Bob: Nothing significantly different. Excepting that circumstances prevailing when we started Familiar allowed us the opportunity to trial these “wacky” ideas in practice. Such circumstances may not present themselves next time around. Folks have to be open to the ideas of doing things differently, or I suspect a similar scenario might never even get off the ground.

Sam: Do you have any advice for others thinking about building this kind of environment for their businesses?

Bob: I hate giving advice – I find it rarely followed. But one thing I would say – don’t underestimate the time needed for, and the value of, supporting folks who might feel uneasy from time to time about the choices they’re enabled to make. I’ve put in much time supporting people here when the way forward has seems unclear for them personally. But I feel it’s never been enough support, and I always want us to do more. And one word of caution: Time. It’s taken us three years of daily practice to even begin to understand how these ideas all fit together. The benefits are definitely there, we’re demonstrated that, but few companies seem to have a longer-term view. Along the way, we have discovered some useful shortcuts.

Sam: Thanks, Bob, for sharing your experiences with me, and my readers.

Bob: My thanks to you also, Samantha. It’s been fun.

[End]

– Bob

Further Reading

The Starting of Familiar ~ Think Different blog post

Many people have expressed an interest in learning more about the evolution of Organisational Psychotherapy. This post attempts to go back to the roots of the idea and follow its twists and turns as it evolved to where it is today (January 2020).

Familiar

Around the mid-nineties I had already been occupied for some years with the question of what makes for effective software development. My interest in the question was redoubled as I started my own software house (Familiar Limited) circa 1996. I felt I needed to know how to better serve our clients, and grow a successful business. It seemed like “increasing effectiveness” was the key idea.

This interest grew into the first strand of my work: Rightshifting. I had become increasingly disenchanted with the idea of coercive “process” as THE way forward. I had seen time and again how “process” had made things worse, not better. So I coined the term Rightshifting to describe the goal we had in mind (becoming more effective), rather than obsessing over the means (the word “process”, in my experience, conflating these two ideas).

“Rightshifting” describes movement “to the right” along a horizontal axis of increasing organisational effectiveness (see: chart). Even at this stage, my attention was on the organisation as a whole (and sometimes entire value chains) rather than on some specific element of an organisation, such as a software development team or department.

Circa 2008 I began to work on elaborating the Rightshifting idea, in an attempt to address a common question:

“What do all these organisations (distributed left and right along this horizontal axis) do differently, one from the other?”

Subsequently, the Marshall Model emerged (see: chart). Originally with no names for the four distinct phases, categories or zones of the model, but then over the space of a few months adding names for each zone: “Ad-hoc”, “Analytic” (as per Ackoff); “Synergistic” (as per Buckminster Fuller); and “Chaordic” (as per Dee Hock).

These names enabled me to see these zones for what they were: collective mindsets. And also to answer the above question:

Organisations are (more or less) effective because of the specific beliefs and assumptions they hold in common.

I began calling these common assumptions and beliefs a “collective mindset”, or memeplex. This led to the somewhat obvious second key question:

“If the collective mindset dictates the organisation’s effectiveness – not just in software development but in all its endeavours, across the board – how would an organisation that was seeking to become more effective go about changing its current collective mindset for something else? For something more effective?”

Organisation-wide Change

Organisation-wide change programmes and business transformations of all kinds – including so-called Digital Transformations – are renowned for their difficulty and high risk of failure. It seemed to me then (circa 2014), and still seems to me now, that “classical” approaches to change and transformation are not the way to proceed.

Hence we arrive at a different kind of approach, one borrowing from traditions and bodies of knowledge well outside conventional management and IT. I have come to call this approach “Organisational Psychotherapy” – named for its similarities with individual (and family) therapy. I often refer to this as

“Inviting the whole organisation onto the therapist’s couch“.

I invite and welcome your curiosity and questions about this brief history of the evolution of the idea of Organisational Psychotherapy.

– Bob

Further Reading

Memes Of The Four Memeplexes ~ A Think Different blog post

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe (Brussels, Belgium) when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

• RAD (Rapid Application Development – James Martin, etc.)
• JAD (Joint Application Development)
• Evolutionary Development (Gilb)
• Rapid Iterative Development
• Risk Management (Capers Jones, etc.)
• TQM (Crosby, Juran, Shingo et al)
• NextSTEP
• Modula-2 (Wirth)
• Eiffel (Meyer)
• Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

Familiar was a software house based near Reading UK (some forty miles west of London), which I started and led, along with several ex-Sun Microsystems colleagues, circa 1996-2000.

This post is about why we decided on “Agile” as our general approach to getting things done. It’s not so much about why we were the first.

One Hundred Percent Agile

This refers to the fact that all our work – both client-facing and internal – was conducted in an “agile” manner. Which is to say, the way we worked back then looked something like Scrum does nowadays, e.g. with two week iterations, emergent “requirements” and regular delivery of working things into production.

Of course, this was some five year years before the label “Agile” was to be coined by the Snowbird folks and therefore some years before this way of working began to be applied more widely, by others, in the software house kind of context.

You could also say we were 100% Agile because (what came to be identified as) Agile principles informed our approach to working across the whole organisation – both our own organisation and that of clients – and not just in the software development work we did.

Why

We didn’t call what we did “Agile” or “agile”. We weren’t trying to replicate someone else’s approach or ways of working. We weren’t trying to be agile, we were intent on being great! And for us, great meant “highly efffective”.

We adopted our own approach to work – primarily but not exclusively software and product development work for various clients – because we wanted to better meet the needs of our customers, of ourselves and of our company. And incidentally, the needs of our suppliers, our loved-ones, our shareholders – mostly the folks working for the company – and our channel partners, too. We continuously evolved our approach – which we then called Jerid, now Javelin – both to adapt to changing contexts, and to more effectively meet folks’ needs, as we learned more about what those need were and how to go about better meeting them.

Let me say that again, we chose to work the way we did because we wanted to better meet folks’ needs. I wouldn’t have uses this form of words back then, but with the benefit of hindsight this is what we were intent on doing.

We had all seen enough of the IT/software industry to know that the industry norm was far from meeting anyone’s needs effectively. We knew we could do much better. And we knew the basics of how. We were determined to continue to advance our knowledge in that regard.

Success

We succeeded, I believe, because the whole organisation was geared to the Jerid approach, and there were no discontinuities, such as we see in many organisations trying to “go agile” today. By which I mean, for example, the discontinuities between the “agile” software teams and the rest of the containing organisation, with its raft of decidedly non-agile – even anti-agile – beliefs, principles, processes, policies, procedures and organisational structures.

Put another way, our way of working met folks’ needs, not because of any specific characteristics – NOT because it was, or we were “agile” – but because we wanted to be great at what we did, and took time and effort to understand how we could achieve at least some of that aspiration.

We were building an environment in which folks could come together, work well together, find and grown intrinsic motivation, build positive interpersonal relationships both internally and externally, and excel.

– Bob

It was twenty years ago this month I finished my first assignment as a Scrum Master at Barclays Bank Head Office in London.

Of course, Scrum hadn’t been invented then, and my role wasn’t actually called “Scrum Master”. But anyone looking back at what I was doing, day-to-day, would probably recognise much of it as Scrum Mastering. Facilitation, identification and removal of impediments, a buffer between the team and distracting influences, guidance in a common approach, and so on.

Actually, it was more than just a Scrum Master role, because as well as delivering some key NeXTStep projects for Barclays, we were also inventing our own approach to software development, involving self-organisation, inspect-and-adapt, short time-boxed interactions, etc., which we came to call “Jerid” (and which over the years evolved into “Javelin“).

The label “Agile”, along with the Agile Manifesto, did not emerge until the Snowbird gathering in 2001, some seven years after we started our journey. So at the outset, we chose to describe what we did in the terms then prevailing, including, variously, RAD (rapid application development), RID (rapid iterative development) and JAD (joint application development).

Labels aside, our approach was a fusion of my own experiences of software development up that point, together with:

• Tom Gilb’s Evo method, in particular, quantification cf Principles Of Software Engineering Management.
• De Marco and Lister’s Peopleware.
• Ed Yourdon cf Decline and Fall of the American Programmer.
• A gaggle of works on software risk and risk management.
• Ideas from the quality movement (TQM, PDCA, et al).
• A sprinkling of stuff from software metrics.

Since those early days, I’ve played the role of Scrum Master or Agile Coach on some dozen occasions, interspersed with a number of other, generally more organisation-wide roles. Notably, the experiences with Jerid/Javelin at Barclays and other clients in the mid-nineties led to me joining Sun Microsystems’ UK Java Centre, and thence to starting the first 100% Agile software house in Europe (Familiar Limited, 1997).

Looking Back

Looking back today, at the things I’ve learned and how the Agile approach has emerged and grown in credibility and awareness over the past twenty years, some highlights stand out:

• We started from much the same position as the later Snowbirders: As practitioners disillusioned and frustrated with the “Big IT” approach to software development projects, often called “Waterfall” but more honestly described as “chaos, ineptitude, arse-covering and panic”. Practitioners wanting to do a good job, with the belief that we knew better how to go about developing software.
• Pretty soon, after a few projects and clients, it became obvious that being in charge of our own work and approach, at the team level, was only shifting the burden. I realised that most key impediments to teams’ progress and productivity lay outside the control of the team, in the wider organisation.
• Aside from Agile – as it came to be known – being a “symptomatic solution”, it has also failed to address the key issues of deliberately developing the “right things” and of explicitly managing the risks inherent in software development.
• Management can be very supportive of teams working on critical projects, even to the extent of allowing much leeway in adopting new approaches, and circumventing prevailing rules and mores.
• Management can also make bat-shit crazy decisions guaranteed to make delivering anything near to impossible.
• Businesses generally have a host of pressing matters, and only rarely is software development and its effectiveness anywhere visible on the business radar.
• The Agile (Snowbird) approach was never “designed”, and in particular never designed for effective adoption by real, fallible human beings in less than ideal conditions.
• Unlike other “agile” approaches, Javelin started from the position that “software development is risky, and success requires we manage those risks”.

“Risk management is project management for grown-ups.”

~ Tom DeMarco and Timothy Lister

From Processes To People

Over these twenty years, I’ve been seeking an answer to the question “Why is software development so badly handled, so ineffective, so broken, almost everywhere we look?” I’ve tried more or less formal project management, risk management, heavyweight process (CMMI), lightweight process (Agile, Javelin), management, leadership – all kinds of approaches and good-on-paper solutions. It’s taken me this long, and a circuitous journey down many cul-de-sacs, to arrive at my present understanding.

And what is my present understanding? That that only thing that really matters is the people involved in the endeavour. They don’t have to be particulary smart or experienced, but they do have to be curious and interested. And above all, motivated. All else pales into insignificance.

After twenty years, I still enjoy helping people develop software, and make a pretty good Scrum Master. Not that I’d suggest you ever hire a by-the-book Scrum Master – the role as defined has just too many built-in dysfunctions to make it useful.

– Bob

[Tl;Dr: Teams can be more effective by eschewing both Scrum Master and Product Owner – if they can count on getting the support they need when they need it.]

I’ve written before about Familiar and how we delighted both our customers and ourselves by the way we approached software development. And my recent observations on the role of Scrum Master seem to have struck a chord.

At Familiar, we had neither Scrum Masters – although using a Scrum-like approach to development – nor Product Owners. And we did just fine. Better than fine, actually. Our teams found their own ways of working, handled their own interfaces, and gained an effective understanding of customers and their needs, by themselves. With support from one or more extra-team specialists, when the team decided they needed it.

I have seen teams struggle when they have to go it alone in finding new and more effective ways of working, especially if they come from another place, like a batch-and-queue (a.k.a. waterfall), project managed, big-requirements-up-front past.

Yet teams of highly intelligent, reasonably motivated folks can exceed expectations when allowed to make their own choices, so long as they know how to call for help and can do so, quickly and often, whenever they feel they need to.

Perceived Risk

The idea that people have to be supervised is deeply ingrained in our view of work. The very notion of allowing teams their head without a Scrum Master or Product Owner to watch over them, keep them on track and generally boss them about seems highly risky. Despite all the evidence and advice, most organisations are still in no way ready to embrace self-organisation without the safety net of supervision. And with supervision, self-organsation offers hardly any advance at all.

Support

By support, I mean someone – or some number of people – that can help the team find ways past the obstacles they will regularly encounter. Some shared context is useful, so the helper(s) may have some longer-term relationship with the team, rather that just being called in “cold”. Some of the skills useful in such helpers will include Amanuensarian, coach, and therapist. I wrote a fuller list some years ago.

Given the wide range of skills that might be needed, only the very largest organisations are likely to have such people on staff.

Protection

Another often quoted aspect of the Scrum Master role is the protection he or she can afford the team, from interruptions and other disruptions. I wouldn’t want to downplay the value of this, but I would be much happier to see teams themselves more aware of the value of flow and the need to minimise interruptions – including those self-generated. Can teams handle interruptions themselves? Yes – with adequate awareness and support.

Why Not The Scrum Master

Apart from the Universal Scrum Master Failure, the very nature of the relationship between many Scrum Masters and their teams tends to an unhealthy power dynamic. Many managers – unfairly or unreasonably, in my view – hold the Scrum Master accountable for the results of the team. Naturally, then, the Scrum Master feels under some form of pressure (such as duty, self-interest, or similar) to push the team to do “better”. And, human nature and learned behaviour being what is it, oftentimes this pushing can be coercive and violent. Few realise the significant damage that such a dynamic wreaks in collaborative knowledge-work.

Undoubtedly there are (a few) Scrum Masters that avoid this dynamic. These folks appreciate the need to create an environment where the team can find motivation (to the extent they so choose) and learn. By learning, they become more effective over time. Unfortunately, the few enlightened Scrum Masters rarely find themselves in organisations where cultivating this kind of environment for their team is anything but excruciatingly difficult and painful for themselves.

Both of these conditions together – “enlightened” Scrum Masters and “fertile” organisations soil – are necessary to allow the Scrum Master role to deliver value. It’s so rare for both these conditions to exist at the same time in the same place as to mean that maybe less than 10% of situations would derive value from having someone in the Scrum Master role.

Why Not the Product Owner

The issue of power dynamics has less impact in the relationship between teams and their product owners. Although the nature of that relationship is very varied, more varied even than that of Scrum Master and team.

I reject the Product Owner role for different reasons. Specifically:

• Setting up a division of responsibilities increases the likelihood that the team will – in practice – relate less well to customers and users, and their concerns.
• Having a distinct Product Owner reduces the opportunities for emerging technical possibilities to inform the direction of evolution of the product. Put another way, teams often uncover opportunities for new, as-yet unthought-of features, and directions for the product, but for a host of reasons these opportunities go by the board.
• The Product Owner role allows for “absentee” Product Owners, where key customer intelligence is not gathered, or not passed on to the team. When the team is handling these matters, it’s less likely for such matters to get overlooked.

Summary

In summary, if I were on a development team, or responsible for one, i’d want neither a Scrum Master nor a Product Owner. I would instead take pains to ensure that the team had a wide range of skills and experience at its beck and call, and the know-how of how to pull such skills as it needed them. To reduce delays, this may mean having one or more such people on hand, close-by, at all times. This does not mean a Scrum Master.

– Bob

When, nearly twenty years ago, I started Familiar it was with a very clear and declared purpose:

“To allow people to come together and discover what ‘fulfilment’ means for each of them as individuals.”

At the time, few working with us understood the import of that purpose. And those observing from the sidelines, even less so. In fact, most outside observers called it “madness” or “apple-pie land” or some such. Maybe it was an idea ahead of its time.

But now, wiser heads – such as Alain de Botton, Nilofer Merchant, Professor Gary Hamel, Simon Sinek, et al. – write about the need for a more humane workplace. And of course, W Edwards Deming and Peter Drucker were writing and teaching about this kind of thing half a century ago.

“One of the most Googled questions is: ‘What should I do with my life?’
There’s a fantasy that there’s actually an answer out there.”

~ Alain de Botton

De Botton believes there is a desperate need for more companies that are explicitly focused on working out what someone’s talents and inclinations are, identifying their potential, then guiding that person towards a place in the economy where this potential may be best applied and expressed.

I so believe, also. I suggest companies and organisations which lend support to their people in their search for meaning will reap the harvest in many beneficial ways.

And I have proposed the Antimatter Principle as a means to address this and make it happen.

What do you believe?

– Bob

Further Reading

Man’s Search For Meaning ~ Viktor Frankl
Talent Will Not Be Wasted For Much Longer ~ Alain de Botton

I first hit on the notion “Attend to folks’ needs” – only very recently named by me the Antimatter Principle – back in 1996. We had just launched Familiar Ltd, and our first big commercial project was to build a self-service web application for the corporate customers of a large Telco. As one of the first Agile software houses in Europe, we of course applied Agile principles (although not the label) in the conduct of the project.

Aside: Yes, we were still “doing projects” back then.

One key aspect of the project was discovering just what our Telco client – and, by proxy, their customers – wanted us to build. Most of us has been around the block enough times to know the importance of “building the right thing”. Regular interim releases of the evolving product was one of our primary means to this end. But from the outset we also began asking, recording and sharing what all the folks involved in the project needed from it.

You can see a very simplified example of this approach described in the post “Nonviolent Project Management“.

Not Just Customer Work

We did not apply the Antimatter Principle just to our customer projects, though. We used the same principle in the inception and evolution of the whole company, too. For both our customer projects and the company, we sought the needs of everyone involved – developers, customers, suppliers, channel partners, everyone. Everyone, that is, that was willing to have a say.

Of course, it was early days for these ideas. We made some mistakes. And some useful discoveries along the way.

Since those days, I’ve applied much the same Antimatter Principle in just about every engagement and role I’ve had. Sometimes it’s coincided with stellar success (like the aforementioned Telco project). Sometimes it’s coincided with a train wreck. Most often, the latter has been in organisations where attending to folks’ needs has been unimaginably alien. I’ve learned some lessons from that, too. (And see cautions, at end).

Unimaginable

Some folks have responded to my recent posts suggesting that they couldn’t imagine an organisation that cleaved to the Antimatter Principle. What it might look and feel like. How it might work in practice. Having not only imagined it, but experienced it for real, I thought some pointers might prove valuable. Here’s some of the things that made it not only possible, but a joy to be part of:

Quantification

Quantifying folks’ needs – even in the most rudimentary manner – made discussing them much easier and less ambiguous. We happened to use a variant of Evo (cf. Tom Gilb) for this.

Fit Feedback

Our takes on our own – and other folks’ – needs were mostly educated guesswork. Conscious of this, yet not fazed by it, we tried to deliver quickly on a solution to each of these guesses – so that the person or group involved could try it on for size and determine how close to the mark our guesswork had been.

“You can’t really know what you need until you get it. Only then will you know whether you need it or not.”

~ Marshall Rosenberg

Integrated, Intentional

Over time, we invented various means to explain our approach, and to solicit, record and act on folks’s needs, and built these means into the way our work worked. “Stakeholders and their Needs” is one example of this kind of thing. The evolving record of who were our stakeholders, and their (ever-changing) needs formed one element of a broader “project control dashboard” (a.k.a. context radiator) – which also served to record and, more importantly, share and make visible other aspects of the work:

• Project Name
• Project Charter
• Statement of Purpose
• Case For Action
• Vision
• Stakeholders and their Needs
• User Stories or Use Cases (derived from and traceable to Stakeholders needs)
• Quality Objectives (also derived from and traceable to Stakeholders needs)
• RIsk Parade and Top Risks
• Critical Success Factors (key quantified aspects of the Purpose)
• Outline Feature Schedule (including milestones or integration dates)
• Glossary of project-specific terms
• Project address book
• Miscellanea (e.g. quality, test and change plans – depending on folks’ needs)

Aside: This general form served the fairly standard needs of a wide range of projects. Each particular element only appeared, and was elaborated, to the extent that some folks had expressed a need for the information. Further (one-off) coordination, etc. needs were met on an as-needed basis.

Dialogue

For some of our staff, and customers too, the whole idea of a company going out of its way to seek out and listen to their personal needs, and moreover act on them, in an organised and intentional way, was bizarre in the extreme. In a refreshing way. (We selected our customers and suppliers – and staff too – with much care).

For staff in particular, I can remember many intense conversations on the sofas or over a pint, exploring the implications of what I now know as the Antimatter Principle.

Afterword

That this all began nearly twenty years ago causes me some chagrin. Not least because of how it’s taken me so long to come to appreciate the role of the Antimatter Principle in our success at Familiar – and other occasions since.

Having experienced it, I have little doubt that the Antimatter Principle was at the root of the joyous experiences I have both witnessed and participated in over the years since I first began to “Attend to folks’ needs”.

– Bob

Caution! Attempting to treat people as if they matter, without winning the understanding and active support of your higher-ups and your peers, may cause alienation, organisational cognitive dissonance, damage to your credibility, and to your career.

Caution! Attempting to treat people as if they matter, without first winning their trust and understanding, may cause suspicion, resentment, gossip, and unforeseen consequences.

Caution! Attempting to replicate this story in your own organisation may require experimentation, adjustments for your own context, and sensitivity to the needs of the people involved. Your results may vary from those reported here.