Archive

Monthly Archives: April 2015

The Bees’ Knees

April 30, 2015
Agile, Antimatter principle, Fellowship, Organisational effectiveness, Product development, Software development
1 Comment

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 [link updated 22/Apr/2022 to use a Wayback Machine reference] 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

April 28, 2015
Organisational Therapy
Leave a comment

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

April 27, 2015
Organisational Therapy
Leave a comment

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

April 25, 2015
Technical
5 Comments

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?

April 24, 2015
Agile, Antimatter principle, Community, Organisational effectiveness
Leave a comment

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

April 20, 2015
Agile, Buzz, Organisational effectiveness, Quintessence, Software development
2 Comments

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 or invite them to 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 – and maybe customers too – 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 just 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 into 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 embrace 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

Further Reading

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

Agile Competency Is A Crock

April 16, 2015
Agile, Lamentation, Lemons, Recruiting
10 Comments

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

Out Of House FlowChain

April 14, 2015
Agile, Engineering, Flowchain, Organisational effectiveness, Product development, Software development
1 Comment

Out Of House FlowChain

When I conceived of FlowChain, some six years ago now, my immediate context was development shops with their own in-house developers, and other supporting staff.

But it strikes me that with just a few adjustments, it’s also suitable for organisations that sub-contract out most or all of their development projects to third parties.

These adjustments centre around arranging for the various third parties (assuming, in the likely case, that there’s more than one) to each contribute staff to the “Pool” (see diagram). These arrangements include:

Commercial

How will the third parties be paid? Some UK government functions use function points as a measure of “work done”, with a set price for each function point “delivered”. See: Output-based contracts. I can imagine other contractual arrangements, too.

Social

How will the third parties’ staff integrate or form healthy relationships with the in-house commissioning staff (a.k.a. product owners)? Will there be shared spaces? Regular visits to and fro? Some more technical forms of communication (Twitter, chat, video conferencing, etc.)? Remember, each backlog item is sized for two to three people working together for two to three days.

Tooling

Third parties remain free to pull items from the backlog as they see fit (just as with in-house FlowChain), and use their own tools, languages, etc.. I foresee some advantages in having a common code repository, coding and other standards, agree requirements around test suites, and so on.

Delivery Into Production

Maybe the organisation contracting the third parties has its own Ops department. In this case the interface between development (teams, third parties) and Ops would probable best be standardised and agreed (like an API). If the third parties have their own Ops folks, then they can do DevOps in their own space and time, and serve the “production” services – or even micro-services – they each operate, directly to users.

Shared Backlog

For clarity, this variant of Flowchain retains the enterprise-wide backlog, with user stories, improvement stories, etc. being prioritised by some black box (or white box) prioritisation algorithm, committee, manager, or whatever. The only real change is in how the Pool is constituted. Note: I see no particular reason why the general FlowChain principle of “ANY unassigned development folks from the Pool can coalesce around each new top backlog item” cannot stand, here.

There may even be emergent advantages in having e.g. developers from different third parties coming together to collaborate on specific backlog items. How weird would that be? Again, policy would guide folks’ actions here.

Who would “manage” the backlog?  This could be done by a small in-house staff, or itself subcontracted out to one or more third parties. Note: the backlog in FlowChain is largely self-managing, in any case, given an effective prioritisation algorithm or approach.

Flow

Flow (of e.g. software into the hands of those whose needs are being attended to) remains the key objective of the whole approach.

Growing An In-house Capability

For organisations without an in-house development capability, this approach provides a simple(r) path to establishing and growing an in-house development capability. In-house developers can be added, one by one, as and when circumstances (budgets, priorities, etc) allow. These new folks can work alongside – and learn from – third-party staff already used to Pool working, and the balance between in-house and out-of-house staff, skill sets, etc. adjusted dynamically as needs dictate.

Drawbacks

The key drawback I foresee is in the matter of dev-ops integration (DevOps). This could prove more difficult, in the case where developers, etc. are out-of-house and Ops in-house. This seems a special case of the issues of outsourcing and offshoring, generally. But I’m sure a bunch of smart developers and smart ops can work this out, especially with some help and guidance.

– Bob

As Simple As Possible

April 13, 2015
Antimatter principle, Organisational Therapy
Leave a comment

As Simple As Possible

As I have written about and explored the Antimatter Principle over the past two years, I have learned some things about how to explain it. Looking back through the collection of posts, and bearing in mind others’ reactions, I suspect I have done a fair but no way remarkable job of explaining why “attending to folks’ need” is the only thing we need to nurture awesomely effective knowledge-work businesses.

Accessibility

I guess Einstein really was a genius, not only for his ideas, but for the ways in which he made those ideas accessible to the general public. For example, regarding the Theory of Relativity:

“When you sit with a nice girl for two hours you think it’s only a minute. But when you sit on a hot stove for a minute you think it’s two hours. That’s relativity.”

The Antimatter Principle follows a simple line of reasoning:

  • Collaborative knowledge-work always involves humans and social relationships.
  • We find great joy in helping each other in meaningful ways.
  • The effective workplace is one which recognises and works with, rather than against, these facts.
  • Self-strengthening “virtuous circle”: As we experience the joy of helping others, we want to do more.

 When you sit with someone for hours helping them get their needs met, it doesn’t even feel like work. But when you sit working for just a few minutes disconnected from people, relationships and a social purpose, it can feel like eternal damnation. That’s the Antimatter Principle.

– Bob

Further Reading

Social: Why Our Brains Are Wired To Connect ~ Matthew D.Lieberman

Stuck

April 11, 2015
Antimatter principle, Organisational effectiveness, Product development, Rightshifting
1 Comment

Stuck

The world of software development seems stuck. Have you felt that stuckness yourself? The kind of stuckness where we find ourselves experiencing a difficulty and every attempt to get ourselves out of it only serves to maintain or worsen the situation?

This recent blog post by Steve Chapman (courtesy of John Wenger) explains the idea in much detail. In case you don’t have the time to read it in full right now, here’s a summary:

Stuck situations arise through the mishandling of difficulties in a number of different ways:

  • Trying harder from the same mindset that created them
  • Oversimplifying or denying the complex nature of the difficulty
  • Creating utopian oversimplified solutions (a silver bullet)
  • Accidentally creating a stuck paradox by attempting to resolve things from the same level of abstraction that caused the difficulty in the first place

“The world that we have made as a result of the level of thinking we have done thus far creates problems that we cannot solve at the same level as the level we created them at.”

~ Ram Dass

First Order Change

“First order change” attempts to resolve a difficulty from within the frame of that difficulty – an approach that, at best, results in some incremental shift but essentially only leads to more of the same. Software development has been stuck in first order change – with its emphasis on process, standards, technical practices, compliance, etc. – for close to fifty years now.

Second Order Change

“Second order change” is movement or action that attempts to resolve things from outside of the frame of the difficulty. Second order change interventions typically seem counter-intuitive, spontaneous, bizarre and experimental – the opposite of what we might call common sense.

The Antimatter Principle

The Antimatter Principle is an example of second order change. It steps outside the frame of the difficulties and the stuckness of the software industry, and into a different, new frame.

This new frame seems counter-intuitve: how can it possibly make sense to forgo transactional relationships with people and attend to their needs instead? Wouldn’t that just mean we’d be taken for all we have?

It seems spontaneous: attending to folks needs as and when they arise.

It seems bizarre.

It seems experimental. Where’s the proof? The evidence? The data? Why have we not heard of this in practice? Who has been doing this already?

It seems to run counter to common sense.

Typically, (first order change) interventions try harder from the same, outdated and stuck mindset that they are trying to alter, or over-simplify the problem by denying the ongoing, dynamic, complex nature of organisational life.

The Key Question

In his aforementioned post, Steve Chapman asks the key question:

What might a global, second order intervention – to totally transform our approach to change and development – look like? What counter-intuitive and perhaps seemingly nonsensical approaches would need to be bravely adopted? What difficult beliefs would we need to gently let go of in order to challenge stuck habits and experiment with new ideas?

Having studied this question for the best part of the past twenty years, the Antimatter Principle is my answer. And the difficult beliefs we need to let go of are those implicit in the Analytic mindset.

“Our individual and organisational stuckness seems rooted in our habit of trying harder to become something we are not [e.g. cogs in a machine], rather than slowing down and becoming more aware of what we already are [e.g. human beings].”

~ Steve Chapman

– Bob

Further Reading

Is The Antimatter Principle Useful? ~ Ged Byrne

 

 

Agile Consultancies Aren’t

April 9, 2015
Agile, Lamentation, Rant
3 Comments

Agile Consultancies Aren’t

Why not? Well, at the very root is the the Myth of Redemptive Violence, which gives power to both the Domination System within which we as humans are for the most part emprisoned, and to the Analytic Mindset with its anachronistic and oppressive (Theory-X) view of human beings as e.g. cogs in a machine. More specifically, there’s a whole passle of “failure modes” which I’ve seen in numerous self-styled Agile Consultancies:

The Path Of Mammon

  • Consulting teams in name only. Consultancies like to supply teams. Many times, these teams are selected by managers, and run by Project Managers or Account Managers. And from there, it’s managers all the way up (down). Even whilst espousing the benefits of Agile, these consultancies fail to walk the talk.
  • Analytic Mindset. Consultancies, not wishing to look too alien to their largely Analytic-minded client base, and perhaps lacking the imagination to see beyond conventional management models, most often adhere to the hierarchical management models now beginning to look very dated.
  • Theory-X. At the beating heart of Agile lies the Theory-Y disposition. How many Agile consultancies have Theory-Y type relationships with their staffers, as opposed to the more traditional Theory-X stance?
  • Play. Innovation. Creativity. All espoused values of Agile, and all conspicuous by the absence in many consulting engagements, where margins, revenues and milking the client for as much money as possible seem to take precedence. And where things have to be done “by the book”, both by the consultants and the client’s staff they’re supposedly “helping”?
  • Delivering value. This. How many consultancies do you know that offer an unequivocal value-for-money guarantee?
  • Incremental delivery. Another core value of the Agile approach. How often do contracts with clients reflect this? How often do contracts (do you remember “Customer collaboration over contract negotiation?) stipulate fixed terms for the consulting engagement?
  • Agility. How many consultancies do you know that start an engagement with a plan of campaign, or agenda, vs sensing the clients evolving needs and responding to those changing needs as they flex and unfurl?
  • Agile is about human relationships. How many Agile Consultancies do you know that major on that? On building long-term relationships between their company and their clients’ companies? (Much more that just relationships between individual consultants and individuals in the client company). On becoming a trusted parter at the heart of clients’ businesses?

I could go on, but I think I’ve listed the main points of my argument.

Two-Way Street

It’s a two-way street, of course. Agile Consultancies follow the Path of Mammon mostly because that’s what their clients expect, or demand. That’s what many imagine it takes to survive and thrive in a Market for Lemons. It looks risky to buck that demand in favour of another way. But another way there is.

Another Way

There is another way. A way which eschews short-term revenues, and skipping from one unsatisfactory engagement to the next, in favour of helping clients in the longer-term. With non-dogmatic advice and help that attends to the needs of everyone involved, not just the consulting company’s big-wigs. This Other Way is the path I myself have chosen to follow. It’s not as easy nor well-travelled a path as the Path of Mammon. But I find it immeasurably more satisfying, all-in-all.

“Two roads diverged in a wood, and I, I took the one less traveled by, And that has made all the difference.“

~ Robert Frost, The Road Not Taken

– Bob

Further Reading

Joy, Inc. ~ Richard Sheridan Why Familiar Was Europe’s First 100% Agile Software House ~ FlowChainSensei

Dead Wood

April 8, 2015
General, Leadership, Management, Organisational effectiveness, Psychology
Leave a comment

Dead Wood

Much of my work over the past twenty years or so has been informed by the grace and wisdom of Dr. W Edwards Deming, often known as Bill Deming. This post is inspired by the following quote:

“The only reason an organization has dead wood is that management either hired dead wood or it hired live wood and killed it.”

~ Bill Deming

Note: Very similar quotes have been attributed to Peter Scholtes, and indeed the above quote may well be Dr. Deming paraphrasing Peter Scholtes.

Definition

“Dead Wood” here refers to people in a group or organisation who are no longer actively useful – people still drawing salary, etc., but adding little or no value.

Deming’s 95/5

Bill Deming observed that “95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and 5% are attributable to the individual”. If we accept this, then is there even such a thing as dead wood? Maybe there’s just folks trying to do a good job, but frustrated – defeated, even – by the system, the way the work works, and the situations in which they find themselves.

Dead – Or Just Dormant?

I have seen many folks, in various organisations, written-off as “dead wood”. I see this much like “flipping the bozo bit” – many managers seem to believe that “dead wood-edness” is an inherent attribute of individuals. And little or nothing to do with their circumstances or situation. Maybe they have not heard of the Fundamental Attribution Error.

Is dead wood really dead, or are those so labelled just in the wrong jobs, in the wrong teams, in circumstance where they’ve been all but forced to disengage, where they have learned to be helpless?

“There is nothing either good or bad, but thinking makes it so.”

~ William Shakespeare

Maybe you know some “dead wood” in your team, group or organisation. What might it take to bring them back to life, to flourish, to see some green shoots of new growth? Is there anything you could do to help that along?

– Bob

Further Reading

Four Days With Dr Deming ~ William J. Latzko & David M. Saunders
The Leader’s Handbook ~ Dr. Peter R. Scholtes

Twelve Signs Of A Great Agile Evangelist

April 7, 2015
Agile, Antimatter principle, Coaching, Doctrine
5 Comments

Twelve Signs Of A Great Agile Evangelist

1. Don’t Talk About Agile.

The first rule of evangelising Agile is: You do NOT talk about Agile. The only folks who want to hear the word – or the gory details – will be those who are looking for a badge of some kind. Or for bragging rights at the golf club. Or tyre-kickers. Strong prospects will not be interested in the label, or the details, but rather in the fact that you understand and care about their problems (empathy) and have useful – and proven – solutions for them to apply. Some of these useful solutions may involve Agile things. Shhh. For example: Talk about their business issues, and the issues common to their business domain. Telcos might be interested in better customer service, and better customer experiences when using their online services, apps, etc..

2. Know Your Cause

“Doing Agile” is not much of a cause, really. Even “being Agile” doesn’t quite cut it. Why are you enthused by Agile? Personally, I see it as a means to move folks closer to a workplace – and a way of working – that allows those folks to realise more of their potential and get more of their needs met – whilst seeing others’ (customers, suppliers, managers, shareholders) needs better met, too. For example: “Effective agile means people more engaged with their work, more focussed on our customers – and our customers more engaged with our products.”

3. Get down with your motivation

Whatever it is that motivates you, embrace it. People can sense half-heartedness and dilettantism. For example: “We’ve seen major steps forward in happier workers, and organisations which are a joy to work in, and with.”

4. Work With Fertile Soils

Plant your cause’s seeds in fertile minds. With folks that are ready or at least willing to listen. If they think they know what their problems are, and that their existing strategies are good for addressing those problems, don’t waste your – or their – time. There will be a few folks who are either unaware of their problems – these may listen, or aware but dissatisfied with their current strategies (solutions). For example: Engage with new prospects, equipped with a checklist of those things that you believe signify fertile soils. Make it an early priority to gather the information needed to complete the checklist. If a new prospect rates poorly on the checklist, decline their kind offer to take things further.

5. Connect To Folks’ Needs

Make your cause relevant and specific to individuals and their existing needs. Help them see how your cause is a more effective strategy for them than their existing ways of working, and thinking. Of course, to connect with folks’ needs, you’ll have to attend to (explore) those needs. For example: Ask your contacts in the organisation what they need. Enquire as to whether there might be others they could suggest with whom you might have similar conversations. Discuss how new ways of working might address some of their needs, individually and collectively.

6. Supply Metastrategies

Many folks need help in acquiring a suitable metastrategy or two before they can move on from their existing strategies and adopt the one(s) you are proposing.

7. Be Honest About The Pitfalls

In many sales situations, standard advice is to avoid talking about the negatives. In Agile adoptions, avoiding mention of the pitfalls only sets up the client for failure. As DeMarco and Lister said in Waltzing With Bears “Risk Management is Project Management for grown-ups”. Maybe your audience has few to no adults? Then RUN! For example: Talk about the rates of failure (generally estimated at somewhere between 50% and 95%). Talk about the common failure modes (faux agile, management discomfort and resistance, change fatigue, organisational cognitive dissonance, etc.). And talk about some possible mitigations for those common modes.

8. Talk About The Benefits

What are the benefits? Not the old chestnuts of “faster, cheaper, quicker”. But benefits that directly address their own particular specific pain point(s). For example: “I understand your biggest competitor can add major new features to their flagship product in six weeks or less. With the necessary changes, we believe that your team could do the same, in timescales as short as two weeks.” In my post “Pitching Agile” I describe using The Three Box Monty as a sales tool in “selling agile” to executives.

9. Make The First (Or Next) Step A Small One

The Kanban Method, for example, cunningly says “start where you are”. Although this begs the question – where else could one start? In any case, engage the prospective client in discussing options and help them come up with their own way forward. For example: Visualisation (of a part of the current workflow) or explicitly limiting work-in-progress (recognising current implicit limits) might be places to start.

10. Don’t Try To Motivate People

Rah-rah motivational speeches and miraculous stories are best left for the God Squad. They have an audience that responds to that kind of thing. Use empathy rather that motivation.

11. Be Organised

Wow. Really? Not “appear well-organised” But actually be well-organised. For example: Have standard templates, checklists, and other documents and planning tools ready and to hand for each new prospect. Keep track of contacts, needs, dates, conversations, and so on. Again, clients and prospects can tell when you’re organised.

12. Be Humble

Don’t proselytise dogma. Don’t make grandiose claims. Don’t make any claims at all. Not even when you have ironclad evidence. Evidence rarely sways anyone. Great evangelists connect with people, and their existing needs. If what you’re selling isn’t what they need, then smile, wish them well, and move on.

– Bob

Further Reading

The Art Of The Start ~ Guy Kawasaki
The Art Of Evangelism ~ Guy Kawasaki
Value Forward Selling ~ Paul DiModica

Ten Things to Stop Doing To Yourself

April 2, 2015
Organisational effectiveness, Organisational Therapy, Rightshifting
1 Comment

Ten Things to Stop Doing To Yourself

As Arthur Ashe said, “Start where you are. Use what you have. Do what you can.” Bringing about positive change in our workplaces, and the way our work works, comes down to making a start. But just as learning new things often involves unlearning old things, making a start often goes hand in hand with stopping a bunch of things that have been holding us back.

Here are some ideas on what to stop, to help get you started:

  1. Stop ignoring folks’ needs. Including your own. As human beings we have several million years of evolution behind us that has made us, above all, Homo Empathicus. A workplace where we attend to each other’s needs – and to our own – is a constant source of joy and belonging. And an absolute prerequisite for significant positive changes in the way our work works.
  2. Stop believing what others expect you to believe. In the words of Steve Jobs, “Our time is limited – don’t waste it living someone else’s life. Don’t be trapped by dogma, which is living the result of other people’s thinking.” Find out for yourself. Seek your own truths. Be mindful of the many implicit assumptions we all operate under ever day. “If you see Buddha on the road, kill him”.
  3. Stop working blindly to other people’s priorities. Only when we understand the purpose of what we’re working on can we find deep satisfaction in it.
  4. Stop doing all those things that impair folks’ cognitive functioning – including your own. It’s no surprise to realise that knowledge workers work with their brains. And that a thousand and one things each day get in the way of that. You don’t know what things impair cognitive functioning? Go find out.
  5. Stop using fear, obligation, guilt and shame in forlorn attempts to get others to do what you want them to. Ask yourself: what reason would you best like for others to do what you want?
  6. Stop running from problems. Face them head on. As Ohno said, problems are priceless “kaizen opportunities in disguise”. And “Having no problems is the biggest problem of all”.
  7. Stop doing things the way they’ve always been done. We can’t get started on changing the way our work works if we hang on to past ways of doing things. “The most dangerous phrase in the language is, ‘We’ve always done it this way’.” ~ Grace Hopper
  8. Stop bashing stuff out with little care for its quality or relevance. Yes, you may get paid for doing that, but at what cost to your self-esteem and self-respect?
  9. Stop pursuing efficiency, especially at the cost of effectiveness.
  10. Stop looking at things rationally. Understand just how irrational and driven by emotions and hidden biases we humans are. Work with that, not against it.

– Bob

Further Reading

Stop It ~ Bob Newhart
The Kurt Lewin Change Management Model ~ Kurt Lewin
Bridges’ Transition Model ~ William Bridges
Baggage ~ Think Different blog post
Predictably Irrational ~ Dan Ariely