Archive

General

Reflective Questions

At this time of year, it seems customary to take a moment to reflect on things. As an aid, please allow me to invite you to reflect on some or all of the following questions, either by yourself or in the company of others:

  • How relevant has joy (and flourishing) been in your life in the past year? Is that something for just yourself, for your loved ones, or for folks more widely?
  • What was the biggest source of joy in your life in the past year? Does that suggest any kind of change of focus from where you choose to focus you attentions presently?
  • Who matters to you (including yourself)? And how much are you in touch with these folks’ needs?
  • How often in the past year have you made some kind of (refusable) request of people around you in the pursuit of getting some of your needs met? Did you feel able to explain your needs in any detail?
  • What groups and/or communities have you felt an affinity for? How in touch are you with the collective needs of these groups or communities? Are you moved to attend to those needs?
  • Can you recall any specific instances where you were the victim or perpetrator of violence (in the broadest sense)? How did that make you feel? Did the violence achieve its intended result? Were there consequences?
  • Can you recall any occasions in the past year where you felt some special or peculiar empathy with other(s)? Did you have the opportunity to express or share that feeling with anyone?
  • In the past year, how often have you really talked (spoken openly and listened fiercely) with others?
  • Did you experience any epiphanies in the past year?
  • Do you feel you found some answers to questions that have long been nagging at you, in this past year?
  • What part has spirituality played in your life this past year? Do you imagine you’d be happier with more (or less) spirituality in your life in the future?
  • Do you recall occasions in the past year where you’ve acted from the heart, out of non-judgemental (and non-romantic) love? How did that go?

I wonder how you respond to these questions – I’d love to hear about those responses.

– Bob

The Aspiration Gap

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

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

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

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

The green curve is the topic of this post.

The Green Curve

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

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

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

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

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

Summary

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

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

– Bob

Footnote

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

 

Obduracy

I tweeted recently:

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

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

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

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

– Bob

What is Expertise?

Hiring an expert is a pretty much everyday occurrence. There’s accountants and lawyers, bankers and insurers, butchers and burger flippers, gardeners and mechanics. Sometimes we hire people not for their expertise, but simply to save us time, for example dog walkers or housekeepers.

For those folks we hire for their expertise, what does that actually mean? In the Antimatter frame, we might choose to say that experts possess – and can apply – more effective strategies for getting (some of) our needs met than we possess ourselves.

We’d not often tell our accountant how to calculate our tax liabilities. Nor our lawyer how to prepare and present our legal case. That’s because, with their more effective strategies, they’re likely to achieve a more effective outcome than we, with our relatively ineffective strategies, could. So we’re more likely to see our needs (in the round) get met.

Where’s this Going, You Might be Asking

Well, let’s turn our attention to hiring people – be that employees, contractors or consultants. Sometimes we’ll hire people to save us time. We could do the job that we’re hiring them to do, but we have more valuable things we can be spending our time on, so we hire them to do the less valuable things.

But sometimes, we’ll hire folks for their expertise. There’s some needs for which we accept our own strategies for getting those needs met are relatively ineffective. Like, running a software team or department, for example. So we find someone who appears to possess – and can apply – relatively more effective strategies.

So far, so good. If we choose our experts well, we’ll see our needs met more effectively – sometimes very much more effectively – than if we chose to attempt to meet those needs ourselves.

However. What happens when the effective strategies employed by our experts seem inexplicable to us? When we just can’t understand how applying their preferred strategies can achieve getting our needs met? We rarely quiz our accountants and bankers on their strategies. But we do quiz our new hires. As if we’d understand.

The Credibility Barrier

We have crashed headlong into the “credibility barrier”. Where it’s our own incredulity that blocks us from hiring those very folks possessing the most effective strategies for getting our needs met. And the most likely outcome being, we’ll reject the expert and their expertise, rather than recalibrate our assumptions and beliefs about what’s credible.

– Bob

What is “Working Software”?

We have for decades now been informed by the Agile Manifesto, and its four guidelines. Guideline number two is “working software over comprehensive documentation”. I’m sure many folks skip over this with no more than a quick nod of agreement (and a implicit interpreting of “comprehensive documentation” as “reams of useless documentation”).

But what exactly do we mean by “working software”? A quick trawl through the Internet finds little in the way of a definition of this term, nor any explicit explanations of the why – the value – of “working software”.

For me, working software is simply any software that is actively being used by customers (a.k.a. users) in their real jobs. Until and unless it’s actually being used for the core purpose for which it was built, no one will be any the wiser as to its fitness for purpose.

Who Benefits from “Working Software”?

Developers

Developers get to understand how close they came to understanding the customers’ needs. Assuming, of course, that the feedback loop from customs to developers is a closed loop, rather than having no feedback from customers, or any feedback that is provided falling into a hole or getting hopeless garbled somewhere along the line from customers to developers. In the latter case working software is a pretty useless and ultimately frustrating concept.

Customers

Customers get to apply the software in the context it was intended. By which I mean their using it to help them be more successful (whatever that might mean in any individual case). They’re reassured that the developers are attending to their needs (although not necessarily fully meeting them). By applying the software in their work context, they get to see its true nature and fit. And they get to tell their story, or at least a part of it. Folks find telling their stories cathartic (assuming they’re being listened-to).

The Producers

The producers (the company supplying/building the software) get to exercise their channels to and from the market, and to and from active users. Shortfalls in the clear communication of needs (customers -> developers), smooth deployments (company -> customers) and clear communication of feedback (customers -> developers) can be identified and addressed. In principle, anyways.

Other Benefits

“Working software” as defined above, promises other benefits, above and beyond those already mentioned.These additional benefits  include:

  • Provides a definitive and unambiguous definition of what has been shipped/deployed, in a way that written requirements or documentation (one of the forms of documentation mentioned in the aforementioned Agile Manifesto guideline) simply cannot.
  • Promotes interaction and collaboration. Not just via feedback on the final version, but all the way through the evolution of the product or service under development. (Assuming the product or service deployed is capable of supporting real users in real work).
  • Early & regular delivery of value:
    Value to the customer / user (the growing utility of the product or service, as it evolves through numerous deployments and instances of real use).
    Value to the producers (assuming the producers get paid for each deployment + live use).
    Value to the developers (kudos and the joy inherent in materially attending to folks’ needs).
  • Flow (assuming iterative deployments + live use).
  • The Check phase of PDCA (hypothesise -> experiment -> compare proposed results with actual results -> draw conclusions )
  • A valuable measure of progress (“how well are we contributing to the success of our customers?”)

What “Working Software” is Not

It’s not:

  • “works on my machine”
  • “passes the test suite”
  • “runs in the test environment”
  • “runs in production”

None of these provide the acid test of real users doing real work with the thing.

Proviso

As with most things Agile, the label “working software” misleads as much as it helps. I’d propose renaming it to e.g. “deployed product or service” but that horse is already out of the stables and far over the hills. “Working” is ambiguous, and “software” omits mention of all the other elements of the deployed product or service necessary to put it to real use (user guides, release notes, other documentation, training, support, etc.).

– Bob

Further Reading

Online Experimentation at Microsoft ~ Ronny Kohavi et al.

Stainless Steel Rats

From time to time I step back from the frontline of better software, and write a post trying to put things in a broader context. This is one of those posts.

Managers Don’t Want Software

Managers in companies making and selling products and services don’t want software. It’s a PITA to manage, costly, and troublesome. If someone came along and showed them how to get along without software, most would jump at the chance without a moment’s hesitation. (But one of the many reasons for my support for #NoSoftware, btw). The perceived link from software to revenues is tenuous at best. And most managers don’t even give a hoot about revenues or profits. The way the world of work works encourages us all to satisfy our own personal egos, pockets, and other needs.

Companies Don’t Want Long Term

Senior managers and executives are under all kinds of pressure to deliver short terms results. Shareholders and the markets are largely aligned to short-term wins.  And all have little incentive to take a longer-term view. Most KPIs and OKRs focus on the next quarter or year. Getting good at anything seems like a distraction from “making the numbers”. Getting good at tricky, complicated and complex things like software development holds even less appeal. Most senior folks don’t expect to be in post beyond a couple of years, and most expect their present companies to live short, frenetic lives. (The numbers on that largely reinforce that expectation).

Customers Don’t Want Software

They want their needs attended-to – and, preferably, met. The great majority couldn’t give a rat’s arse whether software is involved in that or not. And given the pain they perceive as arising from the software components of many commercial services they have to use, they’d like to see the back of software, too.

Our Bubble

We practitioners live in a software bubble, imagining that the world sees software like we do. Shiny, glitzy, awesome, useful, cool. This just ain’t so. And for the conscientious practitioners, there’s the need to master our trade / craft / profession / discipline. No one else needs us to do this. And few outside the bubble are interested in indulging us in seeing that need met.

The Bottom Line

It’s my considered opinion that software development, “broken” for the past fifty years, remains just as broken today – because almost no one needs it to be any better. What to do then? Is there no hope for us conscientious practitioners?

Little hope, I’d say, excepting doggedly pursuing our dreams of a better world. Finding joy where we can, like stainless steel rats in the wainscoting of business and society. Banding together for mutual support. Seizing each fleeting opportunity to see our needs for better ways of working attended-to, if not always met.

And talking with people outside the bubble. Listening to them. Trying to understand their needs. And seeing if there’s any chance of alignment between what they each need, and our own dreams.

– Bob

Not Obviously Wrong

What’s obviously wrong in software and product development? The list is continually changing, but here’s some stuff which was not obviously wrong ten or twenty years ago, which has recently become obviously wrong, at least to many people in the world of software development:

Obviously Wrong

  • Big batches and queues of work (aka Waterfall)
  • Utilisation (i.e. keeping resources fully busy)
  • Ignoring stakeholders (a.k.a. The Folks That Matter™)
  • Big Design Up Front (BDUF) (a.k.a. long feedback loops, or none at all)
  • Violence in the workplace
  • The daily commute

And here’s a list of stuff which has not (yet) attained the status of “obviously wrong” – and so appears in the list labelled “Not Obviously Wrong”:

Not Obviously Wrong

  • Estimating (see: #NoEstimates)
  • Management
  • Command and control
  • Telling (ordering) people what to do
  • Leadership
  • Specialisation
  • Cost accounting
  • Projects (see: #NoProjects)
  • Big developments in big chunks with big groups of people
  • Ignoring the costs of delays
  • Testing (a.k.a. inspection)
  • Demanding compliance to defined ways of doing things (a.k.a. process dogma)
  • Separating ownership of the way the work works from the people that do the work
  • Agile
  • SAFe
  • Scrum
  • Kanban Method
  • Ignoring the Cost of (misconceived) Focus
  • Work (as contrasted with e.g. Serious Play)
  • Open plan offices
  • Local optimisations
  • Dress codes (suits, ties, etc.)
  • etc.

How do items get to move from the one list to the other? (note: everyone has their own two lists, and each item moves at different times for different folks). How do your two lists look, at the moment?

Unlearning

Looking at this another way, the obviously wrong list above has items that, although once not obviously wrong, now appear on many folks’ obviously wrong list, having made the transition through e.g. a process of reflection, evaluation, discussion and above all UNLEARNING.

No Hashtags

FWIW, it occurs to me that we might choose to regard the raft of #No… hashtags on Twitter as opportunities to consider in which of our own – and others’ – lists the related (hashtagged) topic appears.

– Bob

%d bloggers like this: