Feedback: victim or beneficiary?

Feedback takes many forms, some is explicit and some can be inferred, even the absence of interaction is a form of feedback. Some if obviously well-intentioned, and some less so, some is invited and some is thrust upon us.

When you accidentally cut someone off in traffic, the feedback they give may be in the form of a horn and a hand gesture.  There is no question this is feedback, it may even be useful when you have stripped away the anger and your defensive response – I did after all miss something, they are helping me see something I didn’t see myself and now I will at least have the option of improving my behavior in similar situations in the future.

boston-road-rage-1024x683

Improvement is MY choice

Please note the word ‘option’,  the decision to change my behavior is mine, I can choose whether I respond or how I respond, giving a peer feedback does not compel them to change the way you want them to, regardless of how forcefully you may give the feedback.

Many times you will receive conflicting feedback, or sometimes you just disagree with it. When someone gives you feedback and they are asking you to change behavior remember it is you that needs to change and there is no one Youer than You.  It is up to you, you can choose what or whether to change.

you-have-brains-in-your-head-you-have-feet-in-your-shoes-you-can-steer-yourself-any-direction-you-choose

A Feedback Culture

I work in an organization where there is a very strong culture of self-improvement and professional development, but there is also a distinct absence of management, we therefore rely heavily on feedback from our peers. Our internal processes encourage formal and informal peer feedback.

In an Agile community we rely heavily on feedback loops for improving our processes, stand-ups, demos retrospectives, not to mention the metrics we encourage in our development practices. These are all opportunities to respond to the feedback as a team to help us improve.

Peer Feedback

However, individual feedback from peers is much less structured and much less objective so it becomes much harder for the giver or receiver to be objective in the way they give or receive the feedback. Peer feedback is by nature personal and when things get personal the stakes get higher. We give feedback in a subjective way, and we receive and we respond to feedback in a subjective way, both are cursed with perspective.

Ostensibly the goal of feedback from the perspective of the giver is to affirm behavior we approve of (e.g. clapping and cheering) and to discourage behavior we dislike or disapprove of (booing).  Context is also a factor we may be motivated personally or professionally.

For the receiver of feedback it is ostensibly to aid us in seeing things we are unable to see, to gain another person’s perspective on something. We may get to see things we can’t or don’t see for ourselves e.g. Am I speaking too quietly.

Whether the feedback is invited (“Can you hear me?”) or not (“Speak up!”) we are benefiting from another’s perspective on a situation.

Attitude

Sound’s great! But the attitude of the giver and receiver play a much more significant role in peer to peer feedback, and in how effective or valuable that feedback is, and what the consequences on the relationship are.

Let’s go back to the person I accidentally cut-off in traffic. Whilst there is benefit in being reminded that I need to pay more attention to my blind-spots I doubt very much the person cut-off and is giving me hand-gestures was overly concerned with my personal development or in helping me become a better driver.  The reality is that their goal was not to help me improve, it was to vent their frustration, to express anger and to feel better in themselves by ranting at me, my welfare was not even remotely the concern.

And so it is with peer feedback, there are times when I really want to express my opinion, I don’t care whether the person improves, what matters to me is that I get my say and I can express MY feelings.  This can come off as spiteful rather than supportive. and leave the person feeling a victim.

Victim or Beneficiary

The “feedback culture” has created an opportunity for some people to express a desire to ask to “give feedback” when really they are taking an opportunity to give someone a piece of their mind in a situation where the ‘victim’ feels they cannot respond. By calling it feedback we get a free punch and if they react badly or refuse to be verbally punched we can claim they are not acting in the spirit of feedback.  I worry this is damaging our culture and is a misappropriation of feedback, the result is the artificial harmony we were trying to get away from. Dressing an attack up as feedback does not change it.

bully

Before giving another person ‘feedback’ we need to reflect on it ourselves and consider whether our true desire is to help the person improve. Do we truly desire the subject to be the beneficiary of our feedback or is the act of giving feedback more about satisfying your own need for satisfaction and they are just the victim of your feedback.

Spirit of improvement

Please understand that I am not saying that the horn and the hand gesture are not feedback – clearly they are. Nor that I can’t respond to the feedback and improve. It is a question of the spirit of the feedback as much as the  message itself.  If I feel the feedback is given in the spirit of helping me I am far more likely to respond favorably, if I see the feedback as a veiled attack I am as likely to resent the message and in some extreme cases I may retaliate – I am less likely to see it as an opportunity for improvement.

Is your true desire is to help the person improve or do you want to make them feel bad? Do you want a good relationship in future? Then perhaps be more considerate of your approach.  We all make mistakes, and we can all improve so let’s make the effort to be kinder in our delivery of the message – not necessarily the subject. Feedback needs to be clear and should not shy from difficult issues but the delivery can make all the difference.

TRUNK Test

When we rely so heavily on relationships and on feedback it is important to apply the TRUNK test for offering feedback:

Is what you are about to say TRue, Useful, Necessary, and Kind?

 

 

 

Advertisements

Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

download (1)

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance.  Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

andon

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose.  The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

devops

The difficulty in many organizations is that senior management hide behind an open door policy.  “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot.  In many cases the fear is justified,  but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door”  is not that open.

opendoor

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.

 

 

 

 

 

 

 

 

For the public good…

I am continually fascinated by the notion of self-organising teams, how they motivate themselves and how you can create an environment that is conducive to self-motivation.

Unfortunately my experience is that self-management works for the minority and is highly rewarding and highly effective, but it does not work for all. Bystander Syndrome is prevalent and too often the plants do not get watered. Why don’t developers water the plants?

So, recently I ran an experiment and discussion on the general low involvement and engagement of extra-curricular activities. In particular events that are considered to be core to the effective working of the company but are not explicitly part of your core objectives.

The premise of the experiment is that we have become more focused on benefit to ourselves or benefit to our local teams, rather than the benefit to the wider organisation.

img_0447

For those out there ready to point out that an experiment requiring voluntary attendance already excludes those that are more focused on themselves – you got me!
I stacked the deck in favour of the more social minded of the organisation.

Some examples:

Our organisation is very much built around self-organisation and we are expected to manage our own time and priorities.  However, we have a number of activities that are ‘global’ in scope: some where the time spent is voluntary and expected to be worked above and around billable time.  Or facilitating other team’s retrospectives which is billable time but can conflict with your primary team priorities. Even our Guilds, which are groups of people based around a single focus or competency have an implied ongoing commitment to attend regularly.  Finally, “Lunch and Learns” or bookclubs where there is opportunity to share ideas and learn from colleagues, which is a core cultural goal of the organisation but is done as part of your personal development and on your own time.

All of these activities could be considered to be valuable to the organisation and in most cases to you personally (directly or indirectly), but all require an investment of time and effort. My observation is that in many cases the involvement is diminishing either proportionally or absolutely as we grow. Attendance at lunchtime events seems to be diminishing, involvement in volunteer groups like guilds is a challenge to the organisers and maintaining membership is probably the number one challenge.

The goal of the discussion was to identify ideas for how we maintain or stimulate these activities and how to involve a wider audience, preferably without putting a greater burden on a few (and often the same few people), and without directing people to attend, which is counter to our culture.

The Game….

We played a game loosely based on the ‘Public Good Game’ We set up two relatively large groups. All participants were given $10 each and the game is played in rounds.
Each round players can contribute as much or as little as they like to ‘a pot’ but the total contributions will be combined and then a pre-determined bonus would be added to it. One team got a 30% bonus the other team a 40% bonus.

Round 1

All players were asked to choose how much to contribute, in the 30% team the contributions were visible, in the 40% team the contributions were secret.

If you apply pure logic, the maximum gain is obtained by everyone contributing fully, that way everyone gains a lot.  But an individual can work out that by opting out and reducing their individual contribution they can benefit at the expense of others.

Subsequent rounds…

Over the course of a number of rounds as more and more people realise that others are not contributing fully, they will either call the others out for not contributing, OR they too opt out and eventually those that are still contributing receive back less than they contribute and at that point system fails as everyone eventually opts out.

End Game

What we found was that the transparent team reminded each other and kept the focus on the public benefit and maintained a better contribution level, the secret contributions team had two or three participants who were able to benefit considerably at the expense of others  by not contributing (leeching from the pot). There was sufficient reward to keep the others motivated although that was diminishing each round.  Overall it was the transparent team that benefitted more, but both teams missed out on a huge amount of potential benefit by a focus on personal gain.

Conclusion

In the recap there was a suggestion that it was unclear whether the goal of the game was for collective gain or individual gain – e.g. How did we measure the winner?

But the reality is that this is the same quandary that we face in our day to day life,  are we working for the benefit of ourselves or our team or our company?  All our choices for extra-curricular activities are an investment of our own time and effort and we are motivated either for personal gain (what is in it for me?) or collective gain (How would me attending benefit my team/company?)

Discussion

Many of the arguments we heard were around billing, and utilisation. There seems to be a reluctance to use personal time for ‘extra-curricular’ learning, which implies that there is a perceived lack of sufficient personal benefit from involvement in these activities.

In other cases such as facilitation and helping other teams people are balancing time spent with their local team against involvement in activities that benefit a wider group.  The question is… Which is more important?

The challenge for us then is how to change priorities such that activities that benefit the company as a whole are perceived as valuable (not necessarily more valuable but valuable enough to make that effort), or to highlight the benefits to us as individuals resulting from a greater involvement in company wide activities.

The conversation that followed created some great ideas, as well as highlighting some of the concerns.


The Dunbar number

Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships.

Dunbar’s number on Wikipedia

Dunbar has a theory that as groups exceed a certain number approximately 150 people their sense of community diminishes and the group becomes less effective, less cohesive and it is more difficult to self-organise.

Many of the issues raised could be interpreted to have their root in the Dunbar number.  As we grow we don’t personally know the other people that are presenting at LnLs or the others that are attending the guild meetings. This lack of personal attachment results in a diminished sense of interest, ownership and responsibility, skipping is downplayed as it is only letting down people you don’t know, or an assumption that others will attend.

Ideas for increased engagement

  • Offer food
  • Educate people on calendar etiquette, e.g. show up if you accept
  • Increase advertising/promotion of events and activities
  • Write up a “What you missed” summary for those that didn’t attend
  • Leaders show support by attending,
  • Reward directly or indirectly those that present and/or attend
  • Make clear the purpose or learning goals of events
  • Introduce compulsory lunch breaks, or compulsory attendance
  • Highlight the understanding/visibility of what happens when you don’t step up
  • Identify Champions to help organise and promote these activities
  • Have fixed times/days for lunchtime activities to regulate number and ensure quality.
  • Invite only those from a sub-group (accept Dunbar’s Number and work with it).

Our goal with this experiment was to gain ideas and gain a better understanding of the problem and to share these concerns with a wider audience, we were not aiming for a solution to the problem just a start to the conversation.

Feedback?

Any more thoughts or ideas on this would be greatly appreciated

 

 

The Zone of Acceptance

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a direct confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours and core responsibilities.

However, when you move to agile it becomes much harder to deal with. We introduce the concept of self-management and self-organization, there is no longer an external person pushing you to extend your boundaries.

change

What is my Zone of Acceptance?

In my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife will in a ‘matter of fact’ tone reply – “That’s your job!”  I don’t doubt that it is, at some point we agreed a division of responsibilities – , the responsibility is clear.

But conversely my behavior in a different situation is far harder to manage. My wife may ask me to change our child’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying that.  She can ask on a regular basis but that in itself undermines the equality and self-organizing nature of marriage, she shouldn’t need to ask. We have an understanding that generally works and in this case the reality is that she is not asking me to take the responsibility, nor is she demanding assistance, but my help is certainly appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support. We are a team.

That is not my job

The same becomes true in an Agile team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that over the wall to a tester” or similar comments, they can be directly challenged, and the coach or the other team members can act accordingly. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the board to avoid picking up a card that doesn’t fall into their zone of acceptance.  This behavior may not even be visible, a team can actually become very productive in the short-term by forming mini-silos, but that doesn’t make it right or healthy in the long run.

I see the role of a Coach (or any Agile minded team member) to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and to be active in all meetings, to volunteer to write documentation and present the Demo, and to challenge those that don’t become active members of the team.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code syntax itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries. In the long term I’d suggest those roles should become indistinguishable from each other and in an ideal world they would be one and the same – a team member who would do what they could and what was needed.

Jack of all trades

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing; coding and design etc. are very different skills and expertise in each should be valued. But my view is that the comparison of skills needed to get a user story to ‘done’ will often form a huge amount of overlap and likely a combined involvement.

purple jigsaw

If each user story represents a piece in a puzzle, chances are that there are a few parts that will require a specialist in ‘Blue’ or expertise in ‘Red’ skills, but the majority of the work is shades of ‘purple’ something that does not require particular expertise  and could be achieved by anyone on the team or through a mix of people. We often use edge cases as examples so we can dodge the normal cases, when we see that we should call it out.

How do we expand the Zone of Acceptance?

But now what? We understand the problem, we know it is hard to spot and hard to challenge, so how on earth do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognize it as a problem too.
Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than looking for the easy way out for themselves.

One team I work with identified this problem for themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a story the team member would stop and think:

  • First whether they were taking a task that someone else could take and learn – or maybe they could pair and teach someone else to share their knowledge;
  • Secondly “Is this the next highest priority or am I taking an easy option?  Some team members will cherry pick from the backlog rather than taking the highest priority item.

By having a written reminder it can become a challenge at stand up. The team members can call out each other if they see either of these behaviors.

Great Team Players

This barely touches the surface of this particular problem, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team – and even better what is most valuable for the customer.  And more significantly for this to be supported and encouraged by the team and the organization as a whole. Too often the organization rewards ‘star developers‘ rather than great team players, that message reinforces bad behavior and can be extremely corrosive to the organization over time.

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

or

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

Related image

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more.  No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner.  But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

1cf58fa9895dafded2997558ab348190

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

cropped-serres-view-4.jpg

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity.   And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

 

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Leadership

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in.  I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

 

 

 

Why don’t developers water the plants?

Bike-shedding, Bystanders and Boredom:

I have a theory that in the context of self-organizing teams in a business environment, there are zones of diminishing responsibility and thus the effectiveness of self organization as the tasks get further from the perceived core purpose of the team or individual.

That is to say that a self-organizing software development team may have little difficulty organizing how to create a feature in their product, but may struggle to water the plants or empty the bins in their Team area.

9f0ddaf84c621256fe3f01a6eedf29f9

Background

We as an organization have embraced Spontaneous Order (self-organizing teams) and have adopted a variety of Holocracy, the result is a pretty large organization (Approximately 400+ people) with almost no management outside of the core leadership team of four.  The results are fascinating to observe, in some cases wildly successful and in other cases not so much.

Teams are created for a defined purpose, most often this is a defined project from a client, the composition of the team is decided by one of the leadership team based on personal knowledge of the skills of the prospective team members. This is obviously a limitation of scale and requires an exceptional level of knowledge of the available people. Clearly it is not self-organization in the context of team creation but this is the extent of outside influence for most teams (unless they have problems). The teams are expected to self-organize to deliver on their defined purpose.

Defined Purpose

For the most part they do very well and are able to deliver high quality software, interact effectively with clients and have a reputation for being the best in the custom App development business.  Although there are a few internal difficulties, such as a tendency for excessive bike-shedding* early in projects, and for a few individuals, especially the stronger personalities to shape the teams to enable them to do the work they like relying on the others to do the rest.

Similarly strong personalities can limit a notion of continual improvement, that is to say that strong personalities can instill pressure to stick with what worked previously rather than being open to improvement.

Those are problems that could be explored further but for today my interest is in observing how wider organizational responsibilities or team responsibilities that are perceived as distant from the defined purpose get lost, ignored or simply take far longer than they should to get done.

*Bike-shedding (or Parkinson’s law of triviality)

Way back in 1957 Parkinson observed that members of an organization give excess weight to trivial issues, spending a disproportionate amount of time discussing issues that everyone has an opinion on (in his example it was the the building of a bike shed), this discussion was at the expense of more important issues that were outside the domain of expertise of the entire group.  In other words people contribute because they ‘can’ not because they ‘should’.

In my observations this is a MAJOR problem for self-organizing teams, the choice of electronic Kanban board is my favourite pet hate on this, the amount of time spent deciding on which tool to use or which columns to include, or future discussions about whether to add or remove a column is astonishing, these same teams will spend hours on these topics but will then declare a story writing activity unproductive if the quantity of stories written in an hour is below an arbitrary number, regardless of whether the discussion was effective in identifying details valuable to getting a feature right.  Please note I am not suggesting that the decisions about tools or workflow are not important, just that it should be proportionate.

To remedy this self-organization may need a helping hand, a facilitator to keep the group focused, or to redirect in the face of bike-shedding.

Structure vs Empowerment

I often hear people talk about not wanting a framework imposed on them (e.g. Scrum) or “wanting to find their own way”. But in my observations many do find themselves with a workflow that would be described as Scrum to an outside observer.  The concern I have with this is balancing the freedom to find your own path – allowing teams choose their path, balanced with the waste involved in teams repeatedly churning for weeks on end or longer until they find the path which is ultimately very similar to what would have been prescribed in the first place.  Is it wrong to build on past experience by suggesting a proposed framework structure? Is it empowering to allow teams to repeatedly re-invent the wheel? I am oft told that it is empowering for them, but I wonder if they would feel the same way if they were paying the bills?

This applies to other parts of the organization too, it is all very well when entering a restaurant to be offered no menu and told to order anything you want. But when faced with that how many would feel imprisoned by too many unclear options, how many would rather have a menu and feel empowered to stretch it a little asking for tweaks or combinations, in other words having boundaries that can be pushed.

fencing

Observations of children playing show that if a play area has a fence they utilize the whole area, but when the play area has no fence the children cluster close to the center with each other.  In our subconscious we are more daunted by the lack of boundaries, but when we have them and feel safe and empowered we will push at them.

In retail, studies show that customers faced with 6 choices are 15 times more likely to make a purchase than those with 24 choices, too many choices confuse and frustrate us and so we regress to safety which is to NOT make a decision.  The same is true in our business life, we become overwhelmed with choice, constraining options is empowering not limiting.

The three layers of self-organization responsibilities

The teams will generally have activities and responsibilities fall into three camps, either trivial issues get blown up in to long and largely pointless debates that drag on, more complex issues get glossed over leading to problems later and finally there are certain responsibilities that get overlooked or dismissed as unimportant or out of scope of the team.

Self organising hierarchy

Primary Tasks

These are tasks that are clearly and directly related to your role on a team and directly related to achieving your team’s goals and objectives.  In the case of a developer this may be writing code for specific user stories.  Please bear in mind that a named role such as Developer or Quality Advocate or even Product Owner may imply certain responsibilities are theirs rather than the team as a whole (I am observing this not endorsing this)

Secondary Tasks

These are the tasks that the team are responsible for but may not be perceived as core for the individual, again in the developer’s case this could include organising meetings, testing or writing stories or deploying or… well you get the idea.

Tertiary Tasks

These are tasks that need doing and are essential to the function of an organisation but are outside the explicit responsibility of the team such as: emptying bins, washing dishes, watering plants. Or less trivially ordering stationery, updating company web pages, ordering IT equipment and so on.

Exceptions:  There seem to be two exceptions to these layers, the first is if a task in any of the layers is perceived by the individual as interesting or rewarding in some way, in which case the layers can be overcome, the other is when someone of authority (including peer pressure) explicitly assigns responsibility to an individual or small group which elevates the task to a Primary task.

Bystander Syndrome

Bystander syndrome is a phenomenon of anthropology where the more people are responsible for something the less responsible the individual feels.  Sadly this syndrome is the reason that self-organization so often fails. Why in small teams or small companies things work well but as they grow this attitude slowly creeps in until one day there is a pile of dirty dishes in the sink, un-emptied bins, and someone has stolen my chair because their’s is broken and it was quicker to take mine than order a new one*. (*imaginary scenario – honest)

These minor annoyances are the start of the breakdown in your corporate society and the warning signs that self-organization has reached it’s limit.  To keep things running new roles will need to be created to make people explicitly responsible for these Tertiary tasks. In short you will no longer be self-organizing someone will need to lend a discrete hand, to enable self-organization to continue where it really matters.

Summary

Essentially these are growing pains, the result is what can be best described as a failing of human nature. The tasks that get the most effort and attention are those that fall in the sweet spot of being close to the core purpose of the team, are trivial so that everyone has an opinion, and are interesting or appealing or have clear ownership.   The tasks that get ignored and overlooked are those that whilst important or necessary in the grand scheme do not map directly to the core purpose of the individual, are uninteresting, or have no clear owner.   For these self-organization wont save you, a helping hand (or a gentle prod) is needed.

Providing self-organizing teams and people with boundaries and structure and for our leadership to have an understanding and acceptance that we thrive best when we know our boundaries makes for a safe environment to grow. We will push at those boundaries mercilessly if we feel safe. But don’t be surprised if the plants don’t get watered unless you assign the job explicitly!