Monthly Archives: April 2015

The Bees’ Knees

[6 May 2015 Note: The article on Bees’ Quadratic Voting mentioned below has drawn some stinging criticism from a certain Warren D. Smith. Knowing nothing about bees, I have chosen to flag the contention over these ideas.]

When it comes to product development, I have long felt uncomfortable about how most organisations go about choosing which products, and features within products, to prioritise.

The most common approach – HiPPO – and indeed many other approaches, only seem serve the egos of those involved. Rarely does an approach come even close to selecting the most promising product or feature, with respect to the goals, ambitions and yes, shared purpose, of the organisation.

Software and product teams rarely if ever get to choose what they work on. So the key decisions have been made even before the work flows into their remit. Little wonder then the frustrations of such folks, who often find themselves working on stuff in which they have little faith, from a commercial standpoint. And little wonder, too, they these folks find it, ahem, a challenge to feel enthusiastic and committed to their work.

Experiments, MVPs, A/B Testing, Etc.

We have evolved ways to address this issue, mostly centred around the idea of trying things out and seeing what works. This causes me discomfort, too. Not least because in involve some investment in work (sunk costs), and inevitable waste.

And it still doesn’t address the up-front question of just WHAT to experiment on, or try out.

Of course, if your organisation is old-school, then it’ll have specific people – the single, wringable necks – whose job it is to make these kinds of decisions. Product Managers, for example.

Yet some companies are finding that crowdsourcing such decisions, whether using an internal crowd (a.k.. Fellowship), or involving outside folks too, can lead to much more effective decision-making.

Quadratic Voting

This recent article about how bees make decisions points the way to a more effective approach to such crowdsourcing. In essence, we might imagine a prioritisation approach that uses many heads, yet allows for an efficient outcome:

“All type-symmetric Bayes-Nash equilibria of an independent private values Quadratic Voting game converge to an efficient price-taking outcome as the population size grows large.”

~ Steven P. Lalley

Mathematically, Quadratic Voting is the only pricing rule that gives individuals an incentive truthfully to report their preferences.

Maybe you might like to experiment with using Quadratic Voting (QV) in how your organisation decides which product and feature to work on next? Or, God Forbid, if you’re attending to folks’ needs, then QV may help you all agree on which needs come first.

And maybe it’s a perfect complement to the Advice Process as seen and reported by Frederic Laloux?

– Bob

Further Reading

The Principles Of Product Development Flow ~ Donald “The Don” Reinertsen

I Am Your Therapist


In case you found my previous post too negative.

Note: the “you” and “your” in this post mostly refers to the organisation a.k.a. workplace, working community, within which individuals play their parts.

I am your therapist when you ask me.

I find joy in attending to folks’ needs. When you need me as a therapist, I will likely find much joy in the role.

I am your therapist for as long as we both feel we’re attending to our needs.

Our connection, should we both choose to form one, must of necessity be a mutual one. Whereas our focus at the outset may be on the needs of the organisation, we will likely find joy in attending to the needs of others, too, such as employees, managers, shareholders, customers, suppliers, and wider society. And even my own needs as your therapist.

I am your therapist on those occasions when you choose to play an active role.

Whenever you’re energised and involved in attending to your needs, and addressing your issues, I’ll be there.

I am your organisation’s therapist.

As an organisational therapist, I work with the organisational psyche. If you believe that the organisations psyche – or mindset – has any influence over the organisation, how it works, and its relative success or failure, then you may begin to see the value of having someone attend to it. As we work together, you may come to see this more clearly.

– Bob

Further Reading

The Advantage ~ Patrick Lencioni

I Am Not Your Therapist


Note: the “you” and “your” in this post mostly refers to the organisation a.k.a. workplace, working community, within which individuals play their parts.

I am not your therapist until you ask me. 

Until you request my involvement, our relationship is one of acquaintance, rather than one of connection and working together on your issues.

I am not your therapist until I agree to take on the role.

Our connection, should we both choose to form one, must of necessity be a mutual one.

I am not your therapist until you choose to play an active role.

Whilst you may feel uncertain, passive, even catatonic at the outset, absent your willingness to help yourself, we will not make progress.

I am not your therapist when you feel you don’t need me. 

There will be times when, for a multitude of reasons, our connection and its potential fruits have little attraction for you. At those times I can be patient, until you review your choice, and choose to feel I have something to offer.

I am not your therapist.

As an organisational therapist, I don’t work with individuals. Not you. Not any one. If you have personal issues, I might be able to refer you to someone who may be able to help. You might say that as an organisational psychotherapist I work in the spaces between people. Like gardeners work on the soil between plants.

I am not your therapist.

There’s nothing “wrong” with you, so you don’t need a doctor. Maybe you could use a friend. Maybe we could become friends. That might help us both.

I am not your therapist, you are.

There’s nothing I’m going to “do” to you. Any changes you wish to see ultimately come from yourself. Everything done to you will come from you.

– Bob

Further Reading

The Organisation’s Therapy Experience ~ FlowchainSensei
The Organisational Therapist’s Experience~ FlowchainSensei
Individual vs Organisational Psychotherapy ~ FlowchainSensei

Microservices In Embedded Systems

I don’t write many “technical” posts, finding people and organisations more challenging, and hence more interesting, but this is one. If you like the diversion, let me know and I’d be happy to write some more such posts.

Some years back I was running a boutique embedded systems development company, in partnership with a hardware engineer. He’d design and build the hardware – micro-controller based – and I’d implement the core functionality in software. Mostly in C, C++ or Python, with some e.g. PIC assembler here and there. OSes were Linux, WindowsCE, or naked. Approach was entirely Agile (on both the hardware and software fronts).

We specialised in hyperconnected devices – now more widely known as the Internet of Things – so every device we designed centred around an embedded web (HTTP) server.

One particular project – at the higher end of micro-controller capabilities, with virtual memory addressing and a fairly beefy CPU – was an event logging device with e.g. remote access (dial-in or ethernet) capabilities, a touch panel for local admin, and a bunch of digital I/O lines for scanning the connected devices to be logged.

I chose Python as the prime option for the implementation, with Javascript and CSS for the touch UI, some C for low-level hardware (device driver) functions, and Json for initial device configuration a.k.a. policies.

Once I had a Python implementation that would run on the platform, I gave some thought, as I was writing some early code, to a suitable architecture. I knew the client had a vague interest in extending the range of product variants in the future, as well as possibly adding more features, so although not a priority, extensibility was at the back of my mind.

Aside: Another reason for Python being the favoured implementation language was the excellent CherryPy webserver package, which I had used often before. Unfortunately, it turned out that CherryPy wouldn’t run on the platform (WindowsCE), and tight schedules did not permit an investigation as to why. So I went with a basic SimpleHTTPServer implementation instead.

More pressing, in terms of getting the whole thing working, was the memory usage of each Python process. And the relative shortage of memory on the device (suggested by the economics of the design). This consideration was paramount, it turned out, and a good deal of the work was a consequence of shoe-horning the necessary functionality into the memory space of the device.

Eventually, the architecture evolved into circa a dozen separate, cooperating Python processes. (Note: I stuck with Python, because actually implementing the necessary functionality in Python was much quicker and less painful than doing the same in e.g. C or assembler).

In retrospect, today we might choose to call this a microservice architecture. Each Python process ran independently of the others, doing its small bit, and interacting with one or more of the other services as and when necessary.

The microservices included:

  • Watchdog
  • MCP
  • Networking
  • TimeWarden
  • MediaWarden
  • EventScanning
  • EventLogging
  • Webserver
  • RemoteCommandListener
  • SyncSource
  • DeviceStatus

Aside: Actually, there were rather more microservices than this originally, but I had to combine some in order to meet the memory constraints.

At the end of the project, it was clear (to me, not to anyone else) that, serendipitously, the architecture was such that adding new features, even whole new microservices, would be a piece of cake. I’m not aware that this was ever appreciated, let alone acted upon (no one else involved was at all software savvy).

Have you worked in embedded systems development? Have you ever seen or considered the pros (and cons) of a microservices-style architectural approach?

– Bob

Further Reading

Stop Thinking About User Interface ~ Juan José Ramírez
Windows CE: Synchronization Objects – Events ~ Bruce Eitman

What’s In It For Me?

The general election is all but over here in the UK. It’s been marked, as usual, by incredible promises and naked appeals to self-interest from the major parties, and incredulity and apathy from the electorate.

It seems the political elites have a profoundly Theory-X view of the voters. According to the political rhetoric, everybody is out for themselves, venal egotists. Everybody is assumed to want more money, less time working, more pandering to their biases, and an easier life in general. Psychiatrists call this projection.

Whilst I can believe that many in politics are all out for themselves, I daily see evidence that people in general are much more social. Much more interested in what’s in it for other people. Much more concerned for the communities in which they play a part.

But this isn’t a post about the election. It’s a post about how the workplace – and the way the work works – often places people in situations where they feel they need to look out for themselves, rather than follow their natural, human inclination of looking out for others, too. I’m pretty sure if we had a different political system, one which encouraged politicians to attends to folks’ needs, rather than their own, we’d see a different kind of politician, a different kind of politics, and an electorate much more engaged with the whole process.

And isn’t that what we’d like to see in the workplace? A different climate, where people engage willingly with each other and their common challenges, and look out for each other in getting things done?

And just like in politics, I see little prospect of things changing markedly any time soon. But, just like in politics, we don’t have to play “their” game. (Although it’s not their game so much, as the game imposed by the system).

Would you be willing to take up my invitation to consider how you could change you workplace for the better by bucking the system and giving others, and their needs, even a just little extra consideration?

– Bob

How to Develop Software – And Why Most Organisations Can’t

There’s a simple recipe for developing cool, awesome, high quality, cost-effective and just plain sexy software. Most developers know this recipe. Most organisations do not.

How To

Get a (small) bunch of people who enjoy working together, who choose to work together, who choose what they’re working on and the scope of that work, who choose their own tools (if any) and equipment, who love what they do (and why they do it / who they do it for), and who have the autonomy to figure out how they can work best together, in the longer term. Offer them them some difficult (but not impossible) challenges and provide them with the wherewithal* to get on with it. Invite them to deliver working stuff (into production) frequently, and make sure the rest of your organisation knows that everyone benefits from immediate and meaningful feedback each time they do that.

(*By wherewithal I mean information, money, connections, someplace to work, and support).

Why Most Organisations Can’t

Most organisations cannot do this. They cannot attract the kind of people who can and want to work this way. Even if they could, they cannot trust these people to just get on with it. Even when seeing demonstrable progress every week or two. They cannot tolerate the absence of any “management” roles, whether this be overt (e.g. line managers, project managers), or covert (Product Owners, Scrum Masters, et al.). They cannot tolerate people “doing stuff” that they don’t understand, in ways they don’t understand. They cannot reliably give immediate and meaningful feedback. Above all, they cannot tolerate people having fun. After all, work is a serious matter, and results count for much less than how they’re arrived at.

Bonus Tip 1 – What To Do When Your Organisation Can’t

Make your organisation one that can. One that can attract the kind of people who can and want to work this way. One that can trust people to just get on with it. One that can tolerate the absence of any “management” roles – rejoice, even. One that can tolerate people “doing stuff” that they don’t understand, in ways they don’t understand. One that can reliably give immediate and meaningful feedback. Above all, one that can tolerate people having fun. After all, work is a serious matter, and results count for much more than how they’re arrived at.

Bonus Tip 2 – How To Scale

If you have more than one piece of software on which you want to see progress at the same time, get two, three, or a hundred more (small) bunches of people. Ensure they have the wherewithal (including a common purpose). And let them figure it out as they go. Most organisations can’t do this, either.

– Bob

Agile Competency Is A Crock


Part 1 – The Lede

The Agile Manifesto set out to make developers’ (and others’) live richer, saner and more fulfilling.

A true irony of the legacy of that Manifesto is that finding a fulfilling job or role “in Agile” is nowadays next to impossible.

Competency is not something valued by hirers and their gatekeepers. Being a “safe hire” is all.

Part 2 – The Background Story

My dear friend, the late Grant Rule, had many compelling stories to tell.

One of these concerned a large insurance company in the home counties. Let’s call them InsCo. For some reason, the powers that be became interested in the reasons why they were not doing as well as they thought they should be, business-wise.

Some number of investigations were commissioned. One concerned the type of people they were hiring, versus the type of people needed for business success.

To cut a long story short, it became revealed to them that not only were they hiring people with little to contribute in the way of the organisation’s business goals, they were actually hiring people whose general style actively undermined those goals.

In other words, their hiring practices were expressly filtering out those people best suited to make a positive contribution inside the business. And this had been going on for years, if not decades.

I always found the story fascinating, not least for its compelling ring of truth.

In todays’s business world, I see many of the organisation I visit or work with making exactly the same error.

Organisations whose hiring practices filter OUT exactly those candidates who would best contribute to the espoused goals of the organisation.

Guided by the heuristic of POSIWID, I assume that organisations – or more exactly the core group within an organisation – are not much interested in the organisation’s espoused goals. Deming said as much fifty years ago, with his First Theorem:

“Nobody gives a hoot about profit”

~ W Edwards Deming

I find this particularly noticeable in hiring for so-calle Agile positions and roles. […]

Now, I’m not about to criticise folks – senior executives and middle managers in this case – for acting in their own individual and collective (core group) best interests.

It’s what humans do – acting to get needs met.

I’m just inviting you, like the executives at InsCo did, to take a look at the consequences of your current hiring and staffing policies and processes.

And consider how those staffing policies and processes play against the things that matter to you.

Oh, and maybe consider what those things that matter to you are, too.

Part 3 – The Dilemma

For me, struggling as I am to find gainful and meaningful employment, the questions aired in part 2 raise an interesting question for all of us in the Agile field:

Do we concentrate on appearing competent, and on our abilities to help the organisation achieve its espoused goals? Or do we focus on getting a well-paid job – which demands a very different strategy and “personal brand image”?

The former strategy suggests we list our experience, results and contributions to the success of the organisations we have worked with. That we take hiring organisations’ espoused goals at face value and play to those declared goals.

The latter strategy suggests we present ourselves in terms that appeal to the needs we imagine the hirers – and their gatekeepers – have.

Needs rarely articulated and only determinable through observation of these folks’ actions. Needs which in most cases means portraying ourselves as conventional, conservative, and status-quo loving. As “safe hires”.

I’ve discovered – unsurprisingly, to me – that I just CAN’T bring myself to do the latter.

I’m NOT a safe hire, not do I ever wish to be. My value proposition is other.

Outwith the emotional consequences of pretending to be something I’m not, and setting myself up at work to live a life that’s a bald-faced lie, I just don’t want to find myself in any more jobs or roles that, in essence, are just another stupid punt.

How about you?

– Bob

%d bloggers like this: