Why Familiar Was Europe’s First 100% Agile Software House

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