Archive

Monthly Archives: May 2018

The Future of Coding Environments

How would Scotty or Geordie go about writing code for the Enterprise? Would they write code at all? Would they just interact with the Computer via speech or holodeck, or would a keyboard of some sort still have a place? 

In any case, my interests have always stretched beyond matters of organisational effectiveness, beyond matters of human and humane relationships, and beyond matters of how the work of software and product development might better work.

One of my other abiding interests has been the nature of programming. Indeed I spent more than two years, decades ago, on conceiving, designing and implementing a proof of concept for the kind of development environment I’d like to use myself, when writing code. At the time, the work was codenamed “Simplicity”.

My core feature set / wish list includes: 

  • Editing source code directly in the AST, rather than editing source code in text files
  • Direct and incremental compilation of source code as it’s being entered
  • Multiple coders editing in the same AST concurrently
  • Live editing of the AST “in production” (with appropriate safeguards built-in)
  • One homogenous AST for each entire (live production) system
  • Source code control / version control features built right in (and automated away from distracting the coders)

OK, so this may not be the kind of development environment Scotty or Geordie would recognise. But it’s a world away from all the crap we have to put up with today.

Blockers

So why don’t we see more movement towards the emergence of some of these features in our development environments today? In a word: conservatism. Developers en masse seem disinclined – or unable – to look anew at their tools, and dream.

“The future is a foreign country; they do things differently there.”

– Bob

Further Reading

The Mjølner Environment ~ Görel Hedin, Boris Magnusson

 

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
  • Big Design Up Front (BDUF)
  • 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
  • Management
  • Command and control
  • Telling (ordering) people what to do
  • Leadership
  • Specialisation
  • Cost accounting
  • Projects
  • Big developments in big chunks with big groups of people
  • Ignoring the costs of delays
  • Testing
  • Demanding compliance to defined ways of doing things
  • Separating ownership of the way the work works from the people that do the work
  • Agile
  • SAFe
  • Scrum
  • Kanban Method
  • Work
  • 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

Product Owners Suck

Teams doing Scrum “by the book” will have a Product Owner. The Scrum Handbook describes this role thusly:

“The Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

It goes on to say:

“The Product Owner is the sole person responsible for managing the Product Backlog.”

i.e. the Single Wringable Neck.

Outwith Scrum “by the book”, many teams, Scrum or otherwise, will find themselves with a Product Owner, almost always, in practice, outside the immediate development team itself.

One characteristic common to every Product Owner role I have ever seen has been “push”. The Product Owner pushes work (features, stories, or whatever the unit of backlog) into the backlog, and thus onto the team. The Product Owner generally dictates the priorities of the work items in the backlog, too.

Here’s where the dysfunctions creep in. If we accept that we’d like to encourage intrinsic motivation in the team, and that Dan Pink’s three factors of intrinsic motivation apply (Autonomy, Mastery, and Purpose), then we begin to see how the typical Product Owner stance sucks the motivation away from the team by undermining their autonomy (they’re expected to do what’s pushed on them, with the priorities dictated), their mastery (focus is on delivery not learning), and purpose (the purpose is that of the PO, often opaque or little shared, not a shared common purpose across everyone involved).

Go Pull

I’ve seen clients where this push-oriented Product Owner role has served no one well. Not the Product Owner, nor the development team, nor the product, nor the customers. The Product Owner is worn to a frazzle trying to herd the developers, like cats, towards the outcomes he or she thinks the customers want. It’s most unlikely the Product Owner will know what features are valuable, and how they should work, before stuff gets in front of the customers anyway, and the delays in the “push” model just exacerbate this dysfunction.

Further, in the push model, developers have little opportunity to experiment and innovate. They’re often far better placed than the Product Owner or even the customers to spot opportunities for breakthrough innovations, both large and small, yet the push model basically precludes them from contributing in this way.

So why not turn it around? In my career, I’ve seen all the best products come from development teams that directly own the product. And, consequently, directly own the relationship with the customer. Often, not the whole team, as this might irk the customers – at Familiar we had one member of the development team act as “customer liaison” – a role which could rotate between team members if it started to become a chore for the person in question.

It’s unlikely the Product Owner will wish to do themselves out of a job, so how can we arrange things such that everyone has a better time than with the “push” model? And so we make even better use of the most valuable things the Product Owner has – product domain expertise and customer nous?

In the service (call centre, etc.) sector, Vanguard introduced the idea of front-line call staff taking all the calls, with limited (brief) training to handle the most common types of call, and with experts and specialists on hand to help them through handling the less common types of call as they arrive.

Transferring this idea to the Product Owner role, why not have the development team own the product, take all the decisions about features, stories and priorities – by pulling information from the customers – and whenever the development team has some questions they can’t answer themselves or in conjunction with the customers, have the Product Owner (now Product Domain Specialist or some such renamed role) on hand to pitch in and provide the missing knowledge or expertise.

I guess the Analytic minded organisations out there will feel uneasy about no longer having their hands around the Single Wringable Neck, but learning about Team Accountability might go some way to compensate for this?

So, let the teams suck (pull), instead of having the Product Owner push.

– Bob

PS Note that the above suggestion – to hand over core elements of the Product Owner role to the development team – assumes the development team owns the scope for the whole product, not just the software, and can collaborate and coordinate with other people and groups to ensure the whole product is delivered (whether incrementally for not). See also: Obeya.

Further Reading

The Transformation of O2 – A Vanguard Case Study in Reengineering Call Centres (pdf)

Testbash Dublin and Organisational Psychotherapy

As I mentioned in my previous post, I’m just back from presenting an interactive session on Organisational Psychotherapy at Testbash Dublin. Some folks seemed confused as to the relevance of Organisational Psychotherapy to testers and the world of testing, so I’m happy to explain the connection as I see it. (And please note that many of my previous posts on Organisational Psychotherapy may also help to illuminate this connection.)

I’ll start by riffing on something Rob Meaney said during his presentation:

“Significant quality improvements [aren’t] driven by testing. They [are] driven by building relationships and influencing the right people at the right time.” ~ @RobMeaney #TestBash

Quality (and other) improvements come from improved relationships. This has been a theme on this blog for some years now. For example see: The Power of Humane Relationships.

I asked a key (for me) question during my session (several times):

“If we accept that (as per the Marshall Model) it’s the collective mindset of the organisation that determines its relative effectiveness, how do we propose to support the organisation if and when it choses to do something about its mindset?”

Unsurprisingly perhaps, I heard no answers, excepting my own proposal for a means to that end: Organisational Psychotherapy.

I wonder how many folks involved with testing ask themselves and their peers the question “How can our organisation become more effective at testing?”. Or, using the #NoTesting frame, “How can our organisation become more effective at delivering quality products and services?”

Fellowship

Organisational Psychotherapy is not just about improving product quality, however. Through improved relationships, and a shift in how the organisation relates to its people (i.e. from Theory-X to Theory-Y), the quality of life at work also improves. Put another way, we all have more fun, more job satisfaction, and get to realise more of our potential at work. Further, for all the folks that matter, their several needs get better met. And, as a bonus for the organisation itself, it gets to see its people more productive and engaged. What’s not to like?

Incidentally

I’ve also written elsewhere about using the Antimatter Principle in practical ways during software development. For example, during development we eschew requirements gathering in favour of incrementally elaborating hypotheses about the needs of all the folks that matter, and then conducting experiments to explore those needs. I can envisage teams that still need testers adopting a needs-focused approach to driving testing. For example, putting into place various means by which to answer the question “how well does our product meet the needs of the people that matter to us?”.

Practical Applications

On a related note, some folks asked me about practical applications of Organisational Psychotherapy in their day-to-day work as testers. Here’s just a few applications which immediately come to mind:

  • Improving communication with the people that matter (i.e. developers, fellow testers, management, stakeholders, customers, etc.). I find NVC (nonviolent communication) skills and practice particularly useful in this context.
  • Clarifying what works and thus what to do more of (Cf Solutions Focus). This can improve team retrospectives.
  • Helping the people that matter (including ourselves) feel better about what we’re doing (Cf. Positive Psychology).
  • Understanding each other’s strengths, with a view to having the right people in the right seats on the bus (Cf. StrengthsFinder).
  • Eliciting requirements (if you still do that) (Cf Clean Language).
  • Building a community (such as a Testing CoP or a multi-skilled self-organising product team) (Cf Satir Family Therapy).
  • Improved cooperation with higher-ups (empathy, Transactional Analysis, etc.).
  • Dealing with blockers to changing/improving the way the work works.

Invitation

I’d love to hear if this post has helped put my recent Testbash session in context.

– Bob

Testbash Dublin

I’m just back from presenting an interactive session at Testbash Dublin. I enjoyed conversations on the topic of the session – Organisational Psychotherapy – as well as conversations around e.g. #NoTesting. Indeed, I noted a common theme running through many of the sessions from the more seasoned testers presenting: a grumbling low-key disaffection with the notion of testing as a path to quality.

No Testing

A number of folks engaged me in trying to better understand what I might mean by #NoTesting. Such conversations generally start out with “What do you mean by ‘testing’?”. My time in Dublin has allowed me to see through my discomfort in avoiding this question (yes, I generally choose to avoid it). I’m loath to get into semantic arguments from the get-go. I find they rarely lead to productive mutual exploration of such topics.

The bottom-line, is: It doesn’t matter one iota what I mean by “testing”. Whatever YOU mean by “testing”, that’s what I’m talking about when I mention #NoTesting. It’s an invitation for YOU to pause awhile to consider how life would be different if you stopped doing “testing” (whatever YOU choose to understand by that term) and did something else to address the same ends.

Ends Over Means

There’s an idea from therapy which might help you understand this perspective. In eg Nonviolent Communication (and some other therapies), human motivation is assumed to stem from attempts to get our needs met. That is, our behaviours and actions result from the strategies (means) we choose in order to meet our needs (ends). Any particular strategy affords us a limited palette of behaviours and actions. Aside: Often, we have little or no conscious awareness of either our ends or our chosen means.

“Testing” (whatever YOU choose to understand by that term) is a strategy you (or someone else) has chosen – almost always, implicitly –  for getting your or their needs met. And other folks’ needs, too, in the general case.

There are always other strategies (means, options) for meeting folks’ needs. Yet rarely do these other strategies receive any consideration. Maybe some of these other options offer a way to better meet folks’ needs. How would we ever discover that, without considering them, becoming aware of them, exploring them?

So that’s what I’m talking about with #NoTesting (amongst a raft of #No hashtags) – an invitation and reminder to actively consider whether your default means (strategy) are best serving your ends (needs), whether your first and automatic choice of strategy is the most effective way to attend to your – and other folks’ – needs.

– Bob

Do Nothing That Is Not Play

If we think about it calmly for but a moment, one logical outcome of nonviolence is folks not working for a living, but playing for a living.

Innovation

Many companies seem desperate for “innovation”. Is innovation more like to come about through folks doing what they’re told (“working”) or through playing with things, as they see fit? I posit the latter is far more likely.

And no, this is not some flight of fancy. Do we really embrace wholehearted the set of assumptions labelled by Douglas McGregor as Theory-Y?

Theory-Y assumptions are: (1) physical and mental effort are natural and most people (depending on the work environment) find work to be a source of satisfaction, (2) they generally, on their own motivation, exercise self-control, self-direction, creativity, and ingenuity in pursuit of individual and collective (company) goals, (3) they either seek responsibility or learn to accept it willingly, and that (4) their full potential is not tapped in most organisations.

Could it be that folks’ “full potential is not tapped in most organisations” because they are obliged to “work” rather than play?

Could it be that engagement (and productivity) would take an amazing leap forwards if we invited folks to “play” rather than “work”?

Could you have the courage to experiment to find out for yourself?

Or are we all so in thrall to what Walter Wink calls The Domination System that play as an alternative to work is undiscussable?

– Bob

Further Reading

Serious Play ~ Michael Schrage
The Importance of Play (A Valentine for Marshall Rosenberg, part 2) ~ John Kinyon
What If #7 – No Work ~ Think Different
The Human Side of Enterprise ~ Douglas McGregor
Theories of Motivation ~ Think Different

Change is a Waste of Time

Change is a waste of time. And money. And human potential.

That’s not to say the fruits of change are not sweet, but the cost of those fruits, especially given the way most companies go about change, is egregiously excessive.

Put another way, if we could spend less time, effort, money, management attention etc. on change, the waste would be less. And the fruits more abundant and sweeter.

Despite many saying they want change, few need change. I mean, it’s not like anyone’s job, livelihood, career or self-image depended on it. At least, that’s the perception. And those few who DO need change, are those that seem to be stymied at every turn when trying to introduce it. 

What to do? 

How about we take a leaf out of the Book of Therapy, and simply support the few – the few individuals, the few organisations – that feel the need to change? Maybe their improved wellbeing might then encourage a few others?

– Bob

%d bloggers like this: