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

More NoTesting

My recent post on No Testing met my needs in that it helped start, and sustain, some interesting face to face conversations at Agile Testing Days 2014 in Potsdam, last week.

Of course, face to face, one can explore a subject and clarify confusions rather more easily than via online channels.

I Can’t Believe It’s Not Testing

Some folks have expressed some incredulity that there might exist strategies – other than “testing” – by which software teams might attend to folks’ needs. These needs including: a quality product, confidence in that quality, and so on. Many of the questions about my post seem to have stemmed from reading it through the lens of “there must be tests, and testing, therefore he must mean…”

So, for clarity, my original post suggests that, yes, we don’t necessarily need testing. Not that testing could be done by others, such as developers. Or at other times, such as before code is written, or even as it is being written. Rather, I suggest that folks’ needs can – in some cases – be met by e.g. more capable developers, more humane relationships,  an Agile Path to Quality, and letting the team make the difference.

I guess this position is a little closer no “No testing” than some have guessed.

What Happens To The Testers?

Listening at Agile Testing Days, I heard a lot of folks – the majority, testers – expressing frustration, disappointment, etc. about their situations. Specifically, how they felt they could be contributing so much more to their teams and products, if only the opportunity was there.

It strikes me that there are so many “testers” willing and able to do so much more than just “testing”, yet find themselves pigeon-holed into a narrow definition of their role. A number of the conference presentations spoke to this theme, including my own and that of Antony Marcano (links to videos soon).

So, for clarity, I’d suggest that many testers would be fine in a No Testing shop or team, as it affords them opportunities for:

• more autonomy in attending to folks’ need
• more scope for mastering software development
• participating more fully in a broader range of team activities
• addressing the core purpose of their organisations, teams and products.

– Bob

Listening

“Listening…means entering the private perceptual world of the other and becoming thoroughly at home in it. It involves being sensitive, moment by moment, to the changing felt meanings which flow in this other person…. To be with another in this ways means that for the time being, you lay aside your own views and values in order to enter another’s world without prejudice. In some sense it means that you lay aside yourself…”

~ Carl Rogers

How often do you feel people are listening to you? That they’re interested in how you’re feeling and what you have to say? That by listening they’re connecting with you as a person? How often do you listen well enough that others feel that same way about you?

Practise

Whilst in Berlin last week for Agile Testing Days 2014, I chose to avail myself of the opportunity to practise my listening skills.

In the course of this practise, I’ve learned a few things – and had a mini-epiphany – which I thought might be useful to share with y’all.

“The moment one gives close attention to anything, even a blade of grass, it becomes a mysterious, awesome, indescribably magnificent world in itself.”

~ Henry Miller

Judgmental Listening

I’ve written previously about judgment and its connection with the quality of relationships. I’ve been practising for a year or two now on reducing the (moralistic) judgments integral to my observations. This has brought me to the point where I’m now aware of the judgments I’m making – and have been making all my life – whilst listening to things people are saying. You know the kind of thing. Someone says something and you immediately start evaluating what they’ve said, and, incidentally, the speaker themselves: “That’s cool”. “That’s dubious”. “That makes no sense to me”. “They must be mad/bad/stupid/awesome”. And so on. A whole host of judgments.

Hierarchy of Listening

Various researchers have written about hierarchies of listening skills. The hierarchy I have in mind does not correspond closely to the core themes of these other hierarchies. Rather, I’m looking here at the question of listening from the perspective of improving the quality of interpersonal relationships. Listening effectively can help raise the quality of interpersonal relationships, whilst listening ineffectively can actually undermine those relationships.

Fake Listening

Fake Listening describes situations where the “listener” is only pretending to listen. The sounds of the speakers words are heard, but the “listener” does not process those sounds to derive meaning. Fake listening can be accompanied with some or all the signs of active listening, but the speaker, sooner or later, notices that the “listener” is only faking it.

Listening to Reply

Maybe the most common kind of listening in our organisations, workplaces and working relationships today. Here, people listen just enough to detect when it’s their turn to say something, and to be able to say something seemingly relevant to the thread of conversation. Nancy Kline in her work with the Thinking Environment contrasts this with “listening to ignite thinking [together]”.

“To be an effective Thinking Partner is to proffer alert, present, non-judgmental and attentive silence to another while they are thinking. The person being listened to, the Thinker, is held in a benevolent field of attention, free of competition, in which the quality of the listening, is a ‘listening to ignite thinking’ not a ‘listening to reply'”.

~ Michael Heuerman

Active Listening

Active Listening involves listening with all senses. As well as giving full attention to the speaker, it is important that the ‘active listener’ is also ‘seen’ to be listening – otherwise the speaker may conclude that what they are talking about is uninteresting to the listener.

“Interest can be conveyed to the speaker by using both verbal and non-verbal messages such as maintaining eye contact, nodding your head and smiling, agreeing by saying ‘Yes’ or simply ‘Mmm hmm’ to encourage them to continue. By providing this ‘feedback’ the person speaking will usually feel more at ease and therefore communicate more easily, openly and honestly.”

Active listening not only means focusing fully on the speaker but also actively showing verbal and non-verbal signs of listening. Generally speakers appreciate listeners demonstrating their ‘active listening’ by the listener responding both verbally and non-verbally to what they are saying.

NVC Listening

I’m calling this state of listening “NVC listening” because it draws on the Nonviolent Communication work of Marshall Rosenberg. Specifically, Rosenberg invites us to “empty our mind and listen with our whole being” whilst “focussing on what’s alive, right now, in the other person”.

Other have described similar states and labelled them with terms such as “Therapeutic Listening” or “Empathetic Listening”. I choose not to use these terms, primarily because I use what I’m here referring to as “NVC Listening” as a practise technique for raising my awareness of my own judgmental listening, whilst actually trying to “empathise with what is alive in the person” to whom I am listening.

The noted Psychotherapist and creator of Client-Centred Therapy, Carl Rogers, defined empathy as:

[the perception of] the internal frame of reference of another with accuracy and with the emotional components and meanings which pertain thereto as if one were the person, but without ever losing the “as if” condition (Rogers, 1959, p. 210-211).

Active Listening vs Compassionate (NVC) Listening

There are many places on the web which explain Active Listening, its benefits, and how to practice it. But the outward signs of Active Listening can often belie our inner judgmental filters through which the speaker’s words are passing.

Compassionate listening, in contrast, need not have any outward signs. Although that might be disconcerting or unhelpful for the person speaking.

In practising NVC Listening, I try to combine the visible signs of Active Listening with internal aspects of compassionate (empathetic) listening. I try to notice myself whenever I’m beginning to start an evaluation or form a judgment, and short-circuit // override that in favour of getting in touch with what’s alive in that person.

Epiphany

The epiphany I mentioned at the head of this post is this:

We can notice our natural tendency to judgmental listening if we have something else to focus on. In NVC Listening I focus on what might be alive in the other person. Where they’re coming from. What’s important to them. Their possible feeling and needs underlying the things they’re saying.

I believe that we can improve our listening skills, and that skilful listening can have a deep impact on the quality of our relationships – relationships essential to working effectively with each other in knowledge-work settings.

Appreciating What’s Alive In People

Positive Psychology studies have revealed the positive effects on happiness, life satisfaction, energy, etc., that come from appreciation. Nonviolent Communication suggests we look for what’s alive in people.

“[Some people] have a wonderful capacity to appreciate again and again, freshly and naively, the basic goods of life, with awe, pleasure, wonder, and even ecstasy.”

~ A.H. Maslow

Whenever I’m practising NVC Listening, I’m not only also trying to sense what’s alive in the person to whom I’m listening, but also I’m trying to appreciate that aliveness. To value it. To savour it. To give thanks for it. When it’s working for me, this appreciation gives me the energy I need to continue.

“Whenever we are appreciative, we are filled with a sense of well-being and swept up by the feeling of joy.”

~ M.J. Ryan

Listening to Ourselves

All of the above not only applies when we’re listening to other people, of course. It applies at least as much when we’re listening to ourself. To our own thoughts, feelings and needs.

Irony

And the irony of writing about listening – absent any immediate opportunity to listen to the thought and reactions of the reader, and connect with them as people – is not lost on me.

Invitation

I invite you to have a go at “NVC Listening” when you find yourself with a suitable opportunity. I’d be delighted to hear how it seems to affect the quality of the relationship with the person – maybe even yourself – to whom you are listening.

– Bob

Further Reading

Nonviolent Communication: A Language of Life ~ Marshall Rosenberg
More Time To Think: A Way of Being In The World ~ Nancy Kline
Active Listening ~ Skills You Need
It’s Not Enough To Listen ~ Jessica Grogan, Ph.D.

No Testing

Testing. Checking. Inspection. Exploration. Learning. Everybody has a different understanding of what testing is. And is not. (Hint: AFAIC, it’s NOT “QA”. And it’s NOT “TDD”).

I’m not going to upset people by offering my own definition. I make no claims to be an expert on testing.

When I’m a customer, I know I don’t want to pay extra just for a product that works as advertised. By extension, I’d not want to pay for testing. I want a product that “just works”. And if asked to pay more, I’d have to enquire skeptically “why can’t you people build it right in the first place?”.

Some years ago now, David Anderson wrote a blog post asserting that “All testing is waste”. I concur. But is it necessary or unnecessary waste (Type I or Type 2 Muda?). And does that categorisation depend on the capabilities of the team(s) – the developers – building the software? If the developers can’t deliver software with the intended levels of defects (which could be non-zero, btw) then maybe testing is a necessary waste, to compensate for that inability. And maybe it’s cheaper and more humane to employ less capable developers, bolstered by testers, than to have capable developers who can meet intended defect levels reliably.

So, do we have to test, despite the customer being unkeen to pay for it? Despite it adding little or no value from the customer’s point of view? Or can we find other, more economic and humane ways to meet the needs testing currently addresses?

Needs

“Testing” is one strategy for getting folks’ needs met. Some of their needs, at least. We might imagine there could be other strategies for getting those same needs met.

What needs does testing address? And who has these needs?

• Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.
• Customers need stuff that works (that meets their needs), for a price they’re willing to pay.
• Companies making stuff need to safeguard their reputations and revenues.
• Managers generally need to appear capable of delivering new products which meet the company’s and customers’ needs, whilst also controlling margins (costs vs returns).
• And of course every individual may have their own particular personal needs, too.

Strategies

My question is: “Is testing the best strategy for meeting all the above needs?”. It may be the best known. The most widespread. The default. But is it the most economic? The most humane? Indeed, what are the dimensions of “best” here? Or even of “reasonably effective”?

“No Testing” attempts to flag up these questions. No soapbox. Just open enquiry.

– Bob

 

 

 

 

 

Death On My Mind

Caution! Raw emotions, vulnerability and plain-talking on display.

For many years now, every day starts with me asking myself “Is today the day I’m going to kill myself?” It hasn’t happened yet. So I wonder will there ever be a day when it does happen? And yet, the little voice still asks the daily question.

Where does the voice come from? Damned if I know. I don’t believe I’m suffering from depression. Or bipolar. Although given the state of mental healthcare provision in these parts, I’m unlike to find any help in resolving that question. Even if I felt like following that path.

I’m guessing – in a self-diagnosing kind of way – that my feelings of anxiety, ennui, frustration, envy, idealism, contempt, outrage, exasperation, bewilderment, disbelief, resentment self-pity and despair indicate that some of my needs are not getting met. I’m also guessing that these unmet needs include (in no particular order, as far as I can discern):

• meaningful (human) connections
• opportunities to make a difference – whatever “making a difference” might mean
• some relative financial stability and security i.e. a modest regular income
• self-empathy
• empathy from others
• opportunities to help people (although, maybe this is a strategy for getting the above needs met)

I can’t for the life of me (sic) understand why the unmet-ness of these needs makes me wonder about something as final as suicide. In the cold light of day, they hardly seem to possess the giant import my subconscious confers on them.

But there it is.

Pointless

Most days, life just seems so damn pointless. And little to zero prospect of any future day being any different. It’s that tiny possibly, though, along with the love and concern I have for my family and friends, that keeps me from pulling the metaphorical trigger. I do appreciate those folks who let me know that I’m making some kind of difference in their lives. But it does little to dispel the feeling of futility.

Why write about this?

I have no clear aim in mind. But maybe there are some other folks out there with similar thoughts and feelings. Perhaps it’s an attempt to empathise. A different path to meaningful (human) connection? Or maybe just putting these words down can shine a light on the matter, for my own reflection.

Will I publish this? I generally publish most of my ramblings. So I guess this one will get published too. Thoughts of consequences swim in and out of consideration. But who can tell where disclosure will lead? Or non-disclosure? Surely any shift has to be for the better?

Request

I’m thinking there’s likely no simple solution, no one thing that will get my needs met. No one thing to quieten that insistent little voice. But just presently, I’m guessing that some gainful employment might help. Some role that involves working and making meaningful connections with folks that are looking to make a difference too. Would you be willing to consider if you might know of, and be able to put me in touch with, someone like that?

Response

You may be inclined to respond. That would be fine. Although I’m not looking for sympathy. Or advice. In any case, thank you for reading this far. I anticipate some judgmentalism, too. We’re only human, after all.

– Bob

Let The Team Make The Difference

[Tl;Dr: Teams can be more effective by eschewing both Scrum Master and Product Owner – if they can count on getting the support they need when they need it.]

I’ve written before about Familiar and how we delighted both our customers and ourselves by the way we approached software development. And my recent observations on the role of Scrum Master seem to have struck a chord.

At Familiar, we had neither Scrum Masters – although using a Scrum-like approach to development – nor Product Owners. And we did just fine. Better than fine, actually. Our teams found their own ways of working, handled their own interfaces, and gained an effective understanding of customers and their needs, by themselves. With support from one or more extra-team specialists, when the team decided they needed it.

I have seen teams struggle when they have to go it alone in finding new and more effective ways of working, especially if they come from another place, like a batch-and-queue (a.k.a. waterfall), project managed, big-requirements-up-front past.

Yet teams of highly intelligent, reasonably motivated folks can exceed expectations when allowed to make their own choices, so long as they know how to call for help and can do so, quickly and often, whenever they feel they need to.

Perceived Risk

The idea that people have to be supervised is deeply ingrained in our view of work. The very notion of allowing teams their head without a Scrum Master or Product Owner to watch over them, keep them on track and generally boss them about seems highly risky. Despite all the evidence and advice, most organisations are still in no way ready to embrace self-organisation without the safety net of supervision. And with supervision, self-organsation offers hardly any advance at all.

Support

By support, I mean someone – or some number of people – that can help the team find ways past the obstacles they will regularly encounter. Some shared context is useful, so the helper(s) may have some longer-term relationship with the team, rather that just being called in “cold”. Some of the skills useful in such helpers will include Amanuensarian, coach, and therapist. I wrote a fuller list some years ago.

Given the wide range of skills that might be needed, only the very largest organisations are likely to have such people on staff.

Protection

Another often quoted aspect of the Scrum Master role is the protection he or she can afford the team, from interruptions and other disruptions. I wouldn’t want to downplay the value of this, but I would be much happier to see teams themselves more aware of the value of flow and the need to minimise interruptions – including those self-generated. Can teams handle interruptions themselves? Yes – with adequate awareness and support.

Why Not The Scrum Master

Apart from the Universal Scrum Master Failure, the very nature of the relationship between many Scrum Masters and their teams tends to an unhealthy power dynamic. Many managers – unfairly or unreasonably, in my view – hold the Scrum Master accountable for the results of the team. Naturally, then, the Scrum Master feels under some form of pressure (such as duty, self-interest, or similar) to push the team to do “better”. And, human nature and learned behaviour being what is it, oftentimes this pushing can be coercive and violent. Few realise the significant damage that such a dynamic wreaks in collaborative knowledge-work.

Undoubtedly there are (a few) Scrum Masters that avoid this dynamic. These folks appreciate the need to create an environment where the team can find motivation (to the extent they so choose) and learn. By learning, they become more effective over time. Unfortunately, the few enlightened Scrum Masters rarely find themselves in organisations where cultivating this kind of environment for their team is anything but excruciatingly difficult and painful for themselves.

Both of these conditions together – “enlightened” Scrum Masters and “fertile” organisations soil – are necessary to allow the Scrum Master role to deliver value. It’s so rare for both these conditions to exist at the same time in the same place as to mean that maybe less than 10% of situations would derive value from having someone in the Scrum Master role.

Why Not the Product Owner

The issue of power dynamics has less impact in the relationship between teams and their product owners. Although the nature of that relationship is very varied, more varied even than that of Scrum Master and team.

I reject the Product Owner role for different reasons. Specifically:

• Setting up a division of responsibilities increases the likelihood that the team will – in practice – relate less well to customers and users, and their concerns.
• Having a distinct Product Owner reduces the opportunities for emerging technical possibilities to inform the direction of evolution of the product. Put another way, teams often uncover opportunities for new, as-yet unthought-of features, and directions for the product, but for a host of reasons these opportunities go by the board.
• The Product Owner role allows for “absentee” Product Owners, where key customer intelligence is not gathered, or not passed on to the team. When the team is handling these matters, it’s less likely for such matters to get overlooked.

Summary

In summary, if I were on a development team, or responsible for one, i’d want neither a Scrum Master nor a Product Owner. I would instead take pains to ensure that the team had a wide range of skills and experience at its beck and call, and the know-how of how to pull such skills as it needed them. To reduce delays, this may mean having one or more such people on hand, close-by, at all times. This does not mean a Scrum Master.

– Bob

Producing Software Is Not The Purpose Of Software Development

[Tl;Dr: All too often we can all get so wrapped-up in the joys and frustrations of creating software that we lose sight of the real purpose.]

I often invite my conference audiences to spend a few minutes discussing, amongst themselves, some question or other relevant to the session. One of the questions which I regularly pose is:

“What is the purpose of software development?”

This question tends to confound the audience for a few moments, prior to their entering into animated discussions on the subject. It always seems like a few minutes is nowhere near long enough to do the question justice.

I ask the question for a number of reasons, not least because of Dan Pink’s assertion that the three keys to intrinsic motivation are autonomy, mastery, and purpose. I rarely come across people and teams who can articulate their purpose.

Your Take?

How about you? What would you say is the purpose of software development?

My Take

So what IS the purpose of software development, as I see it?

• It’s NOT about producing software. Customers don’t want software, although sometime they may want the utility that software provides. Pure software is NEVER the Whole Product, even for apps and other “software products”.
• It’s NOT about delivering value. Despite all the information and opinion to that effect. Needs and emotions trump economic or financial value, every time.
• It’s NOT about solving “business problems” nor “business benefits” nor providing “customer value”. Even when people say that it is. These terms are a thin veneer of amtssprache hiding the needs of e.g. the Core Group – and others – from examination, and avoiding messy discussions about needs and emotions. See also: POSIWID.
• It’s NOT about “creating solutions that help people and deliver economic benefit for an organisation”.

• It IS about meeting the needs of a wide range of people. People involved in the organisation where the software development is happening. Developers. Other technical people. Managers. Executives. Customers. Buyers. Users. Suppliers. And a lot of the meeting of those needs has little or no connection with software.
• And it IS about creating “Whole Products”. Products in which software plays only a minor supporting role, in the overall scope of things.

So, my own answer to the question would be something like:

“The core purpose of software development is to create elements of complete products or services. Complete products or services which attend to – and hopefully meet – the emotional, human needs of a variety of interested people.”

Which, incidentally, looks to me to be quite close to the Agile Path to Quality. Not to mention the Antimatter Principle.

Implications

If we accept the above as our core purpose in software development, it affords us some interesting implications:

• Whatever purpose we believe we are pursuing will direct our efforts and our focus. If we mistake the purpose of our work, we will likely produce results which fail to meet the real mark, which fail to address the real purpose, and which therefore fail to meet the real needs of some or all of the people involved.
  Aside: This seems like a good explanation for why “software development is so broken, almost everywhere on the planet”.
• Most software methods, frameworks, etc. are predicated on an implicit or explicit purpose for software development. In most cases, this assumed purpose is at odds with our true purpose. Thus, when we choose a method or framework suited to our mistaken purpose we end up with something dysfunctional. The history of software development is stuffed full of examples of this.

– Bob

Further Reading

Who Really Matters ~ Art Kleiner
Drive ~ Dan Pink (book)
Drive ~ Dan Pink (video)

The Scrum Master Role Is a Huge Waste of Human Potential

There were a lot of Scrum Masters and Agile Coaches at last week’s Agile By Example 2014 (Warsaw). Enough that I was surprised by their numbers, in relation to the total number of attendees. I guess the organisers were less surprised though, looking at the relatively high number of sessions focussing on Scrum Mastering and related matters.

During the conference I tweeted:

and some folks found it a tad too cryptic, requesting some expansion / elaboration.

The Role of Scrum Master

It’s my view that we invest the role of Scrum Master – as a given for Scrum teams – with far too much deference and gravitas. I’d go so far as to say that the role is a crock.

As Angel Medinilla pointed out in his excellent session ”Developing Great Scrum Masters”, the role is wholly an invention of the Scrum authors, having zero antecedents and little to zero evidence supporting its alleged value.

Listening to the stories of various Scrum Masters at ABE14, it struck me just how many of these fine folks were and are striving to care for their teams, add value, make a difference to people’s lives, and so on. And more so, how the Scrum Master role itself was and is frustrating them in all these aspirations.

So, when I say the Scrum Master role, both as widely conceived and as generally practiced, is a huge waste of human potential, what I mean is that most people in that role could be and are capable of so much more, yet find themselves – through constant firefighting, running around, chasing people, and so on – buried under a mountain of time-wasting and pointless trivia.

Here’s what the Scrum Guide says in introducing the Scrum Master role:

“The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”

~ Scrum Guide, 2013 version

But, due to the Universal Scrum Master Failure, the raison d’etre of the Scrum Master role – “…helping those outside the team understand…” is invalidated, and the role degenerates into that of a firefighter, or worse, a kind of dysfunctional Project Manager.

Personally, I find the failures of the Scrum Master role – NOT, I hasten to add, any failures of the folks striving valiantly to make it work, even as it cannot – calls the whole Scrum proposition into question. Combined with Scrum’s inherent failure as a local optimisation, plus the equally dire failings of the Product Owner role (which I won’t go into here) I’d suggest the best thing we can do is to throw Scrum onto the garbage heap of history. By all means pick though its bones for the “good bits” like short iterations, early ship-ability, small batch size, self-organisation, etc. – although none of these are the monopoly of Scrum.

Maybe then we can get back to the core issues we all face:

• “How do we make organisations relying on software development more effective?”
• “How can businesses exploit software development for business success?”
• “How can we better attend to people’s needs through software development?” and
• “What is the core purpose of that thing we so glibly call ‘software development’, anyway”?

– Bob

Afterword

I guess most Scrum Masters who agree with this post might be asking themselves, somewhat resignedly, “Is there anything I can do in my present role to make things even a little better?” Short of giving up on the whole notion of Scrum Master, is there anything that can be salvaged? From personal experience, I’d suggest taking a look at the Universal Scrum Master Failure and see if there’s anything you can do to address or correct that failure in your corner of the world. If it turns out that your present employer has no taste for that, then you’re pretty much wasting your time. And your potential. Life is too short for that.

Further Reading

Developing Scrum Masters ~ Angel Medinilla
The New, New Product Development Game ~ Nonaka and Takeuchi

Workspaces

I just got back from Agile By Example 2014 (Warsaw). One of the many questions folks asked me while I was there was

“What’s the ideal workspace for software development (teams)?”

Conventional wisdom, seeing software development as some kind of office work or even factory work, suggests that developers’ workspaces can simply look like the typical open-plan office. Or maybe the dreaded cube-farm.

More progressive organisations might choose to regard software development as more of a collaborative, creative endeavour, and arrange the workspace more like e.g. a design studio.

In my experience, both both of these, and other, assumptions are fundamentally flawed.

Software development does not benefit from just one kind of workspace. Any single style of workspace does not allow for the variety of different modes of work during a typical day of development working.

Modes

Software development ebbs and flows, more or less smoothly, and unpredictably, from mode to mode and back again, throughout each and every day.

Cave: Sometimes, one or two members of the team may wish to find a quiet, enclosed space to work on a particular issue where concentration, flow, and freedom from distractions are the predominant issues. A typical “cave” would be a small, private, soundproof office with space for a desk or two, a couple of chairs, and with a door that can be closed.

Bullpen: At other times, a subset of the whole team may wish to work together, either on the same thing (like Mob Programming), or on different, but vaguely-related things (like different User Stories of a given product). Here the predominant issues are explicit and incidental sharing of knowledge, status, and other information. A typical bullpen would be an enclosed space with a large desk – seating up to say eight people around its periphery – with room for chairs, desktops and laptop computers, information radiators, etc., and again with a door closing it off from corridors and other nearby spaces.

Lounge: At other times again, some number of the team may wish to relax, chat quietly, and socialise and work in a more informal space. Here, the space is purposed primarily to socialising and relationship-building. A typical lounge would be an enclosed space – again with a door – with sofas, bookshelves, information radiators, and maybe a place to get drinks (water cooler, fridge, coffee machine, kettle, etc.) and snacks.

Riffing on Modes

In a typical working day, members of the team – and their guests – may migrate repeatedly from space to space, as the pattern and rhythm of their day changes and morphs in response to the nature of the work of the moment.

I’d suggest each team (circa eight people) have their own dedicated area comprising caves (two to three in number), bullpen (or two) and lounge.

In organisations with more than one development team, other needs (meetings, eating, play, etc.) can be catered to by shared facilities (meeting rooms, canteen or refectories, recreation rooms, sports facilities, showers, bathrooms, and so on).

And on larger product development endeavours, involving more than one team, I find some arguments in favour of enlarging the workspace and having all the teams share this enlarged space. For example, with three 8-person teams in the same space, we might look to have five or six caves, two or three bullpens, and a common – albeit larger – lounge a.k.a. common room. And intermittent remote working – such as working from home, or God forbid, a client site – can further reduce the floorspace requirements somewhat.

I hear some mutterings at the back about how much this might all cost. All I can say is, do you know the (hidden) costs – in terms of reduced productivity, less employee engagement, morale, etc.) – of your current workplace arrangements?

Until you discover and quantify those, how can you evaluate the cost/benefit of creating workspaces better suited to software development?

– Bob