Archive

Culture change

The Advice Process – Flaws and Fixes

“The advice process is a tool that helps decision-making via collective intelligence. Much depends on the spirit in which people approach it. When the advice process is introduced, it might be worthwhile to train colleagues not only in the mechanics but also on the mindset underlying effective use.”

We’ve been using the Advice Process for several months now. Whilst we’re still very much committed to its use, and wish to see the changes it promotes, all has not been going smoothly with its uptake.

Promises

We chose the Advice process as a means to devolving and distributing decision-making. We like its promise of quicker – and better! – decisions, raised levels of trust, improved communication, and higher levels of involvement and engagement. This list describes the promises, as described by its early promoter, Dennis Bakke of AES, in more detail:

  • Community: it draws people, whose advice is sought into the question at hand. They learn about the issue. The sharing of information reinforces the feeling of community. The person whose advice is sought feels honored and needed
  • Humility: asking for advice is an act of humility, which is one of the most important characteristics of a fun workplace. The act alone says, “I need you“. The decision maker and the adviser are pushed into a closer relationship. This makes it nearly impossible for the decision-maker to ignore the advice.
  • Learning: making decisions is on-the-job education. Advice comes from people who have an understanding of the situation and care about the outcome. No other form of education or training can match this real-time experience.
  • Better decisions: chances of reaching the best decision are greater than under conventional top-down approaches. The decision maker has the advantage of being closer to the issue and has to live with responsibility for the consequences of the decision. Advice provides diverse input, uncovering important issues and new perspectives.
  • Fun: the process is just plain fun for the decision-maker, because it mirrors the joy found in playing team sports. The advice process stimulates initiative and creativity, which are enhanced by the wisdom from knowledgeable people elsewhere in the organization.

Practice

In practice, we have not yet seen full realisation of the promises. Overall, we attribute this to poor implementation of the Advice Process, which we’re now intent (sic) on fixing – whilst not undermining its original promises (see above).

Flaws

Some of the implementation flaws we have experienced include:

  • Permission-seeking. Some folks have not yet overcome their established reflex of seeking permission. The Advice Process as conceived rejects permission-seeking, placing implicit responsibility for outcomes on the individual or team with the intent, not on the permission-giver. This shift (i.e. from authoritarianism to co-creation) requires a degree of courage from all parties.
  • Trust. Some advisors have found it challenging to trust the intentions or competence of those seeking advice.
  • Belief. Some with intentions have found it challenging to believe that they now have the power/authority to make key decisions.
  • Misunderstanding/clashing frames of reference. Sometimes, advice sought and then given has been received/interpreted as denial of permission.
  • Impatience. The delay between announcing intent and receiving advice has proved a source of friction, leading on occasions to proceeding without waiting to receive considered advice from advisors who may hold key pieces of the puzzle (often, these are the busiest of people).
  • Criticality. Some people have voiced concerns that key business decisions with serious negative commercial or reputational risks could proceed to action, even when some key risks go unappreciated or unaddressed (due to advice being sought from the wrong quarters, ignored, or not understood).

Fixes

We’re intending to experiment with addressing the above concerns through a couple of refinements:

  • Shared responsibility. The onus of communication will rest equally with those communicating intent and those from whom for advice is sought. Those announcing an intent are requested to actively pursue advisors to confirm their intent has been heard and understood by all the necessary parties; those from whom advice is sought are requested to respond promptly and with due consideration of the significance of their role and advice.
  • Time-outs. In those cases where someone believes there is a problem – maybe they feel the Advice Process has not been followed correctly or not used when it should have been – that someone may call a Time-out. The intention or action in question – which may already be in train – will then be suspended, pending a go-around (i.e. another taking of soundings, general proposal of intent, seeking of advice, confirmation that the intent has been understood, and consideration of advice received). Note: This does not imply that the intention itself has been denied or overruled. Rather, some party to a particular instance of the Advice Process believes the Advice Process has not been followed or used appropriately, and that the risks implicit in the intention or action are likely not being duly considered or attended-to.
  • Arbitration. We’ll see if we need to introduce some arbitration or conflict-resolution mechanism to handle repeated time-outs being called against a given intention or action, or to handle occasions where parties disagree on whether the Advice Process has indeed been followed correctly or not.

I’ll keep you posted on how our experiment is going.

– Bob

Further Reading

Decision Making ~ ReinventingOrganisations Wiki

The Advice Process – Definition and Usage Tips ~ Daniel Tenner

Advice Process for Effective Organizational Decision-Making ~ Agilitrix

Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.

Cadence

Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.

Artefacts

Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

 

Tasks – or Deliverables

In most every development shop I’ve seen, folks’ planning vocabulary has been founded on the task as the unit of work. Long ago, at Familiar, we discovered that a different vocabulary offers some key advantages. Ever since then I’ve found that a planning vocabulary when deliverables are the default unit of work suit me much better.

Some Key Advantages

  • Planning in tasks encourages (subconsciously for the most part) busywork (a focus on activity).
  • Planning in deliverables encourages a focus on outputs (ands thus, closer to outcomes).
  • Deliverables are closer to what stakeholders seek (i.e. having their needs attend-to, or even met).
  • Tasks are generally one stage further removed from needs than are deliverables.
  • Deliverables are, to a degree, ends in themselves – tasks are means to ends (and hence more disconnected from outcomes).
  • I find it easier and more useful to quantify aspects of deliverables than aspects of tasks. YMMV.

Mayhap a focus on outcomes directly would be a further step in the right direction, but for most of the development groups I’ve seen, a single leap from tasks to outcomes might have proven infeasible.

May I invite you to trial a change of vocabulary, and of focus, next time you have the opportunity?

– Bob

 

The Future Of Software-Intensive Product Development

A little while ago I wrote a post posing some questions about what ways of working we might look to, After Agile. Fewer folks engaged with this post compared to some others I have written. So I’m assuming that few are thinking about what we might see as the natural – or even unnatural – successor to Agile.

It is, however, a topic that occupies me regularly. Not least because of the intrinsic flaws in the whole Agile idea. We can, and eventually must, do much better.

Recently, some folks have been asking me about what I see as the future for software- and software-intensive product development (SIPD). Of course, I’ve been answering this question, on and off, for at least the past few years.

In a Nutshell

To sum up my take: In a nutshell, the issues that plague SIPD seem obvious. They’re mostly the same issues that plague all forms of collaborative knowledge work. Issues compounded by the gulf between conventional or traditional work and the new world of work (i.e. the world of collaborative knowledge work) – a new world distinctly unfamiliar to most in the world of work today.

We are faced with various collections of pathogenic beliefs (management, traditional business, Agile, etc.), none of which provide us with a context for EFFECTIVELY tackling the challenges we face in the new world of work – i.e. the world of collaborative knowledge work.

I’m choosing here to list these challenges in terms of needs, and in terms of the strategies – conventional and unconventional – for meeting those needs.

Developers’ Needs

Agile came into being driven by developers attempting to see their needs better met. These include:

  • Less working time “wasted” on mindless bureaucracy and distractions, such as meetings, reports, documentation, etc..
  • More time to focus on making great software, and stuff that delights customers.
  • Improved relationships with co-workers, business folks, customers, and the like.
  • More flexibility to adapt to emerging information, to changing needs, and to things learned along the way.
  • More say in what they work on, the tools they work with, and how they do their work.
  • Approval of one’s peers (including a sense of belonging and community re: the “technical” tribe)
  • And simply, the leeway to just “do a better job” and make a positive difference in the world.

Bottom line: Many developers need to feel valued, purposeful, that they’re making progress (learning) and are recognised for their abilities.

Business Folks’ Needs

Secondarily, but still important in the Agile approach, is better outcomes for “the business”. Agilists have come to recognise the following needs (even though common forms of Agile do not address them).

  • Approval of one’s peers (including a sense of belonging and community re: the “management” tribe).
  • Empathy (meaningful connection with other human beings).
  • A positive self-image.
  • Stability (folks have families to support).
  • Acclaim/fame (folks have careers to pursue).
  • Warmth (of human relationships) – Most business folks are just normal people, too.
  • Peace (i.e. an absence of distress).
  • Purpose.

Users’ / Customers’ Needs

Businesses ultimately stand or fall on revenues. Revenues which depend on their products and services meeting the needs of their customers. These needs include:

  • Approval of one’s peers (including a sense of belonging and community re: the “brand” or “XYZ customer” tribe).
  • A positive self-image (what being a user or owner of a certain product says about you, in your own mind).
  • Stability (folks don’t like to think too hard, or continually learn new stuff for no good reason).
  • Warmth (of human relationships) – Most customers, being humans, value interactions with other human beings.
  • Low fuss (i.e. being able to get their jobs done with minimal distress).

Shareholders’ Needs

Shareholders also have needs which they seek to get met. These include:

  • Approval of one’s peers (including a sense of belonging and community re: the “investor” tribe).
  • Contribution to society (e.g. ethical investments) and communities.
  • Financial returns (investors have families and/or lifestyles to support).

In a future post I’ll be looking at the strategies that people use to get these needs met, including those strategies implicit in Agile methods – and some alternative strategies that might prove

– Bob

 

Surely You Can’t Mean That?

shocked

I regularly talk with business people about improving their software and product development, and their businesses as a whole, more and more dependent as these businesses are on these capabilities. The reaction I see far more often than most others is – incredulity.

“Surely you can’t mean that??”

Collaborative Knowledge Work

“Collaborative knowledge work is fundamentally different to the kinds of work you and your people are used to. It will require fundamental shifts in how you approach the whole idea of work.”

“What?!? Surely you can’t mean that?”

Managers

“Managers and management are antithetical to collaborative knowledge work – you’ll have to find some other things to which these folks can apply their skills and experience.”

“What?!? Surely you can’t mean that?”

Workers

“The best people to decide how the work should work are the people doing the work. Not the managers.”

“What?!? Surely you can’t mean that?”

Scrum

“In Scrum, there are only three roles: Developer, Scrum Master and Product Owner.”

“What?!? Surely you can’t mean that?”

Relationships

“The one key element to productivity in collaborative knowledge work is the quality of the relationships between people.”

“What?!? Surely you can’t mean that?”

Projects

“Doing work in projects inflates your costs, demoralises workers, and sucks management attention. You would be well served to find some other approach.”

“What?!? Surely you can’t mean that?”

Certainty

“Looking for certainty – of timescales, costs, quality, outcomes – is a Fool’s Errand. Get comfortable with uncertainty, and focus instead on flexibility and reducing delays.”

“What?!? Surely you can’t mean that?”

Strategy

“The days of a sellers’ market are over. Winning businesses will be those that discover how to compete successfully in a buyers’ market.”

“What?!? Surely you can’t mean that?”

Telling

“Telling capable employees what to do and how to do it only demoralises and demotivates them. Move from telling to serving.”

“What?!? Surely you can’t mean that?”

Incredible

All these are incredible, unbelievable, and utterly essential ideas in the world of collaborative knowledge work. How can we all stop drawing sharp intakes of breath, and come to terms with these – and many other –  impossible-to-believe ideas?

– Bob

 

The Twelfth Principle

There are four values and twelve principles connected with the Agile Manifesto. As the folks at 12thPrinciple say,

“the four values and eleven of the twelve Agile principles do not address the wider organization at all.”

This is one of the key reasons why so many Agile adoptions (circa 80%) fail to deliver on the Agile promise.

I have this weeks added my name to the list of signatories at 12thprinciple.org.  Not because I totally and wholeheartedly embrace the “Twelfth Principle” in its current form. But because I wish to lend support to the idea that it’s the wider organisational context that utterly determines whether any kind of progressive change effort or initiative succeeds or fails.

The Twelfth Principle (n.b. actually appearing fifth in the list of Principles behind the Agile Manifesto) reads:

“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

I see some basic flaws in this, but it does serve to highlight (at least, implicitly) the role of the wider organisation.

Here’s my take on these “flaws”:

  • Projects. I see little point in using projects to frame development efforts. Personally, I subscribe to #NoProjects, and FlowChain as a practical means to replace the whole idea of projects, in favour of product development flow.
  • Individuals. Yes, teams consist of individuals. But Man is a social animal, and collaborative knowledge work – such as software and product development requires society, not individuals. I get the idea that we’re really taking about a focus on people, here. As opposed to say structure, hierarchy, process, or what have you.
  • Give. Not so much give as in charity or largesse, but give as in make available, enable.
  • Them. Shades of them and us? Unfortunate choice of pronoun.

With a free hand, and the awesome benefit of hindsight, I might represent this principle thusly:

“We accept that collaborative knowledge-work proceeds best when we place people at the core of our focus.
We recognise that people do best within a supportive environment,
where needs are shared and attended to by all.”

How might you rephrase this principle?

– Bob

 

 

I Lied

liar

Earlier today I tweeted a lie. I knew I was doing it, and went ahead and tweeted anyway. And I’m not ashamed of it.

Let’s set aside the question of why we feel outraged, disappointed, or betrayed when we catch someone – including, often, ourselves – in a lie.

Down To Brass Tacks

The tweet in question read:

Where’s the lie? Where’s the harm?

The lie is twofold: in the phrase “ideal environment” and in the phrase “optimal knowledge work”. I’ll try to explain the potential harm as we go…

Lie One: Idealism

In psychotherapy, many therapists guard against holding up some ‘ideal” image of a “mentally healthy and well adjusted person”  to their client.

“Clients would be better helped if they were encouraged to focus on their current subjective understanding rather than on some unconscious motive or someone else’s interpretation of the situation.”

In other words, striving for some imagined “ideal” often introduces incongruence, which carries its own pathogenic risks.

“Some clients may feel that their personal problems mean that they fall short of the ‘ideal’. They may need to feel reassured that they will be accepted for the person that they are and not face rejection or disapproval.”

I have observed a similar psychopathology at work in those organisations image, or that attempt to define, an “ideal state”.

Organisational Psychopathology

In a fully congruent organisation, realising its potential is not at the expense of experiencing positive regard. It is able to lead a life that is authentic and genuine. Incongruent organisations, in their pursuit of positive regard, lead lives that include falseness and not realising their potential. Conditions they impose on themselves make it necessary for such organisations to forgo their genuine, authentic lives to meet with approval. They operate from a place incongruent with their true nature.

The incongruent organisation, always on the defensive and closed to many experiences, finds itself ill at ease with its own self. It works hard at maintaining/protecting its self-concept. Because its way of being lacks authenticity, this work is difficult and such organisations can feel under constant threat. Distortion and denial arise to help in defending its self-concept. Distortion occurs when the organisation perceives a threat to its self-concept. The organisation distorts their perception until the (distorted) perception fits their self-concept.

Such defensive behaviour reduces the consciousness of the threat but not the threat itself. And so, as the threats mount, the work of protecting the self-concept becomes more difficult and the organisation becomes more defensive and rigid. If the incongruence is immoderate this process may lead the organisation to a state could be described as neurotic. Its functioning becomes impaired. If the situation worsens it is possible that the defenses cease to function altogether and the organisation becomes aware of its incongruence. Its manifest being may become disorganised and bizarre; irrational behavior, associated with earlier denied aspects of self, may erupt uncontrollably.

Lie Two: Optimality

Many organisations espouse optimality, yet few indeed have a theory-in-use congruent with this.

 “Effectiveness results from developing congruence between Theory-in-use and Espoused theory.”

~ Chris Argyris

So, yes, speaking to “optimality” is speaking to – and congruent with – most organisations’ espoused theories. Thus it may receive more favourable attention than something that speaks to their (unseen) theories-in-use. But in truth, the therapist guards against the client’s espousal of optimality. From the clients theory-in-use perspective, “somewhat better” is likely much more realistic. A key aspect of therapy is providing the opportunity for the client to become aware of, and thereby, maybe, reduce its incongruence.

I suspect expressing the tweet in question in a way that connects with people and organisations might take some doing. Here’s the weaker(?) but more honest version:

Organisational therapy is about creating environments, conditions and workplaces that support more effective knowledge work and cognitive function.

– Bob

Further Reading

All Marketers Are Liars ~ Seth Godin

//platform.twitter.com/widgets.js

%d bloggers like this: