Month: May 2017

Is culture observation or aspiration?

There has been a lot of talk recently about culture and it’s importance when creating organisational identity,  but there are two ways I see for an organisation to create a culture.

A short story…

I was once told a story of how the British and US army engineers take two different approaches to footpath planning when creating their bases.

Flag_-_Union_Flag

The British planned in advance and they laid the footpaths to a defined route and the soldiers were required to follow the specified paths, and were corrected if they didn’t.

71X+wfQBpKL._UX385_

The US engineers on the otherhand would delay laying the footpaths until the base was in use, they would observe the routes taken and where the soldiers walked and would lay the paths when the preferred routes were clear.

The belief (or so I was told) was that people will find the most efficient route on their own.

Each has it’s own merits, and is itself likely a reflection of the culture of those two organisations.

A deliberate culture or a reflective culture

I see this as being very similar to a company’s culture. You have two main choices: either you decide the culture you want, you lay it out and then make decisions that reinforce the path you set. This means hiring practices, rewards, punishments, recognition, and everything in between, you continue to do this until the normal behaviour is to follow the path set.  Your culture is by your design. But to get the culture you want requires a lot of correcting of behaviour until it happens.

Or the alternative is to wait and see, behave the way you behave naturally and the same for the others around you, soon enough a culture will form and it will be a culture that reflects the way you behave. The good news is this is your real culture, the bad news is – this is your real culture.

There are problems with both of these, choosing a deliberate culture that goes against some of your natural tendencies or is unrealistic can lead to it not being followed and the result is that you claim one culture but actually have another, this can be very damaging especially to those that believe in the defined culture.  If you follow the rules but others get ahead by other means it can be corrosive.  A lack of defined culture can also bad as there is no safety check on poor behaviour, left unchecked it quickly becomes the norm and then it becomes your culture, which is the case for women in IT.

Women in Tech

One great example could be seen with Women in Tech, where most companies would say their culture does not set out to exclude or marginalise women, but without a deliberate culture to seek out diversity we have allowed the lack of diversity to become the normal state and for the culture to be one that unintentionally discouraged or excluded women. Often evolving from small companies that have grown by surounding themselves with like minded individuals. Unconsciously biased towards those similar to them.  It will take time and effort and a deliberate culture to break through some of those barriers we have created over the years.

But this is seen in all aspects of an organisation, if your culture tolerates something for long enough, maybe because it is easy to ignore when small, it can become a much larger issue when you grow.  If you are not explicit about the culture you want then you may not be able to shape the culture you have. In larger organisations sub-cultures can form in different areas and this can be even more damaging, without a clear global culture factions develop and the inconsistencies undermine the larger whole.

Agile Transformation

One of the reasons that Agile Transformation is so hard is because it is a culture change rather than a process change, you are defining a new culture and that will not happen overnight. All the previous actions that were normal, the rewards, the metrics the measurements are very hard to undo.  Empowering people to be self-organising when they have only known command and control will take a while to adjust.  I believe this is why so many agile transformations are unsuccessful, some processes are changed but there is no desire or will to change the culture, there is a general wish to change to Agile without actually changing.

The solution

The solution in my opinion is to do a little of both.  Be aware of the culture you want and be explicit about it, shout it from the rooftops, and repeat it and repeat it and repeat it, until everyone in your organisation knows you mean it and you believe in it, be clear where you aspire to be. This will still take a very long time to have impact.

But also be aware of where you are now, the unwritten culture you have now is just as strong and just as real. Be especially aware of the behaviours that your culture currently has that you are not happy about.  If you are honest about your weaknesses and failings you have a far better chance of changing. Seek out and coach those that are not behaving the way you aspire to be, remember they behave that way because it is your culture.

Culture change wont happen overnight but that doesn’t mean you shouldn’t be intollerent of any behaviours that don’t reflect the culture you want.

Do you know ‘what’ your problem is?

The title is a little tongue in cheek, because in my experience it is the ‘what‘ that is likely your problem. We focus far to much on what we are doing both in our work and in our product, and far too little on why we are doing it.

Failing to understand the why

The obsession with local efficiency and and maximizing utilization of people is crippling customer focus and value.

There is nothing so useless as doing efficiently that which should not be done at all.

Dr Peter F. Drucker

Peter Drucker has some very inspiring quotes but that one is by far my favorite and one that I wish was better understood and adopted in practice

shakespeare-quotes-9-1024x540

We look for work to stay busy, whether it be setting up grand databases or magnificent CI solutions. I am not saying either is unnecessary, but does the solution fit the need? Were they built when needed or in anticipation of a possible future need?

The focus on lead/cycle times can result in stories becoming rushed, the focus becomes on getting work ‘done’ as quickly as possible, rather than a focus on getting the work ‘done right’. We are completing work quickly at the expense of adding value.  It also leads to ‘creative accounting’ where the desire to reduce cycle times results in the definition of done getting corrupted.

Refactoring gets sacrificed when throughput is the priority.

Stories focus on the what not the why.

We are often in such a rush to complete we either skip the why entirely or we take the easy route and look for a ‘why’ that satisfies our ‘what’  rather than actually asking why or giving it proper thought and effort into understanding the real why.

Of course the “Why conversation” can be hard, or time consuming and sometimes it seems obvious but can be hard to articulate. Story writing is a time consuming process but when the process becomes rushed there can be a tendency to prioritize stories according to what is written or what is easy to write rather than what is the next priority based on value or other prioritization methods.  We tend towards keeping people busy and the process flowing rather than ensuring we are delivering value and working on the right thing.

It is far too easy to get into a cycle of business as usual, all the time running to catch up but not really knowing if you are working on the right thing. But because everyone is busy and something is getting done “Asking why?” drops below the radar and the hard question of value does not get asked.

stoneage

Step back and evaluate if you are working on the right thing. Sometimes going slower is actually going faster.

Taking a little while to do it right could well pay dividends.  Our goal should be to give our customer the most value, not maximize how busy we are. And whilst logically these two should be related, in reality the opposite can be true.

Learning to write good stories with an emphasis on understanding the why this story adds value, learning to prioritize with the emphasis on why this story is the one we work on next can make a huge difference to a project delivery.   Incorporating story maps; road maps, story boards and utilizing other prioritization techniques can help your product deliver the right thing.

The customer should be your focus

Your product owner should be able to articulate clearly and confidently why the next story is next and that justification should be customer centric. Your goal is to make the customer happy NOT to keep your team busy.

When lead/cycle times start to become more important than refactoring it leads to a degradation of the system, either in terms of a reduction in the quality of the code, or an increase in technical debt, but more often a reduction in quality of the user experience.

UX is an afterthought

When we teach story writing we teach the INVEST method, the I is independent, and V is valuable, but I wonder if the independent is misunderstood, especially when it comes to UX.  The goal of a story is NOT to minimize Effort, it is to maximize Value. Sometimes we can maximize value by minimizing effort (ROI: Return on investment) but our goal is still the value and NOT the reduction in effort.

The goal of a story is NOT to minimize development Effort, it is to maximize customer Value

A story that adds new functionality could easily be tagged on to the existing system with little redesign of what already exists, e.g. We add a new tab or a new page or a new button, just append it to what is there. In some circumstances this may be the right outcome, but it should be a conscious decision not a default lazy way out.

A new story that is adding functionality should be assumed to be incorporating that extra functionality into the system where it fits best for the user and maintains the user experience and flow NOT where it is the easiest to integrate by the developer.  If we just tag on new functionality without consideration for the user or the existing system it can quickly become ugly and cumbersome.  Sadly the prospect of changing completed work – especially visible work can be daunting and many teams are resistant to make changes to the UI, instead preferring to add new functionality where it is least disruptive.

Each new story especially UI stories should require some reflection and a conscious decision to maintain flow and look and feel and maintaining the user experience, maintaining the user experience may very well be more valuable than the new functionality adds.

Acceptance Criteria is a substitute for thinking and conversation

We can get so focused on delivering quickly and meeting AC for a specific story that we become blinkered, we know we need to maintain quality in the sense of stability, reliability and security, but we can easily forget about the less quantifiable quality of the user experience of the system as a whole. We can seek to address the acceptance criteria without thinking whether what you are doing truly adds to the value of the product (not story) and when A/C is specific we don’t question whether it is right, we skip the conversations.

images

Being busy is not your goal

It can be a very hard adjustment especially when you are paid by the hour, or even bill by the hour, for us to accept and understand that sometimes the most effective use of our time is not keeping busy. It may be to do something inefficiently or to not do anything at all.  Keeping you busy is not the goal, delivering the best product to the customer is.

If I were a painter, I…

Recently I have spent a lot of time talking about story writing, but this week the focus has been on Acceptance Criteria and there have been a variety of comments that have caused me to reflect and have caused me some concern.
Some examples:

  • Unless stated otherwise a story is assumed to be happy path only. If it isn’t in the Acceptance Criteria we don’t have to do it.
    • Acceptance Criteria must contain all details including all edge cases that must be tested, anything not stated doesn’t have to be implemented.
  • If all acceptance criteria are met the PO/Customer MUST accept the story even if they are not satisfied.
  • If acceptance criteria change before the story is done, it should be completed as specified and a new story should be created for the changes. after all, late changes to Acceptance Criteria demoralize Developers.
  • If Acceptance Criteria are unclear we can choose what to do.
  • The Acceptance Criteria should never tell us how to do the job.

A metaphor

To respond to these questions I thought I would use a metaphor – A homeowner wanting to redecorate her house.

img_0374

The home owner hires a firm of decorators because they have a reputation for quality.

Her first request is that the painter decorate the sitting room,  She would like the walls painted blue, the ceiling an off-white, the windows also off-white but the paint needs to be wipe-able to avoid finger prints, and the doors and trim should match the window color.

A story is an expression of a need

Acceptance Criteria are the notes from the discussion to help clarify the need

In this case the homeowner has specified a number of acceptance criteria:

  • Walls – blue
  • Ceiling off-white
  • Windows off-white but wipe-able paint
  • Trim same as windows

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner – in this case the home owner.

The acceptance criteria are details provided by the Product owner that would help the workman understand how to complete the job to the satisfaction of the Product Owner

The job can and probably should be broken down into smaller tasks (stories). Having just the windows painted has value, just the ceiling does too, just the trim and potentially each wall independently may have value although that may be harder to qualify with the Product Owner, depending on their needs.

Detail in Acceptance Criteria

What you will note though is that the acceptance criteria did not state that the areas to be painted must be professionally prepared and sanded, that a primer coat be applied and two top coats are applied.  They do not state that the carpets should be protected and that spills should be cleaned up and that there should be no paint on the glass and no wall paint on the ceiling, no ceiling paint on the walls or that the paint should fully cover the walls and be an even drip free finish.  In fact the Acceptance criteria make no mention of how the work should be completed at all.

Who is the audience of your Acceptance Criteria?

The Acceptance Criteria come from a conversation with the Product Owner, but you may also want to take technical notes from conversations with those that will do the work. E.g. if the contractor has an apprentice, it may be necessary to spell out to him/her the technical details mentioned above, what seems common sense to you and the Product Owner may not be as obvious to someone less experienced. But notes on implementation are not acceptance criteria in the same sense. The product Owner should not be expected to understand all the technical details, what is acceptable is always determined by the Product Owner.

If quality is not specified in the acceptance criteria

But that means I only need to worry about the happy path right? So I need to do a good job with the specified work but I don’t need to care about drips or mess or if I am painting the walls I don’t need to care about the ceiling after all I am only doing the happy path. I can ignore walls that are hidden behind furniture, I can do the job quicker if I don’t put down dust sheets and we can worry about cleaning up the mess later right?

Put like that it sounds silly doesn’t it, but that  is what you are suggesting if you don’t consider anything other than the happy path, the minimal amount is done but you are leaving a mess to clean up later.  If this is clearly understood and acceptable to the customer or that you have split a story like this to get feedback sooner there may be an exception but if you think that you can declare a story ‘done’ with a mess left to clear up later it is a recipe for a disappointed customer or a misleading impression that you have achieved more than you really have. Giving a sense of artificial progress may lead to disappointment later.

img_0376

Acceptance Criteria are comprehensive and exhaustive

If all acceptance criteria are met the PO/homeowner MUST accept the story even if the homeowner is not satisfied.   There is some crown moulding between the walls and the ceiling, it was not mentioned in the Acceptance Criteria and the decorator has painted it the wall colour, but the Home owner wanted it the same as the ceiling and thought it was obvious so had not mentioned it.  The decorator insists the job is done because the Acceptance Criteria are met.

This is actually a very common issue, Acceptance Criteria are often not comprehensive and there are ambiguities and omissions, so how do you handle them?  Assuming you are paying for the work on a time an materials basis the customer is the one that suffers, they will have to pay for the rework(or extra work), but it is generally the workman that gets frustrated, they believed they did a good job and so it is frustrating to have to repeat good work.   But the customer is not satisfied, and that should be the only thing that matters. Your goal as a quality workman is to satisfy your customer.  The job is not done until they are satisfied (assuming the request is reasonable)

It might be that the customer is willing to accept the work as it stands and agree to the repainting later. But more likely they will want it fixed before you move on to the next piece of work.

What is not acceptable is to refuse to make the changes because they were not explicit in the Acceptance Criteria.  The story card is an invitation to a conversation, the Acceptance Criteria are reminders of what has been discussed. At no point do Acceptance Criteria or the card become a sealed contract.

img_0373

Changes during a story

The painter is half way through painting the window and the Customer comes to check on progress. She sees the paint colour of the windows and decides it is too white, too stark and clinical and would like the colour changed to an off-white.  She understands that the rework will cost and the new materials will cost and she accepts this, but she is unhappy with the colour.

The painter responds: “But the thing is the A/C were clear about the colour, the shade was specified, I have spent a long time getting through the first half of this job and it is only fair that I finish it according to the A/C”  Then we can have a separate job to repaint it a different colour.  Frankly my metrics will look bad if this job takes 50% longer, it will look like I am slow. Do you know how frustrating it is to do a job and have it rejected..”

I have heard frequently how when a PO changes A/C the story should be completed as it is and a new story created for the revisions.  But any continuation on work that is not wanted is waste. The notion of continuing to work on something that is unwanted, and even worse billing the customer for that time, is just wrong.  If metrics are driving bad behaviour then the metrics are failing. If someone is demoralized because a PO has clarified their needs then they need to evaluate their understanding of Agile.   A full half of the Manifesto is:

Customer collaboration over contract negotiation
Responding to change over following a plan

If you are unwilling to accept and adapt to changes in A/C even late into development, then you really need to go back to basics and ask if you genuinely support Agile software development.  I am sorry if that sounds harsh but the notion that keeping devs happy and metrics pretty is more important than delivering the right thing for your customer is very frustrating for me to hear.

 If Acceptance Criteria are unclear we can choose what to do.

The homeowner has been pretty vague in her choice of colours, blue and off-white. So presumably we can choose whatever we want?

Clearly that is unrealistic.  What might be more reasonable would be to talk to the homeowner and say “We prefer this brand and type of paint and these are the available colours within that range can you pick one”   The homeowner may say, No I want a very specific Blue only available in this brand that needs to be imported from New Zealand.  In which case you should explain that such a choice will increase the cost and duration of the job and adds to the risk – being an unfamiliar material, it may need more coats etc.  If the homeowner understands and accepts those risks then it should be done, but if the homeowner can be presented with a less costly and less risky alternative then they may be willing to modify their request.

Ambiguity should trigger conversation it should not be an excuse for making assumptions.

Ambiguity should trigger conversation it should not be an excuse for making assumptions. The goal is a finish that the homeowner is happy with, the specifics are likely open to negotiation. But whilst you may present alternatives it is for the homeowner to make the decision.

Anything not stated doesn’t have to be done

There are two types of things not stated in the Acceptance Criteria that apply here, how we do the job and some of the specifics.

How: The Acceptance Criteria doesn’t explicitly say that we need a primer coat, but we know that for a quality job it needs to be done. The Acceptance Criteria doesn’t tell us which brushes to use, or how to paint to get a good neat coverage. The contractor may need to specify those to an apprentice, but the homeowner should not need to specify the tools to be used or how to do the job (unless that forms a particular part of the need)  You as the contractor may need to spell out those details to your apprentice, consider those sub-tasks of the story.  Prepare and protect work area; Sand surface, apply primer, apply first coat,  apply 2nd coat, clean up area, clean brushes etc.  But these are NOT Acceptance Criteria to be supplied by the home owner. They are about how to do the job not about the job that needs to be done. Sometimes these do overlap but generally we try to keep the how out of the request.

There are also some specifics that may not be mentioned, for example there is a recess around the fireplace but only 4 walls were mentioned.  Can I ignore the other surfaces?  Likely not, details may have been assumed, if there is doubt clarify with the homeowner. There is something fixed to the wall which is too close to be painted behind, but if not painted it would look odd. The Acceptance Criteria shouldn’t need to specify that you need to remove it and paint behind to do a good job. But again if there is any doubt clarify it with the homeowner.  The Acceptance Criteria will rarely be comprehensive and conversation will be necessary.

Specifics: The Acceptance Criteria should not specify how the job must be done

Normally we try not to specify how the job must be done, but there will be exceptions to this. The homeowner may have a need to decorate using traditional materials, and so may specify that particular tools are used – e.g. No power tools, no lead based paint. No synthetic materials in paint or tools.  Sometimes those requirements are not necessarily clear to you. The Customer may insist on 2 primer coats and 3 top coats.  Two more coats than you feel is necessary for a quality finish, but they insist are how the job should be done.  In those instances you may make recommendations or suggestions, and try to understand why they feel this is a requirement. But ultimately it is for them to decide – so long as they understand the additional cost and risk.

But again there are exceptions to this, for example the customer my request that you skip a primer coat and only apply a single top coat, or insists that you use low quality materials to save on cost. If you believe that this will result in a substandard job, then again you should explain your reasons and try to find an alternative and if necessary refuse to accept the job if you feel that the result would reflect badly on you.  Ideally it should be clear from the start what the expectations around quality of service are, but it may be necessary to re-clarify periodically if there is doubt.

Summary

  • In story terms, the story should express the need, what your goal is. It is the start of the conversation(not the end) for assessing how to satisfy that need.
  • The Acceptance criteria are simply notes to help remember that conversation, they do not form a contract.
  • Acceptance Criteria should never be considered absolute, immutable or comprehensive.  Uncertainty should be clarified with the Product Owner early and often.
  • You should respond to changes in Acceptance Criteria quickly, the quicker you respond the less waste there will be.
  • Acceptance Criteria do not normally express how to do the job, although you may note how you intend to do the job to illustrate to the PO to help clarify any ambiguities.

What about Gherkin?

You can’t have a discussion on Acceptance Criteria without mentioning Gherkin, Gherkin is simply a tool for expressing Acceptance Criteria in a standardised and hopefully clearer format. However, Acceptance Criteria Gherkin and Test scenario Gherkin are very often confused, and the Gherkin constraint may result in the focus shifting from the conversation about the user’s need, to how to use Gherkin and the user’s need may get lost.

Story Acceptance Criteria is also not the place for identifying all of the test scenarios and edge cases, it is about understanding the need of the customer.

Another common issue with Gherkin is that the precise nature of the format and terms implies that the Acceptance Criteria are absolute and non-negotiable which is the exact opposite of how they should be considered.  If you start to fall in to the trap of seeing the Gherkin as a contract (rather than notes on a conversation) then stop using it until you get in the habit of regular conversation with the Product Owner.

By all means practice with Gherkin until you get better, but if you remember that it is about capturing notes from a conversation with the PO and most certainly NOT negotiating the terms of a contract then it is a useful tool.  But personally I prefer not to use Gherkin in the initial conversations about Acceptance Criteria simply because it is not a natural way of thinking for many POs so the format constrains thinking and conversation and the frequency in which it is treated as an explicit contract undermines it’s value.   Once you have discussed the Acceptance Criteria converting them to Gherkin may be beneficial.

However, I prefer to see Gherkin used for Acceptance Testing where those writing the tests are familiar with the syntax and where precision is more important.
If you take nothing else from this, please remember that Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

Accceptance Criteria are notes on a conversation, they are not clauses in a contract.

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!