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