Artefact Driven Delivery

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

Management Monstrosities

Michele Sollecito (@sollecitom) kindly responded to a recent tweet of mine with the following question: 

“Why do so many well intentioned founders and companies end up creating management monstrosities?”

The “management monstrosities” referred-to are the (dysfunctional, ineffective) tech organisations we find just about everywhere these days. My work on #Rightshifting illustrates just how ineffective is the average tech company, compared with how effective they could be (and Rightshifted outliers are known to be).

But Michele’s question is: “Why?”

Over twenty years and more, I’ve seen dozens of organisations up close and personal.  In none of these organisations have the folks in charge appreciated the difference between collaborative knowledge work (Cf. Drucker) and other categories of work. We can call this a Category Error.

Category Error

Collaborative knowledge work is NOT like:

  • Factory Work
  • Manufacturing
  • Office work
  • Service work (e.g. Call centres, Help desks, etc.)
  • Individual knowledge work

Collaborative knowledge work is in a distinct category all its own, and demands a fundamentally different approach to the way the work works, if we’re to see effective working.

Attempting to manage collaborative knowledge work by means common to other categories of work will inevitably lead to ineffectiveness, and all the monstrous consequences that follow from that.

Assumptions and Beliefs

Put another way, organisations import or retread the assumptions and beliefs of the category of work they believe applies to software development. As the category they assign is (almost) never “collaborative knowledge work”, the prevailing assumptions and beliefs are never aligned to effective working.

You may now be asking “Why is the category they assign (almost) never ‘collaborative knowledge work’?”. I’ll leave that question for another post (if there’s any demand for such a post).

– Bob

Grendels

I have of late been reading (well, listening-to via Audible) many of the science fiction classics from yesteryear, by authors I missed out on in my youth (in those days mainly reading Van Vogt, Moorcock, Herbert, Harrison and Heinlein).

The most recent of these books is The Legacy of Heorot by Larry Niven et al.

The book has been described as “reworking the Beowulf legend in science fiction”. Niven amplifies Beowulf’s antagonist, Grendel, into a whole species of pseudo-reptilian super-monsters. Without revealing the whole plot, suffice to say that these creatures are portrayed as solitary, voracious, cannibalistic, and murderously territorial.

Whilst reading (listening), I’ve been struck by the parallels between these “Grendels” and prominent figures in the software community (individual consultants, opinioneers, etc.):

Solitary

I see many such figures (including but not limited to folks in the Agile space) ploughing their own furrows, ignoring others of a similar ilk, minimising productive interactions and community.

Voracious

Niven’s grendels are forever eating, and looking to eat. Eating is their core driver. The folks I have in mind seem likewise voracious in their hunt for revenues and clients (prey).

Cannibalistic

I see many such figures taking the ideas of others, retreading them, and selling them on as original and even proprietary. Analagous to intellectual cannibalism.

Fiercely Territorial

The grendels in the book each assiduously guard their own stretch of water (being basically amphibian), murderouly opposing any intrusion into their territory, with the utmost prejudice. I see parallels with (some, most?) of the aforementioned members of the software thought-leaders and opinion-makers “community”.

Upshot

In the book, the human colonists eventually triumph over the grendels, through a combination of technology, self-sacrifice and strategic thinking. “They’re just animals” the colonists remark, by way of explaining their victory.

I’ve long sought to reach out and connect with our grendels, in an attempt to further the collective knowledge and impact of the software community at large. To little or no avail. Maybe our grendels’ fate is predicted by the fate of the grendels in the book – irrelevance and extinction.

– Bob

Six FAQs Explored

Recently, Adelbert Groebbens (@agroebbe) made an observation on Twitter to the effect that getting other people to understand what we’d like them to understand is a fool’s errand. He illuminated the point with a reference to my Six FAQs post. Al Shalloway expressed his disagreement with many of the points therein. This post explores the subject, via a dialogue between Al and myself, conducted over email recently, and in the context of the original Six FAQs post.

Note: the # numbers relate to the numbered points in Al’s original tweets.

The Dialogue

@alshalloway: (Opening): Thanks. but i disagree with most of the points there [in the original Six FAQs post].

@FlowchainSensei (response): Thanks Al for providing your take on this post. Maybe you’d be willing to enter into a mutual exploration of the subject of e.g. motivation? I guess your comments (provided via Twitter and copied, below) reflect your experiences when working with developers and teams? Likewise, my original post [link] reflects my experiences in similar environments (with a little borrowing from Bill Deming, Russell Ackoff, Marshall Rosenberg and Carl Rogers, to name but a few). It comes as no surprise to me that our experiences differ somewhat, and that our respective conclusions differ likewise. That’s not to say I’m right, or you’re right – we could both be right. Or wrong. Or somewhere in between.

The Annotated Original Post 

Questions I’m frequently asked about software and product development organisations.

Q1: How can we motivate our workers?

A1: You can’t. [see: Al’s #1 follow-up comment, below] Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

@alshalloway: #1:  Pretty much agree but don’t like tone. Most workers will respond to not being de-motivated. the “maybe, just maybe” is what i don’t like.

@alshalloway: #1: (Follow-up): you can’t motivate, you can only stop demotivating. In other words, you can’t motivate them, but you can do other things that are useful. 

@FlowchainSensei: #1: I guess your assessment of the “tone” here differs from mine. How often do e.g. managers or others responsible for the workplace “environment”, when attempting to cultivate a climate conducive to intrinsic motivation, succeed in those attempts? My experiences suggest “occasionally”. I guess you concur on the main point here: that intrinsic motivation can only come from the folks themselves (the emergence of same being aided by efforts to reduce or remove demotivators – shades of Drucker, Herzberg)? 

@alshalloway: Agreed that most managers don’t do this [attempt to cultivate a climate conducive to intrinsic motivation]. But much of that is because it’s never been explained to them [as] a new role they can fill.

@FlowchainSensei: Explaining presupposes they’re motivated to listen to explanations. I’m minded of the following quotations:

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker 

“If you want people to do a good job, give them a good job to do.”

~ Frederick Herzberg

Q2: How can we change the organisation’s culture?

A2: You can’t. [see: Al’s #2 follow-up comment, below] Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that. 

@alshalloway: #2: you can’t change an org’s culture directly, but you can change it indirectly. See my post “Improving Your Company’s Culture”. 

@alshalloway: #2: (Follow-up): you can’t change culture directly, but there are ways to do it indirectly. You can’t change it directly since culture is a result of many things in your company.

@FlowchainSensei: #2: I totally agree that “culture” can be changed indirectly (but not directly). To elaborate on this question, I propose that changing culture through examining assumptions and beliefs (more specifically, supporting folks who are interested in getting together to examine their own *collective* assumptions and beliefs) offers a way forward. For which see: Organisational Psychotherapy.

@allshalloway: I don’t think you need to change minds directly. Rather change how they [people] work.  It’s consistent with the idea “it’s easier to work your way into a new way of thinking than to think you’re way into a new way of working.”

@FlowchainSensei: I’d clarify that as “I don’t think you can change minds directly. Rather enable and encourage change to how the people doing the work choose to work. (See also:The People vs System Conundrum).

Q3: How can we change the mindset of managers?

A3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

@alshalloway: #3: I’ve changed mindsets by guiding people through their beliefs and showing them better ones. I’ve had special training in this.

@alshalloway: #3: (Follow-up): changing mindset is only possible when people are open to it.

@FlowchainSensei: #3: I agree with your follow-up statement. It’s been my experience that folks have difficulties when left on their own in this regard, even when open to the idea of “changing mindsets”. I have found that help, or support, or (your term) guidance can be valuable here. Hence, btw, Organisational Psychotherapy (support-for-changing-assumptions-and-beliefs-as-a-service).

@AlShalloway: Changing mindsets is difficult, and even when possible, takes a long time. It is important to show managers new opportunities and new ways they can interact with the people they work with.

@FlowchainSensei: When and if these managers are motivated to see and learn – see Q1. 

Q4: How can we get teams to take responsibility?

A4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

@alshalloway: #4. Pretty much agree. But again, it’s the skeptic’s tone i object to. Many are ready to take responsibility, but like motivation, we’re de-motivating them to do so.  You could argue we agree – but it’s not clear.

@alshalloway: #4: (Follow-up): You can’t get people to take responsibility, but for those that are willing, you can remove the barriers to it.

@FlowchainSensei: #4: I guess our experiences differ here. I wonder how much that difference has to do with geographies and national cultures (I.e. UK vs USA)? In my experience (UK, and Europe too), many are not ready/willing to take responsibility, often through long experience of being punished or sanctioned for attempting to do so, or even for simply suggesting it. Is “Learned helpless” more prevalent in the UK, I wonder? I agree wholeheartedly with your follow-up statement.

Q5: How can we get managers to trust their teams?

A5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

@alshalloway: #5 Building trust is not easy but it’s possible. Most of the way Agile does it doesn’t work. You can’t presuppose it [trust] or blame people for not having it. Lean management can be helpful here.

@alshalloway: #5: (Followup): You have to build trust, and not everyone is willing to have this built.

@FlowchainSensei: #5: Agreed, especially with your observation that there are some folks who are, on the face of it, unwilling to participate in trust-building. I would love to hear more about the aspects of Lean management which you have in mind. For myself, I have found the Antimatter Principle and Nonviolent Communication both useful in trust-building efforts.

@alshalloway: Trust grows over time as people work together. An expectation that managers will all of a sudden trust their teams is doomed for disappointment. But we can teach managers how to work with people to build trust. Why am I not trusting their [the manager’s people] judgement? What is it that people need to know?

@FlowchainSensei: Agreed. Again, allowing for managers being willing (or unwilling) to be “taught”.

Q6: How can we develop people’s competencies?

A6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

@alshalloway: #6. Your title is inconsistent with what you say. You admit to being able to change competency if they are willing to learn. So it’s not possible.

@alshalloway: #6: (Follow-up): You can only improve people’s competencies when they are already willing to learn. 

@FlowchainSensei: #6: I’m unsure as to the meaning of your original comment. If your follow-up comment serves as a clarification, then I agree entirely. 

In a nutshell, the direct answer to all the above questions is: you can’t. But you can do at least one thing to make progress on all these questions: consider the Antimatter Principle.

Are you willing to be that radical? For that is what it boils down to. 

“We can’t solve problems by using the same kind of thinking we used when we created them.”

~ Albert Einstein

– Bob

Closing

@alshalloway: (Closing) I object mostly to the skeptic curmudgeonly style of the posts – the absolutism of it.  

@FlowchainSensei: (Closing): I guess I’m well-known and loved for my skeptical, curmudgeonly style. :}

Cost of Focus Revisited

[Recent conversations suggest that my post on Cost of Focus failed to explain the idea clearly enough for readers to grasp easily or quickly. As, for me at least, it’s a simple idea, I thought I’d summarise it in brief with a new post (this one).]

Cost of Focus

Let’s start with a definition in a nutshell:

Cost of Focus is the cost incurred when we fail to include key stakeholders* in our deliberations**.

* I generally refer to these folks, collectively, as The Folks That Matter™.
** By deliberations, I have in mind what old-school folks call “requirements capture” or “requirements analysis”, and what I, nowadays, refer to as “needs investigation”.

Put another way:

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs.

Note: I could have chosen the name “Cost of Flawed Focus” (the cost of focussing on less relevant stakeholders and less relevant requirements), but this seemed a little less snappy than “Cost of Focus”.

Typically, the costs in question accrue from rejection of part or all of the delivered project / system / product / software application by one or more key parties (such as users) whose needs have not been adequately addressed  – and these costs can be massive. In any number of cases, whole systems have had to be abandoned because one or more key stakeholder groups have refused to use the new system. And even when not totally abandoned, oftentimes major costs have accrued from the delays and extra work required to remediate the original errors of focus. (See also Cost of Focus’ kissing cousin – Cost of Delay).

The Folks That Matter™

[The following excerpt first appeared in my blog post The Folks That Matter™. I repeat it here for the convenience of the reader:]

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of delaying a given feature by prioritising another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above, i.e. the question of Cost of Focus.

By definition, we are failing to meet some folks’ needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong (prioritise less valuable features), and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary, black-and-white impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding to whose needs to attend, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Cost of Focus ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
Cost of Delay ~ Wikipedia entry

Simples

I can’t pretend I’m not frustrated with the software community for its limited engagement with the question of organisational performance. Given that organisational performance is inextricably linked with the quality of life of folks working in software and IT departments everywhere, and with the health of society more broadly too. This post explores the (simple) connection between organisational performance and Organisational Psychotherapy.

Organisational Performance

I’m using the term “performance” here more broadly than might be regarded as common (but consistent with e.g. the Wikipedia entry).

Aside: In the vocabulary of the Antimatter Principle, we define organisational performance (somewhat opaquely, to be sure) as:

“The relative impact on all the needs of all The Folks That Matter™, of meeting all the needs of all The Folks That Matter™”

For the purposes of this post, I’m using the term to cover:

  • Financial performance (profits, revenues, return on assets, return on investment, debt ratio, etc.)
  • Shareholder value (total shareholder return, economic value added, share price, etc.)
  • Sales and market share
  • Customer and supplier (including employee and management) satisfaction
  • Corporate Social Responsibility
  • The well-being of the Core Group (probably the most crucial, yet least openly discussed)

The Proposition

Organisational Psychotherapy is a very simple proposition, really. Let’s lay it out and see who agrees or disagrees with the line of reasoning at any point:

  1. The assumptions and beliefs held in common (i.e. collectively) within an organisation drive every aspect of the behaviours of that organisation.
  2. The behaviours of an organisation, in toto, govern the performance of that organisation.
  3. To increase the performance of an organisation in any or all of the dimensions of organisational performance requires some changes in its behaviour.*
  4. Any and all changes in behaviour come from changes in the collective assumptions and beliefs held by the organisation.
  5. Organisations rarely have the competence (skills) to examine, change their collective assumptions and beliefs
  6. Outside intervention (i.e. the Organisational Psychotherapist) can help kick-start the organisation in its internal dialogue, introspection and acquisition of the skills necessary to examine and change its collective assumptions and beliefs.

*Note: Excluding considerations of external factors beyond the control of the organisation.

Put another way, Organisational Psychotherapy reduces the risks, costs and timescales of an organisation changing its collective assumptions and beliefs, and thereby reduces the risks, costs and timescales of improving the performance of the organisation.

Diagrammed

Here’s a diagram illustrating the above line of reasoning:

Graphic representation of the line of reasoning

 

Further Reading

Who Really Matters: The Core Group Theory of Power, Privilege, and Success ~ Art Kleiner
The Five Capitals – a framework for sustainability ~ Forum For the Future article
Productivity ~ Think Different blog post

Structurally Broken

“When you have a system in which structural failure is embedded, nothing short of structural change will significantly improve it.”

~ George Monbiot

He was talking about the UK’s transport infrastructure, but I’ve long believed the world’s “Software Industry” system is structurally broken, too. Even the very name “software industry” signals dysfunction. (Of course, this observation applies to many industries, not just software).

Software

“The great Harvard marketing professor Theodore Levitt used to tell his students, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” Every marketer we know agrees with Levitt’s insight. Yet these same people segment their markets by type of drill and by price point; they measure market share of drills, not holes; and they benchmark the features and functions of their drill, not their hole, against those of rivals.”

~ Clayton M. Christensen

We’ve heard time and again that people (customers, the general public) don’t want software, they want the utility that software can bring. Yet we call our industry the software industry, condemning us to build and deliver stuff that our customers don’t want. Granted, “that cat’s outa da bag” as Lt Columbo would say. Renaming the whole industry as something like “the pain solving industry” or the “attending to folks’ needs” industry ain’t going to happen any time soon, if ever.

Industry

Why do we describe the <name to be argued over> field as an “industry” anyways? Images of factories and satanic mills and slave plantations and the Apple “1984” advertisement come to mind. “Art” is rarely labelled as an industry, for example.

Structural Change

So what kind of structural change or changes might bring about some improvements?

#NoSoftware points the way. Analogous to the Paris 15-minute city idea (by implication, #NoCars).

And until customers stop asking for drills (software) and begin explicitly asking for holes (their needs met) we’ll likely not see much change.

What kind of structural changes can you envisage, suggest?

– Bob

Further Reading

Beyond Command And Control – A Book Review ~ Think Different blog post

 

Some Familiar Experiences

[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

Five Reasons Why Agile Coaching is Bullshit

By popular demand, here’s a short post expanding on a recent pithy tweet of mine:

“Agile coaching” is bullshit – for various reasons.”

1. Agile is a Means to an End, not the End In Itself

“Software development coach” might be a (slightly) less bullshit title. For many organisations, and people, quick and cheap software development is the goal. Setting aside why “software is the goal” in itself is a bullshit concept (see: #NoSoftware), “Agile coaching” implicitly excludes other approaches and other means to improving software development. Other approaches which have proven more effective than Agile. And other approaches which the players (coachees) might reasonably seek to explore or experiment with, yet find themselves unable so to do because those other approaches are deemed beyond the pale. Why not start down a road towards the goal that matters (better products, higher margins, more profits, to make money now and in the future or even – and most realistically – maximising the bosses’ well being), instead of driving into the Agile cul-de-sac?

2. Individual Technical Focus

As coaches, (in theory) Agile coaches follow the interests of the folks they’re coaching. In most coaching contexts (i.e. outside of the software domain) coaches have no agenda of their own beyond assisting their players (coachees) grow and develop their skills and abilities – as those players themselves see fit. In practice, technical folks generally seek to develop their individual technical skills and abilities – which hardly matter in the grander scheme of things, such as from the broader business perspective) – and recoil from any suggestion that other skills and abilities might also be important. Things like interpersonal skills, dialogue skills, business skills, serving the needs of the users and other folks that matter, etc..

3. Agile Coaching is an Imposition

I’ve never seen an Agile coach get hired at the request of the people they’ll be coaching. Nor selected by the folks they’ll be coaching. I hear it happens, but so rarely as to be an extreme anomaly.

4. Coach as Manager

There’s a lot of talk about (middle) managers becoming coaches to their people. In most practical scenarios, Agile coaches are expected by the people that appoint them to become managers of the people they’re coaching. I’d call that regressive. And bullshit.

5. Kaizen vs Kaikaku

In theory (for example, with Scrum), Agile coaching supports the team in reaching out across the organisation to address systemic issues affecting the team’s performance (kaikaku). In practice, for all the above reasons, this almost never happens. The Agile coaches, sensitive to not biting the hands that feed them, avoid raising issues that might disrupt other parts of the organisation, and limit their focus on improvements local to their team (kaizen). Which is entirely understandable, given the coaches’ brief and the dynamic of their position (who’s paying them and keeping them in a job). As Shakespeare wrote :

“To be [remain in a job, helping locally], or not to be [rocking the boat and being vilified and let go]: that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune [refrain from raising thorny organisation-wide issues],
Or to take arms against a sea of troubles [raise those issues and thanklessly suffer the consequences],
And by opposing, end them? [’Tis a consummation devoutly to be wished.]“

– Bob

%d bloggers like this: