Archive

Software development

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

#NoSoftware

I wrote a post some time ago about No Hashtags (hashtags on e.g. Twitter which use the #No… prefix). My tweets occasionally mention various #No… hashtags, including #NoEstimates, #NoTesting and #NoSoftware.

I’m thinking it’s about time I delved just a little into the #NoSoftware hashtag. Like most of my posts on Think Different, this one will be brief. #NoSoftware is a deep subject, upon which I could write a whole book, had I but the inclination (or demand).

To whet your appetite, and illustrate the possibilities of #NoSoftware, we need look no further than the story of Portsmouth City Council housing repairs, where an existing, expensive and inflexible IT system was switched off, replaced with manual controls, and only later some limited software support reintroduced, once the needs of all the Folks That Mattered had been fully understood and catered to.

Payback

Let’s start with the payback of #NoSoftware.

As Steve Jobs wrote:

“The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs

A pretty clear alignment with #NoSoftware (yes, I’m coming to that presently) wouldn’t you say?

Let’s just dissect that statement:

Eliminating lines of code we have to write

We’re not talking about writing denser code – cramming more functionality into fewer lines. Fewer lines of code means we’re done quicker, having spent less time, effort and money on the writing of code. That’s a saving in and of itself.

Never breaks

So the lines of code we don’t write means we don’t have to worry about their quality (no matter whether you use defect prevention or testing as your go-to strategy in that arena). More time, effort and money saved.

Doesn’t need maintenance

By maintenance here, I’m thinking about changes to the code occasioned by the changing needs over time of the Folks That Matter, or changes necessitated by changing technical environments. I’m not dwelling on remediation efforts (bug fixes to production code).

More Payback

But the payback of #NoSoftware doesn’t stop with the above aspects. In the bigger picture, it’s not just about writing fewer lines of code. It’s about eschewing software-based solutions more or less entirely in favour of considering the alternatives. More payback includes:

Happier customers

It’s an old saw that “folks don’t want an 8mm drill, they want an 8mm hole”. Similarly, folks almost universally don’t want software, they’re looking to have their needs met. And software for many of these folks has too many negative impacts to be their preferred option. Software is generally written to save (suppliers) costs, not to improve customers’ satisfaction. Most people hugely prefer to interact with other human beings, rather than a computer controlled by – generally lame and inflexible – software.

Opening the Door to Changing Thinking

Software systems as generally conceived, ordered and delivered institutionalise – or “lock-in” – the existing collective mindset. Once installed and paid for, the “sunk cost” fallacy undermines any possibility of changing the existing set of assumptions and beliefs about how the works works. In the vast majority of cases the software system locks the organisation even more tightly into its existing Command & Control (a.k.a. Analytic Mindset) ways of working.

#NoSoftware – Definition

When I use the #NoSoftware hashtag, I’m inviting folks to think again about what, often, are near-autonomic responses. In this case, the System One (cf Kahneman) response – “fast, instinctive, emotional, stereotypical, unconscious and automatic” – when faced with some needs of some Folks that Matter, to satisfy those needs with a software-based solution.

I guess some folks assume that I’m advocating zero software. A kind of Luddites’ heaven. This is not my position. In using the #NoSoftware hashtag, I’m basically saying

“Under some circumstances, maybe there are other, more effective means to meet folks’ needs than the default assumption/strategy that we have to do so via software”.

“How about we think about, talk about, and consider those various circumstances, and means?”

In this way, the #NoSoftware hashtag is a metaphor for

“Would you be willing to think again, and maybe join the search for more effective, relevant or alternative means of meeting the needs in question?”

Example

Some years past, I was working with a company that offered a software product to the corporate market. The product had been in the market for some years, and it was clear that one of the blockers to market penetration was the complexity of the problem and the challenges corporate customers faced in dealing with that complexity. The company chose to build more and more software into their product to help their customers handle the complexity. No one ever discussed the options of offering a consulting service and/or a managed service, using human expertise, to replace or augment their software product. Consequences were, customers remained challenged, and the company’s revenues suffered.

Blockers

As Upton Sinclair’s Dictum tells us:

“It is difficult to get a man to understand something when his salary depends on his not understanding it.”

~ Upton Sinclair

How much more difficult, then, when it’s the revenues of a whole industry we’re calling into question. If the software industry changed tack and stopped writing software, what then? Financial ruin? World collapse?

There’s a multitude of smart people who currently waste much of their time – and lives – writing and delivering solutions to folks’ needs in the form of software. I suggest that to have this multitude refocus and retrain themselves to consider, and deliver, other forms of solution – solutions with less or no software – would make the world a better place for all the Folks that Matter. And “better”, as far as customers are concerned, would mean increased demand and more revenues for savvy suppliers.

Uptake

Like many of my invitations, I find #NoSoftware has few people willing to consider it as an alternative strategy to the status quo of just getting on with writing (more and more) software. I guess this signifies the general learned helplessness, and lack of engagement, autonomy and mastery, we find in most workplaces and employees today. So be it.

– Bob

Further Reading

Why Doctors Hate Their Computers – Atul Gawande
Forget your people – real leaders act on the system ~ John Seddon
Dangerous Enthusiasms: E-government, Computer Failure and Information Systems Development ~ Robin Gauld, Shaun Goldfinch

Why Reason When Faith is So Much More Comfortable?

I’ve become very bored trying to explain why Agile – even when practised as the Snowbird Gods intended – is a dead-end and why we might choose to bark up a different tree for progress in improving the effectiveness of software development organisations.

Firstly. No one seems at all interested in “improving the effectiveness of software development organisations”. Yes, there does seem to be some interest in being seen to be doing something about improving the effectiveness of software development organisations. Hence SAFe, DAD, LeSS – and Agile itself. None of these approaches do anything about actually improving the effectiveness of software development organisations, of course. But that’s not the point. Improvement *theatre* wins the day in just about every case. Irrespective of practices done “right”, or more often, done “in name only” (Cf AINO).

To actually do anything about improving the effectiveness of software development organisations requires we remove some fundamental system constraints, including:

  • Optimising parts of the organisation in isolation
  • Pursuit of specialism (vs generalists)
  • Control (as in Command & Control)
  • Annual budgeting
  • Extrinsic motivation
  • Ignorance of the special needs/realities of collaborative knowledge work
  • Separation of decision-making from the work
  • Decision-makers’ ignorance of and indifference to customers’ needs
  • Seeing performance as consequent on the efforts of individuals and “talent”
  • Discounting the paramountcy of social interactions and inter-personal relationships

And that ain’t gonna happen.

Second, improving the effectiveness of software development organisations kinda misses the point. In that software development is part of the problem. Making it more effective is just – as Ackoff would say – doing more wrong things righter.

Instead, a focus on meeting folks’ needs, or at least, as a minimum, attending to their needs, would serve our search for effectives rather better. And that generally requires less software, and placing software development last in terms of priority, way before understanding customers’ needs ( (and more generally the needs of the Folks’ That Matter).

Given that the software industry’s revenues are contingent on producing software (see: Upton Sinclair’s Dictum) that ain’t gonna happen, either.

Third, if we regard improving the effectiveness of software development organisations as our aim, and limit our ambitions to that part of the organisation concerned directly with software development (i.e. the IT department or the Product Development department) then, at best, we’ll only ever see a local optimisation. Which as Ackoff tells us, only makes matters (i.e. the effectiveness of the whole organisation) *worse*. To improve organisational effectiveness (not to mention supply chain effectiveness, customers’ effectiveness) requires us to consider the organisation as a system, and focus on the systemic relationships between the parts, rather than on the parts taken separately. And given that systems thinking has failed to gain much traction in over fifty years of trying, THAT ain’t gonna happen either.

I’ll just leave this here:

“If you could reason with Agile people, there would be no Agile people.”

It all looks a bit bleak, doesn’t it? Another method isn’t going to help much, either. Unless it addresses the three points outline above. As a minimum.

That’s why I have been for some years inviting folks to consider Organisational Psychotherapy as a way forward.

But reason, rationality, and a cold hard look at reality and the shortcoming of the status quo ain’t gonna happen. Until organisations see a need for that to happen.

– Bob

Damn Outcomes!

It seems in vogue to extol the praises of “outcomes” when discussing e.g. software and product development. Setting aside the challenges of defining what we might mean by “outcomes” (I dislike getting into rabbit-hole discussions of semantics), there’s one key aspect of this debate that seems to escape folks’ attention. W Edwards Deming nailed it decades ago with his First Theorem:

“Nobody gives a hoot about profits.”

Even so, Deming said little about what folks (managers, in his frame) DO give a hoot about. We can turn to Russell L. Ackoff for an insight into that:

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

As Dr. Ackoff says, a secondary focus on profits is just the cost executives must pay in order to maximize their rewards. The actions taken would be different if the well being of the organization was primary and the well being of senior executives subservient to that aim.

Outcomes

So, to outcomes. The outcomes that delight will be those that maximise the executives’ (and other folks’) well being. When developing a piece of software, how often do the specifics of the well being of the Folks That Matter get discussed? Indeed, is the subject even discussable? Or is it taboo? In your organisation?

How unsurprising then, that software as delivered is so often lacklustre and uninspiring. That it fails to address the core issues of the well being of the Folks That Matter? That it’s the wrong software.

As a developer or team, do you ever afford your customers (a.k.a. the Folks That Matter) the opportunity to talk about their well being? And how what you’re doing for them might contribute to that well being?

So, might I invite you to stop talking about specious and illusory “outcomes”. And start asking the difficult questions of your customers (and yourselves)?

Here’s a possible opener:

“Would you be willing to discuss what it is you need for your own well being?”

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post
Agile Competency Is A Crock ~ Think Different blog post

The Aspiration Gap

Some years ago I wrote a post entitled “Delivering Software is Easy“. As a postscript I included a chart illustrating where all the jobs are in the software / tech industries, compared to the organisations (and jobs) that folks would like to work in. It’s probably overdue to add a little more explanations to that chart.

Here’s the chart, repeated from that earlier post for ease of reference:

Chart illustrating the gap between available jobs and jobs folks would like to have.

The blue curve is the standard Rightshifting curve, explained in several of my posts over the years – for example “Rightshifting in a Nutshell“.

The green curve is the topic of this post.

The Green Curve

The green curve illustrates the distribution of jobs that e.g. developers, testers, coaches, managers, etc. would like to have. In other words, jobs that are most likely to best meet their needs (different folks have different needs, of course).

Down around the horizontal zero index position (way over to the left), some folks might like to work in these (Adhoc) organisations, for the freedom (and autonomy) they offer (some Adhoc organisations can be very laissez-faire). These jobs are no so desirable, though, for the raft of dysfunctions present in Adhoc organisations generally (lack of things like structure, discipline, focus, competence, and so on).

The green curve moves to a minimum around the 1.0 index position. Jobs here are the least desirable, coinciding as they do with the maximum number of Analytic organisations (median peak of the blue curve). Very few indeed are the folks that enjoy working for these kinds of organisations, with their extrinsic (imposed) discipline, Theory-X approach to staff relations and motivations, strict management hierarchies, disconnected silos, poor sense of purpose, institutionalised violence, and all the other trappings of the Analytic mindset. Note that this is where almost all the jobs are today, though. No wonder there’s a raging epidemic of disengagement across the vast swathe of such organisations.

The green curve then begins to rise from its minimum, to reach a maximum (peak) coinciding with jobs in those organisations having a “Mature Synergistic” mindset (circa horizontal index of 2.8 to 3). These are great places to work for most folks, although due to the very limited number of such organisations (and thus jobs), few people will ever get to experience the joys of autonomy, support for mastery, strong shared common purpose, intrinsic motivation, a predominantly Theory-Y approach to staff relations, minimal hierarchy, and so on.

Finally (past horizontal index 3.0) the green curve begins to fall again, mainly because working in Chaordic organisations can be disconcerting, scary (although in a good way), and is so far from most folks’ common work experiences and mental image of a “job” that despite the attractions, it’s definitely not everyone’s cup off tea.

Summary

The (vertical) gap at any point along the horizontal axis signifies the aspiration gap: the gap between the number of jobs available (blue curve) and the level of demand for those jobs (green curve) – i.e. the kind of jobs folks aspire to.

If you’re running an organisation, where would you need it to be (on the horizontal axis) to best attract the talent you want?

– Bob

Footnote

For explanations of Adhoc, Analytic, Synergistic and Chaordic mindsets, see e.g. the Marshall Model.

 

Obduracy

I tweeted recently:

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

Here’s a table comparing some of the things we know are necessary for success, alongside the things organisations do instead.

Necessary for Success What Organisations Do Instead
Teamwork Heroic individualism
Primacy of people skills Primacy of tech skills
Self-organisation, self-management Managers managing the work(ers)
Systems view of the organisation Partition the organisation into discrete silos
Manage the organisation/system as an integral whole Manage each silo separately
Use systemic measures to steer by Use silo-local measures to steer by 
Relationships matter most (quality of the social dynamic) The code’s the thing (e.g. velocity)
Effectiveness (do the right things) Efficiency (do things right)
Zero defects (quality is free) (defect prevention) Testing and inspections
The workers own the way the work works Mandated processes and methods (management owns the way the work works)
Workers are generalists Workers are specialists 
Trust Rules, policies
Theory Y Theory X
Intrinsic motivation, discipline Extrinsic (imposed) motivation, discipline 
Everyone’s needs matter (everyone’s a customer and a supplier) Only the bosses’ needs matter (your boss is your only customer)
Explicit requirements, negotiated and renegotiated with each customer, just in time No explicit requirements, or Big Requirements Up Front
Incremental delivery against the needs of all the Folks That Matter, short feedback loops  Big Bang delivery, some or all constituencies overlooked or ignored, long or no feedback loops
Kaikaku and kaizen, to serve business goals Kaizen only, by rote
No estimates, flexible schedules Estimates, fixed schedules
Smooth flow (a regular cadence of repeatably and predictably meeting folks’ needs) “Lumpy” or constipated flow 
Work is collaborative knowledge work Work is work
People bring their whole selves to work People limit themselves to their “work face”.

Do you have any more entries for this table? I’d love to hear from you.

– Bob

The Big Shift

Let’s get real for a moment. Why would ANYONE set about disrupting the fundamental beliefs and assumptions of their whole organisation just to make their software and product development more effective?

It’s not for the sake of increased profit – Deming’s First Theorem states:

“Nobody gives a hoot about profits”.

If we believe Russell Ackoff, executives’ motivation primarily stems from maximising their own personal well being a.k.a. their own quality of work life.

Is There a Connection?

Is there any connection between increased software and product development effectiveness, and increased quality of work life for executives? Between the needs of ALL the Folks That Matter and the smaller subset of those Folks That Matter that we label “executives”? Absent such a connection, it seems unrealistic (understatement!) to expect executives to diminish their own quality of work life for little or no gain (to them personally).

Note: Goldratt suggests that for the idea of effectiveness to gain traction, it’s necessary for the executives of an organisation to build a True Consensus – a jointly agreed and shared action plan for change (shift).

Is Disruption Avoidable?

So, the question becomes:

Can we see major improvements in the effectiveness (performance, cost, quality, predictability, etc.) of our organisation, without disrupting the fundamental beliefs and assumptions of our whole organisation?

My studies and experiences both suggest the answer is “No”. That collaborative knowledge work (as in software and product development) is sufficiently different from the forms of work for which (Analytic-minded) organisations have been built as to necessitate a fundamentally different set of beliefs and assumptions about how work must work (the Synergistic memeplex). If the work is to be effective, that is.

In support of this assertion I cite the widely reported failure rates in Agile adoptions (greater than 80%), Lean Manufacturing transformations (at least 90%) and in Digital Transformations (at least 95%).

I’d love to hear your viewpoint.

– Bob

Further Reading

Organisational Cognitive Dissonance ~ Think Different blog post

Something’s Gotta Give

 

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

This reality puts us in a bind. We find ourselves in a position where we have to trade off successful development against conforming to organisational norms. We can have one – or the other. It’s not a binary trade-off, we can for example relax some norms and gain some (small) improvements in success. But by and large it’s a zero sum game. At least from the perspective of those folks that find value in everyone conforming to preexisting norms.

I don’t think many business folks realise this trade-off exists. Almost all the business folks I have met over the years seem unaware that their norms are what’s holding back their success in software (and product) development. I put this down to the absence of any real understanding of the fundamentally different nature of collaborative knowledge work (different to their experiences and assumptions).

Some of the Things

By way of illustration, here’s just a few of the things that are necessary for successful software (and product) development, that businesses just won’t do:

De-stressing

Removing stressors (things that create distress) from the workplace. These things include: job insecurity; being directed and controlled; being told where, when and how to work; etc..

Stressors serve to negatively impact cognitive function (amongst other things).

Trusting

Placing trust in the folks actually doing the work. We might refer to this a a Theory-Y posture.

Experimenting

Finding out through disciplined and systematic experimentation what works and what doesn’t. See: the Toyota Improvement Kata.

Being Human

Embracing what it means to be human; seeing employees as infinitely different, fully-rounded human beings with a broad range emotions, needs and foibles (as opposed to e.g. interchangeable cogs in a machine).

Intrinsic Discipline

Relying on intrinsic motivation to encourage and support a disciplined approach to work.

Meaningful Dialogue

Talking about what’s happening, the common purpose, and what the problems are.

Eschewing Numbers

Realising the limitations with numbers, dashboards, KPIs and the like and finding other ways to know whether things are moving in the “right direction”.

Prioritising Interpersonal Relationships

In collaborative knowledge work (especially teamwork), it’s the quality of the interpersonal relationships that’s by far the greatest factor in success.

Summary

If your organisation needs to see more success in its software (and product) development efforts, then something’s gotta give. Specifically, some of its prevailing norms, assumption and beliefs have gotta give. And given that these norms come as a self-reinforcing memeplex (a.k.a. the Analytic Mindset), a piecemeal approach is highly unlikely to afford much in the way of progress.

– Bob

Red Lines

There’s been a lot of talk about Theresa May’s “Red Lines” in the media recently.

Every organisation I’ve ever known has had their own Red Lines – ideas, principles, practices and policies which are deemed unacceptable, beyond the pale. Many of these latter would make the organisation markedly more effective, efficient or profitable, yet are ruled out.

Here’s a list of such ideas, in roughly increasing order of benefit and unacceptability both:

Transparency of salaries
Attending to folks’ needs
Nonviolence
Restorative justice (vs Retributive justice)
Self-organising / self-managing teams
No estimates
No projects
No tools
No software
Defect prevention (ZeeDee) approach to Quality (vs Testing / Inspection)
Employees choosing their own tools, languages and development hardware
Employees designing / owning their own physical workspace(s)
(colour schemes, lighting, furniture, floor plans, drinks machines, games etc.) 
Employees choosing their own ways of working (methods, processes)
Organising to optimise Flow (vs costs)
Employees choosing their own working locations (office, cafe, remote, etc.)
Employees choosing their own working hours (incl. hours per day / week)
Employees forming their own teams
Employees guiding their own training and career, skills development
Employees hiring their own peers (and coaches)
Paramountcy of interpersonal relationships and social skills (vs tech skills)
Organisational Psychotherapy
Teams appointing their direct managers
Teams appointing their senior managers
“Open book” financials
Employees choosing their own salaries and terms of employment
Teams awarding themselves their own bonuses
No managers (alternatives to control hierarchies)
Fellowship (No positional leadership)
Do nothing that is not play

Where does your organisation draw its red lines – and how much more effective could it be if it redrew them?

– Bob

 

Standard Work and Collaboration

[Tl;Dr: Ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.]

Standard Work

Standard work (also known as Standardized Work) is an operational definition of how the work works today. Best written and maintained (studied, updated) by the folks actually doing the work. Toyota defines Standard Work as ”the steps one needs to walk in order to complete a process”. Mike Rother defines Standard Work as the “Target Condition” in the Improvement Kata. This seems to me to make some sense.

“There is something called standard work, but standards should be changed constantly.”

~ Taiichi Ohno, Workplace Management

5W+1H

In slightly more detail: “Standardized work answers the 5W+1H of a process – the who, what, when, where, why, and how. Who operates the process, and how many people does it take? What does the final product look like, what are the quality check points, what are the tools required to complete the job? When is a part completed and ready for the next step (how long should the cycle time and takt time be)? Where is this process completed and what does this location look like (standardized work cell, point of use storage of tools, etc)? Why is this step necessary or value-adding, or why is this a quality check point?”

“When there is no standard [work], there is no Kaizen (continual improvement).”

~ Taiichi Ohno

In other words, when a process is performed unsystematically in different ways, then:

  1. There can be no basis for comparison (before/after)
  2. One cannot objectively tell if there was a difference or change
  3. No improvement is possible in regards to Time, Quality, Quantity, Cost, etc.

Collaboration is Waste

So, where does collaboration come into the picture? If the standard work specifies “collaborate here” (with 5W+1H or an operation definition for the collaboration) for a particular step, then all is fine and dandy.

But often, in software development particularly, there is no standard work, or the standard work lacks the detail which might suggest the 5W+1H of the collaboration. Exceptions which come to mind are: the daily standup (Scrum), sprint planning (Scrum) and sprint retrospectives (Scrum) (i.e. the various Scrum ceremonies – for which teams rapidly find their own work standards or de facto operational definitions).

Consequently, collaboration in software development is most often ad-hoc. Someone might run into a problem or challenge, and ask a colleague e.g. “Hey, can you help me with this?” or “Can we pair on this for half an hour?” or “Let’s get together and figure out what to do here”.

If we had clearly defined standard work, the specifics of what to do and who to call on when a problem arises would already be defined. Without such standard work, the coordination (set-up, figuring-out) of the necessary collaboration is waste, and interrupts the flow (both of value, and in the Mihaly Csikszentmihalyi sense of the word).

Do I hear you rail against this idea? Do you believe it’s impossible to foresee where and when collaboration might be necessary? Do you enjoy collaborating so much that you’re prepared to dismiss its negatives? May I put it to you that in such circumstances, you don’t actually know what y’all are doing? That you have little or no clear idea how to get from the start of sprint (or longer term) to the end, to the delivery of value? That you’re making much of it (“the way the work works”) up as y’all go along?

“…this model of ‘standards’ as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what ‘continuous improvement’ really means.”

~ Mark Rosenthal

The Bottom Line

This may all seem rather esoteric. How much can it matter whether collaboration costs us a few dollars or hours? For me, ad-hoc and impromptu collaboration is a signal – that our standard work is incomplete or insufficient, and that we don’t understand as much about what we’re doing and how, as we’d like to think.

Does it matter? I leave that to y’all to decide.

– Bob

Further Reading

What Is Standardized Work (And What Is It Not)? ~ LeanBlitz article
Mike Rother: Time to Retire the Wedge ~ Mark Rosenthal

 

%d bloggers like this: