We Can’t Talk About It

We can’t talk about how we could do things better around here.

We can’t talk about what isn’t working.

We can’t talk about the countless opportunties we ignore.

We can’t talk about what hurts.

We can’t talk about dignity.

We can’t talk about how to make magic happen.

We can’t talk to our boss, our employees, our board, our investors.

We can’t talk about the things we can’t talk about.

We can’t talk about our feelings, emotions, needs.

This all makes me feel sad, frustrated, despondent, at a loss. It’s not meeting my need for meaningful connection nor for mutual exploration. Can we talk about that?

– Bob

Further Reading

We Can’t Talk About It ~ Seth Godin blog post
Discussing The Undiscussable ~ William S Noonan

Capability

There’s an old saw that goes:

“If you want to make a great product, build a great team and they’ll make the product for you.”

From my observations, few organisations subscribe to this homily. I’ve always wondered why.

Is it that organisations don’t want to make great products? I’ve certainly seen some of those. Organisations where everyone is just getting by. Keeping their heads down. Expending little if any discretionary effort. Today it seems trendy to call this “disengagement”.

Or maybe it’s just too much trouble. Building a great team rarely just “happens”. People, from senior managers through to the teams themselves, generally have to put a lot of effort over a sustained period to build a great team. And what happens when the product is delivered and the team disbanded? Like the labours of Sisyphus, we start all over again? That seems a demoralising prospect, to say the least.

Or is it that organisations just don’t believe it? That they don’t see a connection between great teams and the capability to build great products?

Or, perhaps it’s not even on the organisation’s radar. That people might believe the old saw, if they were paying attention to it, but because so many other things take priority, the question of i.e. a strategic capability for product development, or even just software development, doesn’t come up? Doesn’t get considered, discussed, acted upon?

Or, maybe organisations are still stuck in the past, not believing that this software thing will catch on, and that the product thet’re creating at the moment is the last one they’ll ever be call upon to make? Why invest time and effort on building a capability that has only one project – the current project – in which to provide a return on investment?

Or maybe any one organisation just can’t serve two masters. That organisations focussed on delivering products to market just can’t focus simultaneously on building a capability for the future, too.

Or maybe there’s not enough money to make it happen. Like any investment decision, the money has to come from somewhere. Short-termism seems endemic in many organisations, particularly the larger, publicly-listed ones. Jam tomorrow never looks as attractive as jam today.

Or perhaps the organisation has no faith in its being able to keep its people, and thus no faith in its ability to sustain any improvements in its capabilities. Perhaps its business model is predicated on high staff turnover, low wages and the idea that “people are merely cogs and resources”. Where this is true – and I have seen some organisations that think like this – then it might be an entirely rational response neither to invest in people as individuals, nor in the organisation’s capability as a whole.

Whatever the reason, I see organisation after organisation where people are stressed beyond endurance because the organisation is not up to snuff in its ability to deliver new products and product enhancements effectively.

I can’t fathom why this is so widespread, and so persistent – and yet I wish I knew.

– Bob

Afterword

Actually, if we look at the issue though the lens of the psychologist, we might suspect that the current situation is a product of people – and especially the Core Group – getting their needs met, albeit in sub-optimal ways. Do Core Groups not need their organisations to have an effective software or product development capability? Given the many ways I have seen organisations degrade or destroy their capability over time, I think this is a valid question.

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

 

Ten Benefits of Flow

The idea of “flow” in manufacturing is widely know, even if maybe not so widely implemented. The world of software and product development is not much like manufacturing, but we can repurpose some of the ideas and concepts. Flow is one such concept we might choose to repurpose.

I guess most people involved in software and product development can intuit the idea of “flow”, but maybe not articulate it clearly or be able to cite the potential benefits of a flow approach.

“Economies of scale is a myth. Economies are in flow”

~ John Seddon

• 10. Improves morale. Employees want to do good work. They want to see progress. They want be involved. Implementing flow brings these things together.
• 9. Reduces inventory. With improved flow, work in process (WIP) is reduced.
• 8. Makes continuous, incremental improvement (kaizen) easier. Flow is hard since it invites reductions in WIP (work in process), queues and buffers. Thus, flow exposes problems (blockers) that may have otherwise gone unnoticed, and invites us to deal with them, lest development stalls.
• 7. Improves visibility. Flow, by reducing the amount of WIP, lets people see more clearly what is being worked on, and what is going on more generally. This in turn reduces confusion.
• 6. More joined-up organisations. Implementing flow in the middle of the product development value stream – i.e. in software development: analysis, design, coding – provides opportunities to better integrate those functions. And moreover, opportunities for integrating the upstream (fuzzy-front-end) and downstream (testing, ops, production) functions too.
• 5. Improves productivity. Many of the wastes so inherent to batch and queue working (a.k.a. “Waterfall”) are greatly reduced when we focus on and organise for flow. As a result, productivity increases.
• 4. Improves flexibility. With improved flow, we have smaller, more manageable units of development (a.k.a. batch size) equipment and this allows us to respond more quickly to changes in priorities.
• 3. Better due-date performance. By reducing the size of queues and buffers, cycle times are reduced and due-date performance becomes more regular and predictable.
• 2. Builds in quality. When batch sizes reduce, defects are detected earlier (closer in time to when they happened) and less rework is necessary, with an encouragement to fix defects as soon as they happen.
• 1. Improves safety. With flow, work happens at a more regular, sustainable pace, with fewer mad peaks and boring troughs, translating to less distress and more (potential) eustress for the people involved. cf Anzeneering

– Bob

The Nature of the Challenge

“If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”

~ Albert Einstein

We’ve had something like fifty years to solve the problem of reliable, effective software development. And not only have we not solved the problem, it looks like we’ve many more years ahead of us before we get to that elusive “solution”.

I’m not even sure there’s any kind of consensus on the nature of the problem, or even that we have a problem.

I’ve been studying and researching and exploring and thinking about the state of software development – à la Einstein – for the best part of thirty years. This post is about my take on the nature of the problem, as I see it. Maybe you see things differently. Either way, I invite you to share here with me and others how you see things.

Whatever the real challenge is, we seem to have a surfeit of possible solutions. Solutions which rarely get applied in the real world. In the myriad of organisations making software. Or attempting to.

So, as I see it, a key question is “why does so little of our research and new knowledge get adopted and applied?”.

We can point the finger in various directions, but I’m not looking to apportion blame.

It might be fair to ask “Who needs it? Who needs reliable, effective software development?”. It’s been my experience that precious few organisations, despite their protestations and pretensions, appear to need things to radically change for the better.

The Core Issue

There’s the rub. Mostly, people don’t seem to need things to get better. Executives, shareholders, managers, workers, customers – everyone whinges from time to time, but makes little concerted effort to actually do anything.

I’d call this a lack of motivation.

Awareness, Responsibility, Commitment

From my coaching days, I remember the A.R.C. mnemonic. This reminds us that commitment (to actually do something) is a product of people choosing to take responsibility to do something, and that this choice depends on awareness. Awareness that change is possible. Awareness that things can be better. Awareness that things are better, in some few places. And awareness that someone will have to do something before things will get better.

So, for me, I believe there is a problem. Maybe fifty years ago it was a different problem. Maybe back then, it was much more about lack of knowledge, lack of reliable technology, lack of tools, lack of importance (of software, to the world).

But now, we have the knowledge but aren’t applying it. We have reliable tech and tools, and these aren’t making much difference. And software is hugely more important to our products, businesses and societies that ever it was.

Yet a problem remains. and I believe the prime symptom of the problem is that people are unaware of the possibilities, unaware of how much better things could be, unaware of the advances in fields like psychology, sociology, group dynamics and neuroscience. And yes, unaware even of the real benefits of things like Agile and Lean – and how to realise them.

Awakening Awareness

But awareness is not the heart of the problem. If it was just a lack of awareness, then people could make themselves aware. After all, the knowledge is out there. If not on the intarwebs, then in books, periodical and the heads and hands of the (few) people who have done this stuff.

What makes for more awareness? Curiosity? What factors influence whether someone will sit up and wonder about their problems – and seek solutions to them?

I’d say motivation. Motivation to become curious. And then to pursue that curiosity.

Dan Pink suggests (intrinsic) motivation depends on three factors: autonomy, mastery and purpose. In this context, though, I subscribe to Marshall Rosenberg’s insight: motivation (to action) stems from people having (unmet) needs.

So here’s my bottom line: Reliable, effective software development won’t become widespread, won’t become the norm, until people need that to happen. And in most organisations today, I just don’t see that need manifest. Or even discussed. You?

– Bob

The Software Development Manager Role Is An Oxymoron

Managing: adjective
1. BRITISH having executive control or authority “the managing director”

See also: Management

In my post of a couple of year back entitled How To Be A Great Software Development Manager, I closed with the suggestion that great software development managers work themselves out of a job. Well, out of that job, anyways.

Given that effective software development is about quality relationships, effective collaboration, and sound cognitive function, then may I invite you to consider the implications and impact of power-over relationships – such as the manager – managed relationship – on these three aspects?

Here’s my take:

Quality relationships thrive on direct dialogue (as contrasted with the intermediated dialogue implicit in management hierarchies). And the coercion implicit in the manager’s role, as a form of violence, always serves to undermine humane relationships, however benign the intent.

Collaboration thrives when purpose ((and thus direction) is held in common, rather than handed down from “above” (another form of subtle, yet significant, coercion).

Cognitive function thrives under conditions of eustress (contrasted with the conditions of distress arising from e.g. being coerced or otherwise persuaded to do things not obviously related to the declared common purpose). Fear, however veiled, and in whatever form, always impairs cognitive function.

The manager – managed relationship exemplified the dysfunctions mentioned above, undermining as it does the quality of fellowship-style relationships (power-over rather than power-with), collaboration, and cognitive function.

There’s also a variety of research showing the dysfunctions inherent in the (related) leader – follower relationship.

The Bottom Line

The bottom line here is, does it make any kind of sense to create the kind of conditions so inherently antithetical to effective software development (and other kinds of collaborative knowledge work)?

If we were starting from scratch, absent the baggage of history and expectation, would we ever choose to institute the manager – managed relationship, especially in our software development organisations? And what price are these organisation paying, largely unnoticed, for continuing to carry that baggage?

– Bob

Further Reading

Power and Love ~ Adam Kahane
Flow: The Psychology of Happiness ~ Mihaly Csikszentmihalyi

You’d Have To Be Crazy

You’d have to be crazy… to suggest to managers that management is a dysfunctional anachronism for knowledge work, and recommend other means to coordinate and direct the work.

You’d have to be insane… to disband the functional silos in your organisation and move to another organising principle, such as value streams.

You’d have to be mad to stop using projects as the container for development work, and adopt e.g. some kind of flow-based approach.

You’d have to be a lunatic… to embed organisational change in the processes of daily operations and business-as-usual.

You’d have to be cracked… to want to see a wildly successful business, with all the extra work, risk and upheaval that would entail.

You’d have to be a sandwich short of a picnic… to stop directing people and instead give them the support they need to direct and organise themselves.

You’d have to be psycho… to hire a psychotherapist to help improve the health of your organisation.

You’d have to be cuckoo… to trust your people to find their own, effective ways of making software and products.

You’d have to be barmy… to believe the science about people, collaboration and motivation, and implement policies based on that.

You’d have to be deranged… to want to know what’s really going on, to think about stuff and to use your brain.

You’d have to be unhinged… to run against the grain of the opinions and expectations of your peers and do things differently to the accepted norms.

In short, you’d have to be wacko to step out of line. And there’s the rub. So many pressures opposing positive change. So much danger for the reformer. So much safer to conform, keep quiet, and not rock the boat.

“And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful in its success, than to set up as a leader in the introduction of changes. For he who innovates will have for his enemies all those who are well off under the existing order of things, and only the lukewarm supporters in those who might be better off under the new.”

~ Niccolo Machiavelli

So, until the deranged win out, we continue to live and work in a world, and in organisations, already entirely bonkers.

– Bob

The Specialism Meme

Do you feel you have much more to offer than the bounds of your current job afford you?

At the recent Agile Testing Days conference in Potsdam, one of the most common themes I heard from individuals was just this. That they could be doing so much more for themselves, their teams and their organisations than their given role, remit and management expectations allowed. And that they could be having much more fun in work, too, if only they didn’t feel so pigeon-holed and constrained by their nominal specialism.

Memeplexes

We’re rarely aware of our prevailing memes and memeplexes which, nevertheless, profoundly influence the way we live and work. My recent post on Theories of Motivation and the Theory X and Theory Y memes is but one case in point.

Another of the many memes which pass uncommented and unexamined in most organisations is the idea of specialisation. In the Analytic memeplex, narrow specialism is deemed a helpful and beneficial strategy for making individuals more efficient and productive. This stems back to at least the days of Adam Smith and his 1776 book “The Wealth of Nations” wherein he described the principles of specialisation and division of labour.

Subdivide a job – such as making pins – into its constituent operations, and have different workers become expert in each of these different, repetitive operations. This allows for rapid training of non-skilled labour, and “an enormous increase in the productive powers of labour”.

T-Shaped People

In e.g. Lean Manufacturing, companies try to develop workers with multiple skills, multiple specialisms. This aids flow of work through the factory, by allowing workers to redeploy to different jobs and stations when bottlenecks and other impediments to flow arise. The production line can more easily adapt to the ebb and flow of demand.

In knowledge work too, we see organisations looking for T-shaped people – people with deep skills in maybe one or two areas, but with useful skills in perhaps a dozen other areas, too. And not only do they look for these T-shaped people, but organise the work such that people can become more T-shaped over time, and get to regularly use their whole range of skills “on the job”.

Waste

Yet, the egregious waste of human potential continues in most Analytic organisations, where people are locked into a narrow specialism, and expected to work inside that box, neither deviating nor wandering outside of it. This hardly endears the employer to the workers it so confines. In fact, there’s a whole bunch of dysfunctions that stem from the Specialism Meme in knowledge work:

• Impediments to flow
• Specialists as bottlenecks
• Boredom
• Waste of human potential

Why this tie to the Specialism meme? Because it’s bound to the other memes of the Analytic memeplex. Try to overthrow or replace this meme, and the other memes in the Analytic memeplex act to oppose the attempt.

It seems to me fruitless to address the dysfunctions inherent in the idea of specialisation, without addressing the other, interlocking and reinforcing memes in the Analytic memeplex too. And then we’re into the territory of Organisational Transition and the wholesale, organisation-wide replacement of one memeplex (i.e. Analytic) with another (i.e. Synergistic).

How would you explain the continuing hegemony of the Specialism meme in knowledge work organisations everywhere? And what would you suggest by way of means for replacing it?

– Bob

Act Different

“Action is the foundational key to all success.”

~ Pablo Picasso

Since its inception, some four years ago, the title for this blog has been “Think Different”. I chose it as a tribute to Steve Jobs, as a reminder of the fundamental role of mindset in creating effective organisations, and as a statement of intent.

For me, the ability to think different(ly) has always been the gateway to change, to improvement, to effectiveness, to reducing the egregious waste of human potential we see in so many of our organisations, and to acting differently.

Interplay

But the two interplay. Action influences thinking at least as much as thinking influences action. Research has shown that acting differently – “fake it ‘till you make it” etc. – can indeed help people into thinking differently.

The Shewhart Cycle (Plan-Do-Check-Act) shows the circular nature of improvement, and the interplay between thinking and doing.

And similar themes underpin Boyd’s OODA loop (Observe-Orient-Decicde-Act) and Allen Wards’s LAMDA loop (Look-Ask-Model-Discuss-Act). Not to mention the Scientific Method more generally.

And as a counterpoint, I like this quote originating with Martin Gabel:

“Don’t just do something, stand there.”

~ Martin Gabel

Incrementalism

We don’t have to effect a change in our actions all at once.

“You can make a 180° change in your life by making a 1° change in what you do.”

~ Raymond Aaron

Raymond Aaron suggests that If you have an idea for a new way to act, do it now. Yes, I know, that can sound daunting. But he points out that you don’t have to do it 100% now. Even 1% now is a start. And making a start is a key aspect of acting different. It’s what differentiates acting different from thinking different.

Positive Deviance

Another way to begin acting different is explained by the idea of positive deviance. Go look for positive deviants, and start practising what they’ve already been doing.

“It is easier to act your way into a new way of thinking than think your way into a new way of acting”.

~ Jerry Sternin

Think Different by all means, but look for action on acting different, too.

– Bob

Further Reading

The Power of Positive Deviance ~ Richard Pascale & Jerry Sternin

Theories of Motivation

For those who have not already come across these terms, Theory X and Theory Y are theories of human motivation, explained by Douglas McGregor in his 1960 book “The Human Side of Enterprise”. These two theories describe two contrasting models – or sets of assumptions – about workforce motivation.

“How management chooses to treat its people impacts everything – for better or for worse.”

~ Simon Sinek

Theory X

In Theory X, management assumes people are inherently lazy and dislike work. As a result of this, management believes that people need to be closely supervised and comprehensive systems of control developed. According to this theory, people will be disinclined to apply effort without extrinsic motivations (bonuses and the like) and will avoid responsibility whenever they can. Theory X managers often rely on the threat of punishment to gain compliance. A Theory X manager believes that his or her people do not really want to work, that they would rather avoid responsibility and that it is the manager’s job to structure the work and energize their people.

Theory Y

Under Theory Y, management assumes people may be ambitious, self-motivated and capable of exercising self-organisation. A Theory Y manager believes that, given the right conditions, most people want to do well at work. They believe that people find intrinsic motivation in the satisfaction of doing a good job.

Aside: Many people interpret Theory Y as a positive set of beliefs about people. A close reading of The Human Side of Enterprise reveals that McGregor simply argues for managers to be open to a more positive view of people, and to the possibilities that this perspective creates. See also: The Pygmalion Effect and the Golem Effect.

“I shall always be a flower girl to Professor Higgins, because he always treats me as a flower girl, and always will; but I know I can be a lady to you, because you always treat me as a lady, and always will.”

~ George Bernard Shaw, Pygmalion

The Relationship Between Theory X and Theory Y

For McGregor, Theory X and Y are not different extremes of the same spectrum, but rather two different, orthogonal dimensions.

Theory X, Theory Y and the Mindsets Of The Marshall Model

Theory X – and it’s counter part, Theory Y – are two of the key memes in the memeplexes of the Marshall Model. Analytic-minded organisations tend to be archetypes of Theory X, whereas synergistic-minded organisations tend to eschew Theory X in favour of Theory Y assumptions and beliefs. The following chart illustrates the distribution of Theory X and Theory Y over the four mindsets of the Marshall Model.

 

“The biggest barriers to strategic renewal are almost always top management’s unexamined beliefs.”

~ Gary Hamel

– Bob

Further Reading

The Human Side of Enterprise ~ Douglas McGregor