Archive

Monthly Archives: January 2013

What’s Wrong with the Project Approach?

January 28, 2013
Agile, Archive, Flowchain, Organisational effectiveness, Reblog, Software development
18 Comments

What’s Wrong with the Project Approach?

Some time back the late, great Grant Rule wrote this paper on the problems with “projects” as an approach to organising software development. As the original has now ceased to be, I’ve taken the liberty of reproducing it here for posterity:

What’s wrong with the project approach to software development?

January 11th, 2011
Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

  1. Those responsible for business strategy are disengaged from, and know relatively little about, software-intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
  2. Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well-defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s skip over the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C-suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

– P Grant Rule

Nonviolent Management

January 27, 2013
Fellowship, Leadership, Organisational effectiveness, Psychology
1 Comment

Nonviolent Management

This post is a joke, right? How can a concept so closely associated with our prevailing world of domination and Jackal language, so accustomed to using fear, obligation, guilt and shame to achieve its ends, so mired in the mechanics of systemic violence, ever be nonviolent?

Well, bear with me, for I believe there is a way. A way to achieve the same ends as conventional management. And at much lower human cost. Companies everywhere seem to be waking up to the benefits of an “engaged” and motivated workforce. Fewer seem to understand the causal link between the domination system of traditional management and the widespread passive disaffection and disengagement of employees today.

So, for starters, here’s a list of some of the key things that “management” does:

  • Organising and coordinating the activities of a business, so as to achieve defined objectives.
  • Understanding markets’ and customers’ needs and wants.
  • Prioritising and allocating resources, such as equipment, premises, attention, money and people.
  • Helping and directing various efforts towards a definite purpose.
  • Exercising power and authority in making decisions and overseeing an enterprise and its endeavours.
  • Measuring and monitoring progress.
  • Artfully getting things done, with and through other people, in formally organised groups.
  • Forecasting and planning, organising, directing, co-ordinating and controlling (analyse and adjust). (Fayol)

The Belief System Underpinning Violent Management

Douglas McGregor described well the belief system underpinning much of traditional management. He labelled this “Theory X“:

  • The average human being has an inherent dislike of work and will avoid it if he or she can.
  • Because of their dislike for work, most people must be controlled and threatened before they will work “productively”.
  • The average human prefers to be directed, dislikes responsibility, is unambitious, and desires security above everything.
  • Judgement of individuals is a natural and human behaviour.
  • Extrinsic (imposed) discipline – in the form of targets, directives, rules, policies, etc. – is a normal component of the work landscape.
  • Use of coercion, fear, obligation and guilt is both just and necessary.
  • People who resist subjugation and refuse to be complicit in this scheme of things are judged as troublemakers and should rightly be marked for punishment and/or retribution.

So, looking at both the above lists, I posit there’s nothing in the first list that requires the belief system described in the second list (with the possible exception of Fayol’s definition).

How Might Nonviolence Work in Management?

As in other posts, I’ll just briefly recap on the four steps of nonviolent communication:

  1. Say what you saw, or heard (a simple evaluation-free statement)
  2. Say what you felt (it can help, initially, to pick from a list)
    “I feel…”
  3. Say what you need (again here’s a handy list)
    “…because I need/value…”
  4. Make a request (the concrete actions you would like taken)
    “Would you be willing to…?”

So, how might nonviolent management work, in practice?

Instead of telling folks (specifically subordinates, so-called “direct reports”) what to do, the nonviolent manager may, through the four steps, communicate thusly:

  1. Say what she has heard or seen that is relevant to i.e. the running of the business.
  2. Say what she felt upon hearing or seeing that thing.
  3. Say what she needs (sometimes on her own behalf, sometimes on behalf of her unit, or the business as a whole).
  4. Make one or more specific requests (non-demanding, positive and actionable).

This begins to look somewhat like the notion of “Commander’s Intent” from e.g. Auftragstaktik (Mission-type tactics), and the interactive exchange of Commander’s Intent with subordinates’ questions and concerns, during the mission briefing.

An Example

To get a better idea of how this could work in practice, let’s follow a nonviolent conversation between a Manager and her team:

  1. “I heard yesterday from the CMO that we’ll be launching a big marketing campaign at the start of next month.”
  2. “On hearing that, I felt nervous because I’m not sure we can get the new version of the product ready for launch by that date.”
  3. “I need to understand both the likelihood of us being ready, and some options in case we’re not.”
  4. “Simon, would you be willing to take a look at where we are on the product update and get back to me with a confidence estimate for an on-time launch?” (Assuming he agrees:) “How much time do you need for that? What else might you need?”
    “Sally, Joe, Annie, would you be willing to work together to come up with some alternative options in case we miss the deadline?” (Assuming they agree:) ” When can you let me have those options by?”

And of course, the conversation may well go back and forth rather more than shown in this short example, with the manager asking her people how they feel about her requests, what needs of theirs are (and are not) being met, and what requests they might have in response. Some might call this negotiation. I’d favour calling it “mutual exploration of the mission”.

Personally, I’d feel much happier to see the folks work out something like this together, in a spirit of fellowship. But in the traditional organisation, we generally have an obligation to work within the tramlines of the management hierarchy. Such is life.

I have had, occasionally, the pleasure to work with managers who, sensitive to the deleterious effects of coercion and violence on morale and engagement, have adopted and cultivated their own style of management not dissimilar in practice to the example laid out here.

Social Styles

Everyone is different, and “Social Styles” (from Wilson Learning) can help us both appreciate those differences, and adjust our styles of interaction to suit others’ styles. In the Social Styles model, there are four basic styles in which folks like to receive (and convey) information:

    • Analytic – wants numbers, data and facts
    • Driver – just wants to know when something will be done.
    • Amiable – likes to chat about various peripheral things in the course of an interaction
    • Expressive – tends to talk about feelings, emotions and state of mind

I mention this because some archetypal “drivers” might baulk at the time necessary to have such conversations. In “Warfighting“, the US Marines (not known for hanging about, jawing) understand the need to take the time to allow subordinates to understand the mission, contribute to the conversation, and then exercise proper “topsight” and bottom-up initiative. To abbreviate a quote from Dwight D Eisenhower: “Planning is indispensable”.

Summary

Hopefully, in organisations where management and hierarchy have not yet given way to more enlightened forms of coordination and control, this nonviolent approach to management can blunt the psychological damage and consequent dysfunctions of today’s much more prevalent “violent” style of management.

Your views?

– Bob

Nonviolent Meetings

January 25, 2013
Dialogue, Fellowship, Organisational effectiveness, Psychology
3 Comments

Nonviolent Meetings

Around a month ago I wrote a post on Nonviolent Conferencing. Central to that idea – well, more of an appeal, really – was the use of the four steps of Nonviolent Communication as a framework for the conference and the delegates’ participation:

  1. Say what you saw, or heard (a simple evaluation-free statement)
  2. Say what you felt (it can help, initially, to pick from a list)
    “I feel…”
  3. Say what you need (again here’s a handy list)
    “…because I need/value…”
  4. Make a request (the concrete actions you would like taken)
    “Would you be willing to…?”

Having set through a number of meetings this week, I’m minded of much the same dysfunctions in meetings as I see in the more traditional formats for conferences:

  • Speakers not in tune with their own needs nor the needs of their audience.
  • “Push” of more-or-less random information – often of little interest or relevance to the audience.
  • Tendency to talk about things that work well, rather than air problems that need fixing. Whereas a Solutions Focus is nice, often things that could benefit from others’ positive solutions do not get mentioned.
  • Failure to engage with the emotions of the audience (cf Emotioneering).
  • Little or no fellowship – limited sense of collaboration and mutual learning.
  • Fear, obligation, guilt and shame preventing anyone leaving the room, or even saying anything about their frustrations with the meeting.
  • The prospect of future meetings following just the same format, with just the same frustrations.

And in the same vein as Nonviolent Conferencing., I can see nonviolence bringing much improvement to the standard meeting experience.

How would this work?

Basically, the Nonviolent Meeting would bring together

  • folks with specific (topic-related) needs, and
  • folks who might be able and willing to help meet those needs.

Each participant would:

  1. Share with the meeting one or more observations (things seen, heard or otherwise observed at their places of work, and related to the topic at hand – free from judgements or evaluations).
  2. Share what they felt about the thing(s) observed.
  3. State what they was needing, needs which caused them to feel that way.
  4. Make one or more specific requests (non-demanding, positive, actionable) of the other folks in the meeting), in the hope that someone (or some number of those folks, together) might be able to meet their request(s).

Following a request (or requests), the folks in the meeting can then, together, consider how they might contribute, singly or in fellowship, to the satisfying of each request.

Aside: This approach might also serve to encourage some focussed thought in preparing for the meeting. I know from my own experience with Nonviolent Communication how difficult it can be sometimes to go from an observation, to a well-identified feeling, to an underlying need, to a specific request, particularly on-the-hoof. Having some preparation time beforehand to follow through the four steps of NVC might be helpful, especially if one could have some colleague or coach to help in the preparation.

Seems to me this could cut out a whole passle of la-la yadda-yadda talk, and get to the crux of the issues on the table – needs that folks have, that they need help with, help from the other folks around the table.

I’d be interested to hear if you’d be willing to give it a go in your next meeting? And to hear your feedback on the idea.

– Bob

Further Reading

Nonviolent Communication ~ Marshall B. Rosenberg
Speak Peace in a World of Conflict ~ Marshall B. Rosenberg

Business Doctrine

January 18, 2013
Organisational effectiveness, Rightshifting
Leave a comment

Business Doctrine

What is Business?

The US Marine Corps’ “Warfighting” Manual defines the Marines’ “doctrine” – what they believe about their “business” and how they approach it . The manual starts out by defining the context for the whole thing, War itself:

WAR DEFINED

“War is a violent clash of interests between or among organized groups characterized by the use of military force. These groups have traditionally been established nation-states, but they may also include any nonstate group—such as an international coalition or a faction within or outside of an existing state—with its own political interests and the ability to generate organized violence on a scale sufficient to have significant political consequences…”

To me, it seems eminently sensible to define what we’re talking about – “War” in this case – before we can productively start to define and discuss what we believe concerning appropriate means to go about e.g. Warfighting.

So too, it seems to me, is it sensible to define what we mean by “Business” before we can productively start to define and discuss what we believe concerning appropriate means to go about e.g. “running a business”.

Of course, war is about many things, and the definition in Warfighting focuses on just a few dimensions, to the exclusion of many others – those which may not suit the narrative of the Marine Corps or its political masters (such as the Myth of Redemptive Violence).

So too is business about many different things, many unspoken, some contradictory. And most organisations have their own shared narrative (aka mindset, memeplex) – often implicit – about the very nature of business.

Few indeed have been the business organisations I have seen where the fundamental topic of “Business Defined” is discussed, let alone debated.

Here’s just some opinions on “Business Defined”, from various sources:

“The purpose of business is to create and keep a customer.”

~ Peter F. Drucker

“The sole purpose of business is service.”

~ Leo Burnett

“Profit is not the legitimate purpose of business. The legitimate purpose of business is to provide a product or service that people need and do it so well that it’s profitable.”

~ James Rouse

“A business is a nexus for a set of contracting relationships among individuals”

~ Jensen and Meckling

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.” [Ergo: a business exists to maximise its executives’ well being.]

~ Russell L. Ackoff

And we might also accept various other interpretations of “Business Defined”, including the perspective of Art Kleiner and his Core Group Theory, and the idea that businesses serve a social purpose – to give people some place or “ba” in which to come together and be human.

The purpose of organizations is to help people have lives.

~ Phil Crosby

Aside: Rightshifting takes the view that the purpose of any given business is more or less unique to a time, a place, and the people involved.

Doctrine

What do you believe business is for? How many of your colleagues share your perspective on “Business Defined”?

And how likely is it that – absent a consensus, at least within a given organisation – folks have any chance of meaningful discussions and decisions about the “hows” of the business in question?

How can we come up with a doctrine for our business, if we can’t even agree on why we all turn up for work every day? Are we doomed to all pursuing our various different agendas, milling around like a herd of cats?

– Bob

Further Reading

Nonviolent Change

January 10, 2013
Agile, Coaching, Ethics, Organisational effectiveness, Organisational Therapy, Product development, Psychology, Rightshifting, Software development
11 Comments

Nonviolent Change

Change initiatives, and their generally bigger cousins “change programmes”, almost always involve fear, obligation, guilt and shame. And start from a position of coercive violence.

Here’s a typical posture I’ve seen time and again in the context of organisational change both large and small:

“The company needs to make some changes to become more profitable. We judge you, you and you to be of the right stuff for this assignment. You will work on this change effort. Here’s a list of the changes we want to see. And here’s how we insist you should go about these changes. Do things our way and you’ll be ‘right’. Anything else and you’ll be ‘wrong’. If things go well you can hope for some minor level of gratitude and/or recognition. But woe betide things going badly (veiled threats or implicit allusions to the effect that you could be punished or fired in such circumstances). Actually, however things turn out, we’ll classify you all into various shades of right or wrong. Oh, and we also insist that you feel obliged to look happy and motivated whilst doing this.”

Do you see the violence inherent in this system? Walter Wink would describe this as a “Domination System”. Marshall Rosenberg might call it a “Jackal culture”:

“In Jackal culture, feelings and wants are severely punished. People are expected to be docile, subservient to authority; slave-like in their reactions, and alienated from their feelings and needs.

“In Jackal, we expect other people to prove their loyalty to us by doing what we want.”

~ Marshall Rosenberg

What’s Wrong With this Picture?

This posture inevitably provokes defensiveness, resistance, and counterattack. We often call this a “passive aggressive” response. Although outright aggression is possible, too. This posture impacts the morale and (initial) goodwill of the people chosen. It robs involvement and motivation, and induces a state of fear, insecurity and learned helplessness. Ultimately, it’s a key contributing factor to increasing the poor health of the organisation.

Yet it’s so much the norm that it’s beyond most folks’ imagination to even notice that there could be an alternative. Let’s take a look at just one viable alternative:

The Nonviolent Posture

“I guess you share some of our concerns about the future of the company. We have noticed X and Y and Z as signs that the company needs to make some changes to become more profitable. How do you feel about this? We feel concerned enough that we’d like to see a group come together to work on this. Who shares our view on this need (to become more profitable)? What need (purpose) would best align with your needs? What would you each need (request) to sign up to this group? If things go well we can all hope for things to be mutually more wonderful. If things don’t go so well, we’ll all see what we can do about it, at the appropriate time. Actually, however things turn out, are you willing to share in our choice to believe that everyone was doing their best?”

“How could this possibly work?”

“Isn’t this lunatic optimism run riot?”

These are questions which often follow as a common response to nonviolence in general, yet time and again nonviolent means have wrought unlikely (positive and beneficial) outcomes.

Aside: Note the general NVC framework in this posture: Empathy, observations, feelings, needs, requests.

In such a scenario as here described, a genuine posture of nonviolence offers the opportunity for everyone to have their needs met. And when folks have their needs met, they’re likely to feel engaged, hopeful, confident, excited and inspired, to name but a few of the positive emotions.

Of course, it’s a matter of personal belief as to whether such emotions are appropriate, and beneficial, in e.g. a business setting.

What do you believe? Which posture do you see as have more benefit? As having more chance of success? As more humane?

And under which posture would you flourish more? Which would best meet your needs?

Afterword

I chose to characterise both of the above postures in the context of an Analytic-minded organisation. This was both to make the idea more accessible to folks with that worldview, and to illustrate that even in such organisations, it doesn’t require a wholesale shift in the organisational mindset to begin using Nonviolent Communication in e.g. change initiatives.

Just for the record though, here’s the second posture recast in the context of a Synergistic-minded organisation:

“I guess we all share some concerns about the future of our company. Some folks have mentioned X and Y and Z as signs that we need to make some changes. Changes that might incidentally also help improve e.g. profitability. How do we all feel about this? I feel concerned enough to ask whether we’d like to see a group come together specifically to work on this. Who shares our view on this need (to do something, now)? What need (purpose) would best align with each of our own needs at the moment? What would folks each need (request) to sign up to this group? If things go well we can all hope for things to be mutually more wonderful. If things don’t go so well, we’ll all see what we can do about it, at the appropriate time. Maybe it’s not necessary to remind ourselves that actually, however things turn out, we choose to believe that everyone was doing their best?”

And, in a Chaordic-minded organisation, it’s highly unlikely that this conversation would ever even be necessary, as the need for change, the enrolment of people, and the whole nine yards, would be an integral part of daily business-as-usual.

– Bob

Further Reading

Nonviolent Communication: A Language of Life ~ Marshall Rosenberg
Empowerment: The Emperor’s New Clothes ~ Chris Argyris

Taking Vocabulary to Task

January 7, 2013
Agile, Organisational effectiveness, Product development, Psychology, Software development
2 Comments

Taking Vocabulary to Task

Yesterday I asked via Twitter:

“What might one call a Kanban or Scrum board if one is doing neither Kanban nor Scrum?”

Context is always a challenge in 140 chars, so to expand just a little: I was asking from the point of view of folks (like myself) who prefer to walk their own path apropos methods and practices, either evolving something from scratch or so adapting a Scrum or Kanban approach to point where the label no longer really applies.

My thanks to all the folks that responded with their answers:

  • “Task board”
  • “Information Radiator”
  • “Activity Board”
  • “Kanban board (generic)”
  • “Task/activity board”
  • “Process or progress board”
  • “Visual planning board”
  • “Value visualiser”
  • “Story board”
  • “A board”

I guess by their answers, my question lacked sufficient context for some folks:

  • “A lie”
  • “An impediment”
  • “Pretty wall art”
  • “Messy”
  • “A Gantt chart”

Linguistic Relativity

I’ve mentioned the concept of Linguistic Relativity some number of times in previous posts.

For many years I have avoided using the term “task” (or its surrogate, “activity”) for one major reason: The way it sets folks up for being busy (active, working) rather than smart.

Let me explain.

What are we, fundamentally, doing in software development? Some options present themselves as answers:

  • Delivering software (code and other artefacts)
  • Delivering value (in the form of executable and other related artefacts)
  • Delivering things (artefacts, services, etc). that meet the needs of our stakeholders
  • Learning (acquiring the know-how to repeatably deliver something)
  • Building capability (generally in parallel with the above)

in contrast, the idea of a task or activity implies DOING something (i.e. a focus on the activity, rather than on the output). Ideally, we’d like to be able to deliver everything wanted or needed by all the stakeholders, to the “planned” quality levels (cf Gilb, “Competitive Engineering“) with ZERO work (activity).

“Here’s the deal. The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. Right? The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write – right? So, the goal here is to eliminate 80% of the code that you have to write for your app.”

~ Steve Jobs

Aside: Jobs was talking about lines of code, but I posit the argument holds just as well for all the other artefacts involved in software development.

I have found, in practice, that using the term “artefact” or similar reminds folks – often on a subliminal level – that they can get creative and avoid doing much if any work, if they’re smart enough to seek and find ways to achieve the desired ends with little or no activity.

This is why, for many years, I have preferred the “unit of flow” or “unit of control” in software (and product) development to be the Artefact (many of which are interim and not “deliverable”; some fewer, deliverable). Most other folks seem to opt for the default: “Task”.

An Answer of a Sort

So, back to the original question. Absent the explanation laid out here, maybe “task board” would be the most natural choice. Perhaps you can now see why I passed on that.

And “Artefact board” seems weird and contrived, albeit more congruent. Maybe it could grow on me, given time. And it does point to the possibility of using cards for artefacts (or groups of artefacts), rather than e.g. use cases or stories/epics. I kind of like that idea.

But, for the moment, I guess I’d have to go with “control board”, or just maybe “flow board”.

My thanks again to all those who responded.

– Bob

Nonviolent Employment

January 6, 2013
Agile, Familiar, Fellowship, Organisational effectiveness, Psychology, Rightshifting
9 Comments

Nonviolent Employment

Since I’ve begun looking back on past experiences through the lens of Nonviolent Communication, I have come to see this philosophy as permeating many of the policies and decisions with which I’ve been involved over the years.

I’ve written most recently about a needs-based approach to managing projects, and the congruence of that approach with nonviolent precepts.

Only since reflecting on that post have I noted a similar nonviolent thread within the employment policies we had at Familiar.

Voluntary Assignment

“Accept the fact that we have to treat almost anybody as a volunteer.”

~ Peter F. Drucker

Everyone working with Familiar had the freedom to decide which assignments they wanted to work on, and which not. Folks could, at any stage (well, in practice at Sprint boundaries) opt in or out of working on something that was already in progress.

This meant that work had to be in some way attractive, literally. And yes, sometimes this meant we as a company turned away potential business because no one found it attractive enough to commit to working on it.

In NVC terms, if a piece of work did not meet someone’s needs, they were under no obligation to spend time on it.

Status

Everyone had the choice of how they wished to engage with the company. This meant they could consider what they needed – most obviously, in terms of security and continuity of engagement. The options ranged, in practice, from independent subcontractor, through contractor, employee and on to e.g. indentured serf.

And this was flexible, in that someone could change their status as and when they saw fit. In NVC terms, people could make direct, specific, and actionable requests as to the way in which they wanted to engage with the company, at any given time, contingent upon their needs as they saw them.

Compensation

Everyone was free to set their own rate or salary. At the time this was an idea borrowed from i.e. Semco and St Luke’s and rationalised via Transactional Analysis. By which I mean that we wanted a community where everyone could learn how to relate to each other as adults. Who can know what someone’s income / salary / fee needs are better than that person themselves? Indeed, can anyone ever have even an inkling of the personal circumstances of someone else? If not, how could it ever be possible to meet those needs?

Kit

Everyone was free to choose their own equipment, supplied by the company if that’s what they wanted (needed). They were also free to choose their own development tools (editors, repositories, etc), hours of working, and place(s) of work. Whatever best met their individual needs.

Reflections

With the benefit of hindsight, I can see some close parallels between the policies we evolved at Familiar, and the precepts of Nonviolent Communication. I feel sure that these parallels – and in particular the almost accidental focus on folks’ needs, and their subsequent making of requests – contributed much to the wonderful working environment and sense of community at Familiar.

I believe too that the policies described here are the natural evolution of the basic idea that is McGregor’s “Theory Y” (not that we had any managers in Familiar).

– Bob

Further Reading

Open Minds ~ Andy Law
Sociocracy – Wikipedia entry
Holacracy – Website
Holocracy – Definition

Bioteams

January 5, 2013
Agile, Organisational effectiveness, Snippet
Leave a comment

Bioteams

I just stumbled over the Bioteams website, and in particular their Manifesto. Although the concept seems more relevant for teams than organisations, and overlooks more organisation-wide (systemic) issues, I thought it might be useful to repeat an excerpt:

Free Will And Beliefs In Human Teams

How we will act is influenced by the beliefs we hold regarding the situation we find ourselves in when we receive the stimulus. For example, if I do not feel I am being adequately supported or appreciated by the rest of the team, I may avoid action where there is a perceived risk of my failure.

Alternatively if I felt fully supported, I might take bigger risks. In simple terms — human teams have to address the critical issue of team member motivation whereas biological teams do not.

Effective bioteaming cannot be achieved in an organisational team which is suffering from poor motivation.

This is why to be really effective a human bioteam must also take into account the team beliefs and the motivations of its highly intelligent and autonomous members.

The Impact Of Individual Team Beliefs On Overall Performance

Unfortunately there is very little research about the impact of team member beliefs on overall team performance. The only study which partly addresses this issue is the unique work on “Learned Optimism” by Professor Martin Seligman.

Dr Seligman is a clinical psychologist who for the last twenty years has studied the areas of learned optimism and learned helplessness to help individuals deal with depression and pessimism in their lives. As a sub-topic within his research Dr. Seligman has explored how optimism and pessimism in team members impact the overall team performance.

According to Dr. Seligman’s research, optimistic teams will recover more easily from setbacks than pessimistic ones; this does not vary with differing levels of team members’ skills and intelligence.

Uncovering The “Hidden Beliefs” Of High Performing Teams

From what we have been able to find there is no other research in the public domain which directly looks at the beliefs of team members in high-performance teams.

There is however excellent material on the detailed characteristics and behaviours of high-perform- ing teams — two of which are Hot Groups and Organizing Genius.

According to our own personal experience and the research we have carried out on this topic High Performing Teams (HPT) are immediately identifiable by the tacit, or hidden beliefs by which their general behaviour and attitude is determined:

[…]

Good Beliefs Make A Team Work Harder

One of the main consequences of nurturing a team to develop a deeply shared set of beliefs is a greater commitment and will by individual members to put in the necessary amount of work for the project to succeed.

If the team feels trusted, it acquires self-confidence and adopts a meaningful and responsible attitude toward realizing the mission successfully.

Bioteaming Includes Identifying Your Team’s Beliefs

In this context the first step to an ambitious virtual networked business team is to try to honestly identify the current beliefs that each individual team members holds. Next, this set of beliefs can be compared with the seven “hidden”, high-performance beliefs reviewed above to identify the most appropriate team motivational drivers.

As is true for all beliefs, people can only be encouraged to modify them. It is next to impos- sible to mandate their change unless it is fruit of an individual conscious and voluntary deci- sion. The most powerful techniques for modifying beliefs are those that excel at illustrating the consequences of existing beliefs while showcasing the profiles and characteristics of alternative ones. Such responsibilities would generally fall under the responsibility of senior and more experienced members of the team.

A human team operating in harmony with such principles, utilized by many of nature’s most successful biological teams, would be able to operate as an ultra-high-performing team, or as we like to say as a “human bioteam”.

– Bob

Nonviolent Project Management

January 2, 2013
Agile, Dialogue, Organisational effectiveness, Product development, Software development
4 Comments

Nonviolent Project Management

Some eighteen years ago now, I started using a technique I named “Stakeholders and their Needs” – as part of my approach to managing software development projects. I’ve found it a useful enough technique to continue using and evolving it on just about every endeavour I’ve worked on since then.

Aside 1: There’s a paper describing this and other aspects of the whole approach – which in its early days was called “Jerid” and more recently has evolved into “Javelin”.

Aside 2: This was all long before I became aware of Rosenberg and Nonviolent Communication, or even paid much attention to e.g. Gandhi and the general idea of nonviolence.

Aside 3: As in some other posts, I’m leaving to another day the contentious question of whether we should even have “projects” in the world of software and product development. And whether “Project Managers” should be doing the management of said projects.

Aside 4: I recognise that managing a project is about more than just ensuring that the right thing gets built. But given that so many projects fail in this key regard:

  • Poorly defined applications (miscommunication between business and IT) contribute to a 66% project failure rate, costing U.S. businesses at least $30 billion every year (Forrester Research)
  • 60% – 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)

Source:
Software Project Failure Costs Billions. Better Estimation & Planning Can Help

I posit that anything that can help us ensure we are building the right thing has significant value.

Before Requirements

I had, for some years before adopting “Stakeholders and their Needs”, come to see the benefits of a clear and shared understanding of the pertinent “requirements” for a project. And the benefits of evolving those requirements (and their clarity and the shared understanding) as the project progressed, by means of e.g. early and frequent delivery of both working software, and of the interim work products, such as the list of stakeholders and their needs, described here.

But I had also come to see that it was more or less a matter of chance whether the right people got involved (as “stakeholders”), whether they had the inclination or support necessary for them to engage with the project, and particularly whether they understood the formalisms of  the requirements models. Most of all, perhaps, was the key question: “How likely is it that the people who would benefit most from understanding what the project was doing – how it was going to meet their needs, and when – could actually understand those things?”.

The answer then – and I suspect, quite often even nowadays – was “Not very likely”.

So it seemed that some less formal, more easily shared, and understood, articulation of what the project was trying to achieve might be useful. And it seemed handy to have a (prioritised) list of the folks the project team needed to have conversations with about needs (what the team, and the stuff they’re producing, should do).

Thus “Stakeholders and Their Needs” was born.

Here’s a simple (abridged) example:

NameGroupRoleNeedsContact
David HainsCorporateHead of Development
  • Improved organisational development capability
  • Weekly face to face status report
  • Daily RAG status update
555-1234
Personal
  • No surprises
  • No calls when on holiday
Charlene SmittsProgramme OfficeProgramme Manager
  • Clear visibility into project progress
  • Advance notice of any and all resource changes
555-6661
Betsy DoohanProject TeamProject Manager
  • Enhanced reputation as a PM
  • No late nights
555-8882
Charlie WattsProject TeamDeveloper
  • Making a difference
  • Improved C++ coding skills
555-2313
Personal
  • Pay rise before September
Bill HarlanMarketingProduct Owner
  • Ground-breaking product
  • Long-term product success
  • Happy customers
  • 25% market share before Xmas
555-1022
Personal
  • Promotion to Head of Products

We can have other columns too, such as “stakeholder priority” or “email address” – whatever the project team and its wider stakeholder community find they need.

This technique allows everyone to see what everyone needs from the project. When needs conflict – as they inevitably will, from time to time – folks can see the conflicts and move to resolve them. Of course, if some folks are unwilling to disclose their needs to the group, then some needs may go unseen and thus, possibly unmet. This points to the advantages of a climate of dialogue and trust, where folks feel comfortable enough to share their real needs with each other.

And, crucially, the project team and its external stakeholders have a fairly clear, albeit broad-brush, comprehensive, comprehensible and topical statement of what “success” looks like.

Additionally – for those folks who seek such things – this approach affords traceability, from the list of stakeholders and roles, through their various informal needs, and thence to the more formal requirements (Use Cases, User Stories, Quantified Quality Objectives, etc.), and eventually to the outputs/deliverable (e.g. the system components in production).

The Nonviolent Dimension

So, from its inception, this technique, with its focus on needs, turns out to be pretty much in line with the fundamentals of Nonviolent Communication. I suspect that’s why it has proved to be of such enduring benefit over the years.

One further change, now I better appreciate Rosenberg, would be to see if the addition of an “Actionable Requests” column would offer some benefit. Actually, I wonder if a “Feelings” column might not provide some benefit, too. Although I can appreciate that for the vast majority of e.g. Analytic-minded organisations out there, talking about and sharing feelings is even more challenging and uncomfortable than sharing one’s needs.

And this approach also offers a way to take the coercion and violence out of the relationship between the Project Manager (if the project has a person dedicated to that role) and the development team. Given that the team (they’re stakeholders too!) can see everyone’s needs, they have the information they need to make everyone’s lives more wonderful. Violent tactics such as coercion and obligation only get in the way, and are conspicuous by their incongruence, here.

Indeed, the same goes for all the relationships pertaining to the endeavour.

Afterword

This technique is at the root of my approach to “Covalence” – the discipline of ensuring that any endeavour delivers the necessary value to all its stakeholders.

– Bob