Twenty Years a Scrum Master

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

Let The Team Make The Difference

November 4, 2014

Agile, Familiar, Fellowship, Organisational effectiveness, Teambuilding

2 Comments

Let The Team Make The Difference

[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

Needs And Fulfilment

October 25, 2014

Antimatter principle, Familiar

Needs And Fulfilment

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

Roots

October 15, 2013

Agile, Antimatter principle, Familiar, Organisational effectiveness, Software development

2 Comments

Roots

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.

Nonviolent Employment

January 6, 2013

Agile, Familiar, Fellowship, Organisational effectiveness, Psychology, Rightshifting

9 Comments

Nonviolent Employment

Since I’ve begun looking back on past experiences through the lens of Nonviolent Communication, I have come to see this philosophy as permeating many of the policies and decisions with which I’ve been involved over the years.

I’ve written most recently about a needs-based approach to managing projects, and the congruence of that approach with nonviolent precepts.

Only since reflecting on that post have I noted a similar nonviolent thread within the employment policies we had at Familiar.

Voluntary Assignment

“Accept the fact that we have to treat almost anybody as a volunteer.”

~ Peter F. Drucker

Everyone working with Familiar had the freedom to decide which assignments they wanted to work on, and which not. Folks could, at any stage (well, in practice at Sprint boundaries) opt in or out of working on something that was already in progress.

This meant that work had to be in some way attractive, literally. And yes, sometimes this meant we as a company turned away potential business because no one found it attractive enough to commit to working on it.

In NVC terms, if a piece of work did not meet someone’s needs, they were under no obligation to spend time on it.

Status

Everyone had the choice of how they wished to engage with the company. This meant they could consider what they needed – most obviously, in terms of security and continuity of engagement. The options ranged, in practice, from independent subcontractor, through contractor, employee and on to e.g. indentured serf.

And this was flexible, in that someone could change their status as and when they saw fit. In NVC terms, people could make direct, specific, and actionable requests as to the way in which they wanted to engage with the company, at any given time, contingent upon their needs as they saw them.

Compensation

Everyone was free to set their own rate or salary. At the time this was an idea borrowed from i.e. Semco and St Luke’s and rationalised via Transactional Analysis. By which I mean that we wanted a community where everyone could learn how to relate to each other as adults. Who can know what someone’s income / salary / fee needs are better than that person themselves? Indeed, can anyone ever have even an inkling of the personal circumstances of someone else? If not, how could it ever be possible to meet those needs?

Kit

Everyone was free to choose their own equipment, supplied by the company if that’s what they wanted (needed). They were also free to choose their own development tools (editors, repositories, etc), hours of working, and place(s) of work. Whatever best met their individual needs.

Reflections

With the benefit of hindsight, I can see some close parallels between the policies we evolved at Familiar, and the precepts of Nonviolent Communication. I feel sure that these parallels – and in particular the almost accidental focus on folks’ needs, and their subsequent making of requests – contributed much to the wonderful working environment and sense of community at Familiar.

I believe too that the policies described here are the natural evolution of the basic idea that is McGregor’s “Theory Y” (not that we had any managers in Familiar).

– Bob

Zen and the Art of Organisational Enlightenment

August 8, 2012

Familiar, Organisational effectiveness, Organisational Therapy, Rightshifting

4 Comments

Zen and the Art of Organisational Enlightenment

The Enlightened Organisation

I think it’s fairly safe to say that most organisations lack enlightenment. That is, few indeed are those that perceive their true nature, are self-aware (in the sense of consciousness of their own thought processes, motivations and behaviours) and can act on that perception for positive change. I think it fair to say that most organisations exist in a perpetual state of dukkha.

Does this matter? Does it, for example, impact the bottom line? I’d say yes on both counts (yes it matters, and yes, it impacts the bottom line).

The Buddha described it thus:

Insight into the Four Noble Truths we call “awakening”. This awakening allows us to attain the unattained supreme security from bondage.

Ok, enough of Eastern mysticism already. (BTW There’s a similar Western tradition, Transcendentalism, exemplified by Emerson, Thoreau, et al.).

How does this all relate to “the enlightened organisation”?

Self Awareness

If a person lacks awareness of themselves, of their own thinking, of their way of being in the world, then:

“The more asleep we are, the more out of touch we are with what we are doing, the more unaware we are likely to be of consequences, and the more unaware we will be regarding how what we are doing is affecting us and others – so the fewer opportunities we will have to recognize how often we create our own problems…”

~ Milton Dawes

Or from the Mahout and the Elephant perspective: the reflective, self-aware part of our brain governs our ability to overcome the strong psychological hurdles to our understanding ourselves – and why we do things.

In the context of the collective organisational psyche, I suggest that self-awareness (the organisation’s collective awareness of and sense of self) poses the same kinds of challenges and offers the same kinds of benefits if achieved – but at the organisational level.

By What Method

If the goal is a healthy, self-aware organisation, then how can we set about making this happen?

“A goal without a method is nonsense.”

~ W.E. Deming

Personally, I’d suggest taking a look at how individuals go about transforming their outlook and self-awareness. Effective techniques I myself have used include:

Meditation
Zen and zazen
Coaching
Therapy (i.e. help from experienced helpers)
Dialogue on the subject (i.e. with others)
Reading and study (including much study of Koans and the ineffable Tao)

For me, the organisations I see are much like those individuals trapped in a cycle of self-ignorance – unwitting prisoners of their own psyche.

In Conclusion

A thunderclap under the clear blue sky
All beings on earth open their eyes
Everything under heaven bows together
Mount Sumeru leaps up and dances.

~ Wumen

– Bob

Make Bad Hires!

July 11, 2012

Agile, Familiar, Lemons, Organisational effectiveness, Psychology, Rightshifting

11 Comments

Make Bad Hires!

Conventional wisdom, oft repeated on the intarwebs, cautions us to take great care when hiring people. Some folks go to the trouble of quantifying the costs of just one bad hire. But what about the costs of such caution? Here’s a few (sincere) arguments in favour of making bad hires:

However much of a misfit someone may seem at the outset, most people have the ability to learn, grow and develop. Recognising this can send a warm, reassuring and respectful message to everyone in the organisation – including the new hire.
Sticking with a new hire – even when recognising that the hire was “questionable” – can earn much loyalty and commitment from the person in question.
Finding bad hires is a lot quicker and a lot simpler than finding good hires.
Who’s to say that someone that looks like a bad hire will in fact turn out to be such? Kahneman cautions against the cognitive biases that makes us think we can predict people’s performance in advance. (This also reminds me of the Zen story “Farmer’s Luck”).
If we accept making bad hires as policy, our organisation can gear up for it and streamline the procedures for taking people on and letting people go. Much like the agile policy of “deliver early, deliver often, get feedback.” (See also: Zappos). The increased frequency can help us learn faster.
The stigma associated with making ‘bad hires’ decreases or disappears, reducing the delays inherent in people (well, managers, really) avoiding taking “risky” decisions.
People other than managers can be “entrusted” with making hiring decisions.
If you subscribe to the idea of “Deming’s 95%” – that 95% or the performance of any employee is down to the system (the way the work works), not to their own innate skills, experience or talent, then any gap between “good” and “bad” hires will be minimal (5% of overall performance) in any case.
Seemingly “bad hires” will bring diverse perspectives into the organisation, perhaps much more so than “good hires” might.

Note: I would advise retaining one “good hiring” filter: the “No assholes” rule (including filtering-out of folks with sociopathic and/or psychopathic tendencies).

Can you think of any more good reasons for making bad hires?

– Bob

Sardines

June 11, 2012

Agile, Familiar, Organisational effectiveness, Psychology, Rightshifting, Software development

2 Comments

Sardines

It’s not often that my blog posts contain direct advice, preferring as I do the Socratic approach and the Veiled Magic of Questions.

But I HAVE done (and learned) some stuff over the years, and where this stuff is relatively context-free, I’m not averse to sharing.

This is also another in the intermittent series of posts highlighting observable differences between different mindsets – this time it’s office space.

The Rats’ Maze

In many businesses, much effort goes into making the workplace as well-suited as possible to the kind of work taking place. Think: factory floors, warehouses, artists’ studios, automobile workshops – even my local car wash has evolved a pretty darned effective layout for itself over the years.

In the classic, “Peopleware” by DeMarco and Lister – first published more than twenty years ago – the authors explain the significant impact that the physical environment can (and does) have on the productivity and effectiveness – not to mention engagement and motivation – of folks working in knowledge-work businesses.

I have yet to see (outside of Familiar) any organisation that even realises the scope for productivity that a suitable physical environment can offer, let alone take the trouble to find out what works (and what doesn’t) and organise their physical spaces accordingly.

At Familiar, we had around 1600 square feet of self-contained space (plus on-demand access to e.g. meeting rooms, cafeteria, etc). This self-contained space felt “full” with around eight people working in it. So, for us, our optimal density was around 200 square feet per person. This is way more that most every other work space I have ever seen. Recently I was in an office where each person had something like fifty square feet, and that’s including desk space, walkways, seating areas, etc.. Truly this was a daily game of “Sardines”.

Aside: Research has shown the deleterious effects on health, task performance and social behaviours caused by overcrowding.

The Analytic View of Knowledge Work

In most (i.e. Analytic-minded) organisations, folks simply assume that knowledge work is just some (slightly weird) variant of the office work we have known and loved(?) for nigh on a hundred years. Serried ranks of desks, sometimes in cube farms, or more likely these days, open-plan.

The Synergistic View of Knowledge Work

In Synergistic-minded organisations, folks recognise the fundamental differences between repetitive, relatively mindless office work, and the demands of effective knowledge work. These folks arrange their workspaces to better suit the style and nature of the work they’re doing day-in and day-out. Not only is sufficient space allocated, but the nature of the space (in fact, different kinds of space) is carefully tailored to the needs of the work. In general, these organisations perceive that knowledge work is much more like art, design, and learning than it is like office work.

In his recent video about NYU’s ITP projects “What I Learned About Creativity by Watching Creatives”, Clay Shirky describes the ITP workplace, and how both faculty and students regard the physical environment itself as as much a raw material as the items, art materials, computers, etc. in the space.

– Bob

The Familiar Credo

April 5, 2012

Agile, Ethics, Familiar, Leadership, Organisational effectiveness

7 Comments

The Familiar Credo

When starting Familiar, ten of us came together for a day to discuss the possibility of starting a company, explore and exchange our personal values, and take a look at our enthusiasm for working together on something radical. This is what we came up with:

Our Credo

We believe…

On People

People are capable of amazing things. With a just little support and encouragement, people can achieve just about anything. No limits.

On Purpose

We exist as a community solely to help as many people as possible come to better understand themselves and what’s important to themselves as individuals; and to help each of them (us) make those important things happen.
We must subordinate everything else, even our very existence, to this Purpose.
To continue to fulfil our Purpose we must meet the basic needs of the group: food, money, shelter, peer respect, etc. (c.f. Maslow’s hierarchy of needs).
Just as creatures need air to live but do not live for air, we regard these basics as necessary prerequisites to continue living, but in no way the purpose of life.

On Success

We must measure our success in terms of the degree to which we meet our Purpose.
We can only gauge our success when we agree what it is we’re trying to achieve.
Success, particularly in the Information Age, depends utterly on having the full commitment of well-informed people who really want to make a difference.
Commercial success counts for nothing if we lose sight of our deeper Purpose.
We must constantly guard against gauging our success in terms familiar to other businesses (such as growth, profitability, financial wealth, fame, etc.).
Our emphasis on our Purpose will bring far more material success (as an inevitable by-product) than would ever be possible if we tried to make material success the end in itself.

On Sustainability

We can sustain our ideas, ideals, values, understandings, improvements and the like only by identifying or inventing suitable mechanisms and implementing them as integral elements of our enterprise.

On Work

Work can be the most fulfilling, exciting and absorbing activity known to man.
We oppose the notion that work has to be mundane – Death to Greyness!
Work exists both to provide people with an environment to find out more about themselves and what motivates them as individuals, and as a valuable forum for social interaction and exchange.
People must demonstrate their suitability for particular assignments – no one has an automatic right to meaningful work; it’s not part of the contract, folks!
People should regard working through Falling Blossoms as a form of social contract. So long as and to the extent that it suits all parties, it may continue – when it ceases to suit any party it need not continue (and no hard feelings!).
Combining all the various facets of life often seen as separate and distinct, such as work, play, social, domestic, fun, earning a living, etc. are all but different facets of the holistic entity that is Life.

On Trust

To allow personal growth and learning, and as a matter of simple respect, we have no alternative but to trust intelligent people to make their own choices.
People cannot reasonably demand or expect trust, they have to earn it.

On Respect

People must expect to be treated no better and no worse than they themselves would treat others.
People cannot reasonably demand or expect respect, they have to earn it.

On BHAGs

Our operational objectives (Big Hairy Audacious Goals) must always underpin and strengthen our Purpose, rather than undermine or sideline it.

On Commitment

Having someone take responsibility for resolving an issue requires them to have gained a certain awareness of the need to resolve that issue.
Having someone’s commitment to resolving an issue always requires them to have personally and intimately accepted responsibility for the issue.
Commitment therefore comes from an informed view of what needs doing, along with a basic necessary willingness to pitch-in and make a difference.
Our job is therefore to help folks become aware of what’s needed, and then help them become aware of ways of meeting those needs.

On Process

Intelligent, committed, experienced people still perform better, accomplish more, and have more fun, when supported by established ways of doing things (accepted local best practice).

On Competition

Even if we’re not constantly getting better at meeting our Purpose (and all the things that go to help make that happen), we can be certain our ‘competitors’ are.
In line with our view of Familiar as primarily a ‘community of practice’, we do not compete so much with other businesses, but rather other forms of community experience.
If we fail to compete on these terms, we cannot expect to retain people’s interest, involvement and commitment (at least, none who share our particular Purpose).

On Growth of the Enterprise

Growth for its own sake has little merit.
We will look to grow when and only when that growth allows us to move closer to meeting our Purpose, or to bring our Purpose to a wider community.

– Bob

Agile – Circa 1997

March 9, 2012

Agile, Familiar, Software development

Agile – Circa 1997

The Story of INControl

This is the (short) story of an Agile project delivered by Familiar Limited, circa 1997.

Note: There’s a document on my website that describes the approach we used to deliver our projects at that time, then called “Jerid” and subsequently evolved into “Javelin”. Of course, in 1997 the term “Agile software development” had not yet been invented.

“One of the most successful extranet application development projects in CWC history” – Project Sponsor

INControl was CWC’s major extranet application, which enabled all its corporate clients to manage their telephone call routing through the CWC Intelligent Network via a plain old web browser. This replaced their previous service which had involved long and error-prone telephone conversations, plus exchanges of faxes, between customers and CWC’s specialist call centre staff.

The INControl project had spent a long, long time in the Fuzzy Front End. The client – Cable & Wireless Communications – agonised over both the idea and the proposed technologies (WebLogic, Java, J2EE, Swing, etc.). Sun Microsystems had sponsored a number of technology demonstrators in order to close the deal and sell the necessary tin and string.

Finally the client gave the go-ahead to commit development engineering resources to the project, so we called in the folks we had already lined up to do the engineering, architecting, designing, testing and sys admin-ing, and launched the first two-week time-box – or “cycle”, as we then called it.

We already had some information on the basic features of the project, and the client’s particular priorities. Internally selling the idea across CWC was important to the project sponsor, so we focussed the first cycle on producing a working model of the GUI, selecting a few key event types to implement first. We also took the opportunity to make a start on prioritising user stories and elaborating the first (highest-priority) ones, and scheduled the first of the monthly Risk Workshops.

Being the first cycle of the project we also knew, even before the Risk Workshop, that deliverables of the cycle would include some of the basic ‘contextual’ information – a name for the project, a Statement of Purpose, a Project Charter, a Case For Action and a Vision.

Each cycle, in what turned out to be a thirteen-cycle (i.e. 26-week) engagement, followed the same iterative Plan-Do-Check-Act pattern: Cycle planning on the morning of the first Monday, working according to the plan for the next ten days, and a cycle review (internal process retrospective) on the second Friday.

Each Monday morning the team would get together and plan out the deliverables, and interim work products, for the upcoming two weeks. The project sponsor provided input in terms of which user stories should take priority, and what he and the other CWC stakeholders wanted to see during the cycle, and at the end of the cycle.

The evolving Risk Parade (the main deliverable from each Risk Workshop) highlighted to us those areas where we should take special care, or schedule mitigating work items, and the results of the previous cycle’s Cycle Review (a.k.a. retrospective) reminded us of where we needed to act to improve the development process itself.

The core of each cycle planning session involved the team members identifying what work items were going to be needed to:

deliver the chosen stories
manage the risks
improve the development process

and the team members also estimated how long they each would allocate to working on each of the consequent work items.

Delivery Rhythm

The results of the first cycle were very well received by both the project sponsor and the various stakeholder constituencies within CWC, so much so in fact that a number of people within the client’s organisation volunteered to work closely with the development engineering team on elaborating the requirements (iteratively) for the project as we moved forward. We would have promoted this first ‘release’ into production, but were waiting for the delivery and commissioning of the necessary server hardware and infrastructure (a joint Sun-CWC responsibility and outside the remit of the development engineering team).

In cycle 4 we booked the Madjeski Stadium Directors Box to present the first fully-functioning end-to-end release of the application to an audience of all the major stakeholders. The day was a great success, with senior CWC management pushing for a live system as soon as possible. Again, we could have released the system into production there and then, had the necessary infrastructure and client release / acceptance test procedures permitted.

Further cycles added further event types and lesser routing options, along with documentation and some minor performance tweaks.

Improving Along the Way

Some of the process improvements we introduced through the course of the project included:

a mini feature-schedule to help coordinate the work of the various engineers within a given cycle
a daily stand-up to help coordination further
work items being specified by their down-stream consumers (as opposed to how we started out, with the producer of a work item outlining the specification)
a collection of patterns to encapsulate and share common working practises – such as “FiveLinesOfCode”, “ConstantStateOfShip”, “CommonFrameOfReference”, “QualityGates” and so on.

Into Production – Better Late Than Never

Finally, with the commissioning of the production infrastructure in sight at last, the focus of our final couple of cycles shifted to getting ready to deploy the product into live production.

Some three months after the end of the first thirteen cycles, the client’s customers had received the new service so well that CWC commissioned another couple of cycles to add some more features into the product, and we were able to assess the quality of the system in production. The system had run live and uninterrupted 18×7 for over three months, with only three minor defects reported in that time.

As CWC themselves said of this feat:

“this was one of the most successful extranet application development projects we have ever seen”.

Ironically, one lesson we learned was that it could have been even more successful had we had responsibility for the commissioning of the production infrastructure too.

C’est la vie!

– Bob

Project Charters and Social Contracts

March 9, 2012

Dialogue, Familiar, Software development

Project Charters and Social Contracts

On just about every project I’ve been involved with over the past twenty years, I have promoted the idea of a “Project Charter” (or better-yet, a “Social Contract” for the project).

I have reproduced the basic template for a vanilla Charter, below.

Aside: These days, I myself would avoid working within the structure of a “project” wherever and whenever possible, the “project” concept being a zero-sum game, at best. But I recognise many folks have not reached that happy place, as yet. Accordingly I’m open to the accusation of helping folks “do the wrong thing righter” with this post. Folks still mired in the project swamp may find it useful, nevertheless.

The Project Charter

The strength of having a charter (a.k.a. Article of Understanding) lies in helping stakeholders – dev team members, sponsors, customers and others – understand the social context and mutual responsibilities involved in working together. When it works well, everyone is more or less “on the same page” with regard to expectations, etc.

Sample

Article of Understanding

In line with meeting the needs of the project’s stakeholders as quickly as possible, the project team wishes to keep the amount of detail in the requirements for this project to a prudent minimum. The following Article of Understanding attempts to set a certain level of expectation amongst all concerned regarding the likely consequences of that wish:

“Project [Project name – TBD] will try to capture every important requirement in its functional- and non-functional- requirements models, but gaps and ambiguities will inevitably occur. To resolve these the project team will need to invent details on their own. On a typical project, hundreds of such gaps can exist, which makes it impractical for stakeholders and the project team to confer about each one. The project team typically resolve the vast majority of these gaps without the stakeholders ever becoming aware that an ambiguity existed.

In some cases, a stakeholder will have a strong feeling about how the project team has resolved a particular ambiguity and will require a different resolution. This happens to a greater or lesser extent on virtually every project. To the extent that a stakeholder clarifies such ambiguities later in the project to mean something different from the project team’s earlier assumption, there will probably be negative impacts on costs or schedules, or both. The project team will try from the outset to structure the deliverables to minimise these negative impacts, but we all know from long experience the inevitability of this unfortunate feature of development. We will all try to remember this.

The project team undertakes to try to be responsive to the stakeholders’ needs and create solutions that satisfy those evolving needs with minimum disruption to costs and schedules.

The stakeholders undertake to remember that the project team tries its best when interpreting gaps in the requirements.”

The key weakness of a project Charter, is the unilateral or one-sided nature of the document. Typically drawn up by the dev team, a Charter rarely affords the opportunity for buy-in and commitment from all stakeholding parties. In many cases, stakeholders do not see the value in spending time understanding and committing to such a charter. Indeed, quite often some stakeholders will fear the loss of control and increased accountability that such a multi-lateral agreement notionally brings.

A project Contract, on the other hand, demands more work and more understanding from all the signatories, which can take much time and effort to negotiate and discuss. Many organisations are not prepared (sic) to commit the level of effort required to make this happen.

– Bob

Postscript

I do not intend for the reference to “requirements” in the above sample to imply e.g. a Big Design Up Front approach to requirements gathering. If you feel the word may seduce your readers into this assumption, feel free to make more explicit the iterative nature of requirements gathering – assuming that’s how you run your projects, of course.

The Starting of Familiar

August 16, 2010

Agile, Archive, Ex-Amplify.com, Familiar, Organisational effectiveness, Software development

5 Comments

The Starting of Familiar

[From the Archive: Originally posted at Amplify.com Aug 16, 2010]

Introduction

In an attempt to give folks some context to some of my more contentious remarks on e.g. Twitter, I reproduce here the story of how Familiar started out, and some of the things we achieved during my time on deck:

A Customer Quote

“One of the most rational and engaging organisations I have ever seen.”

~ G Shekhar, CTO, InfrasoftTech

Familiar Limited was a company that I started with a colleague upon my leaving Sun Microsystems’ UK Java Center in early 1997. We also had the delight of some ten other interested folks helping us form the company and its ethos from the outset.

Green Park, Longwater Ave, Reading – headquarters location for Familiar Ltd circa 1999

Familiar was a software house specialising in delivering advanced bespoke Java web applications, that also shared its expertise on how best to manage the business of software development – in the form of consulting services – with other software development organisations. In fact, Familiar was the first 100% Agile software house in Europe.

Founded on Principles

When we set up Familiar, we had between us seen literally hundreds of development organisations, and we were convinced that it was sound business sense to found Familiar on the following core principles:

We would run the company for the mutual benefit of all the people coming into contact with it.
We would institute “human systems” that treated people – employees, customers and suppliers alike – like competent, rational, trustworthy adults.
We would do everything possible to build a community for the long term. Success depends utterly on having the full commitment of well-informed people who really want to make a difference.
Work can be the most fulfilling, exciting and absorbing activity known to Man.
No matter how motivated, intelligent and competent people may be, they still benefit immensely from an agreed, common approach to tackling work.
Commonly-held “management” assumptions and traditions (for example: jobs, appraisals, standard employment terms and conditions, management authority) are sometimes counter-productive and deleterious to a healthy business.
All our business dealings would seek win-win-win-win outcomes (for us, our suppliers, our clients, and their customers)

Guided by Practices

Given the above principles, this led us to institute a number of key mechanisms to advance these principles:

People were encouraged to participate in the community on whatever basis they felt most appropriate for their circumstances (for example, as employee, contractor, sub-contractor, apprentice, consultant, etc.).
Equity was available to anyone that participated in the community.
People were invited to each choose their own personal terms and conditions, including rates / salaries, working locations, hours, tools, and so on.
People were continually encouraged to synthesise and evolve their joint working practices (with a baseline set of working practices to make this as painless as possible).
People were invited to choose their own assignments, tasks and deliverables.
Narrow specialisms, such as sales people, managers, and so on were conspicuous by their absence. Everyone was encouraged and supported to become so-called “Generalising specialists”.

And the product of these principles and mechanisms? A hugely engaged and participatory workforce, and a really humane community, which produced a number of essentially defect-free software products, and pushed the envelope in terms of what was possible from a software development organisation.

As an example, here’s just one quote from a continually-surprised customer:

“With INControl, Familiar gave us one of the most successful extranet application projects in CWC history.”

~ Cable & Wireless Communications

– Bob

Twenty Years a Scrum Master

Looking Back

From Processes To People

Share the joy :)

Let The Team Make The Difference

Support

Protection

Why Not The Scrum Master

Why Not the Product Owner

Summary

Share the joy :)

Needs And Fulfilment

Further Reading

Share the joy :)

Roots

Not Just Customer Work

Unimaginable

Quantification

Fit Feedback

Integrated, Intentional

Dialogue

Afterword

Share the joy :)

Nonviolent Employment

Voluntary Assignment

Status

Compensation

Kit

Reflections

Further Reading

Share the joy :)

Zen and the Art of Organisational Enlightenment

The Enlightened Organisation

Self Awareness

By What Method

In Conclusion

Further Reading

Share the joy :)

Make Bad Hires!

Further Reading

Share the joy :)

Sardines

The Rats’ Maze

The Analytic View of Knowledge Work

The Synergistic View of Knowledge Work

Further Reading

Share the joy :)

The Familiar Credo

Our Credo

We believe…

On People

On Purpose

On Success

On Sustainability

On Work

On Trust

On Respect

On BHAGs

On Commitment

On Process

On Competition

On Growth of the Enterprise

Share the joy :)

Agile – Circa 1997

The Story of INControl

Delivery Rhythm

Improving Along the Way

Into Production – Better Late Than Never

Share the joy :)

Project Charters and Social Contracts

The Project Charter

Sample

Article of Understanding

Postscript

Share the joy :)

The Starting of Familiar

Introduction

A Customer Quote

Founded on Principles

Guided by Practices