The Enemy of Agility is Ego

dunning-kruger-effect

Over the years I have discovered that the more I learn on any subject the more I come to realize that I know very little, it doesn’t seem to matter how much I study or how much I learn, the awareness of scope of my ignorance grows far faster.  Does that make me wise or just aware that I know very little?   I suspect that I’m slowly fighting my way out of the valley of despair.

No need to improve

One of the most challenging aspects of being an Agile Coach and working with teams is that to improve you first need to accept that there is room to improve. There are a some teams and team members that believe there is nothing more that they need to learn, they are so supremely confident in their own capability and knowledge that they refuse to consider that there could be a better way to do things than the way they have always done things.
On the other-hand I can’t be confident that there is a better way, only that we won’t find a better way unless we look. I don’t like the notion there is a ‘best practice’ as this limits our thinking. But this puts unwavering certainty that this is the ‘best practice’ against encouragement to explore the possibility of a better way, certainty is very powerful.

Sometimes this ‘certainty’ is founded in fear, especially when dealing with transformations where former roles are called into question, I find this an understandable reaction, but the situations I struggle with most are the team members that become blinkered to opportunities, they have found one way that works (even poorly) and simply are unwilling to try anything different. Their Ego, prevents them considering anything else.

As a coach I have no desire to force processes or ideas on people, only to open their minds that there could be opportunities and alternatives.  So it can be heartbreaking when people refuse to even consider alternatives, or worse impose their views on others through sheer force of will.

Perhaps I am mistaken and maybe the right answer is that if something isn’t broke don’t fix it, but that notion doesn’t sit well with me.

kruger calvin

So how do we persuade people to open themselves up to learning new things?

I recently had an experiences that I found tough, there was a QA who refused to ‘leave his column’ on the board, he would not do anything that was not ‘testing’ and resisted anyone working with him in ‘his column‘ thankfully it is not often I see that level of obstinance. But this situation was further compounded by the rest of the team enabling his behavior. The developers were all too happy not to be involved with the QA aspect and were seemingly unmoved by his unwillingness to cross boundaries.

The QA column was regularly a bottleneck but rather than addressing this the team wanted to mask the issue by pushing cards through and raising new cards for rework. What was tough was that the team saw no need to experiment with alternative ways of working: suggestions included either helping the QA, or even getting the QA involved earlier, and despite raising QA as a bottleneck repeatedly in retrospectives the team didn’t want to change behavior even in the form of an experiment.

As a coach you can shine a light but not force a change.  I felt the team was capable of far more but the team were getting things done and were seemingly content with the status quo. For me this is the dark side of coaching, where you must watch a team not reach their potential, out of respect for their independence.  Ultimately it is a trust issue as things so often are.

Ownership of Columns

In general I dislike explicit roles when there is a shared responsibility, and I dislike the notion that a column on a board is in anyway related to a person or a specific role, the board should reflect the progress of the work (stories) not ownership of the work and when the two become muddled people become defensive and territorial.

When there becomes an association between a column and a person the focus moves from getting a story done as a team, to moving a story on to the next column, we switch our context of efficiency to a narrower view.

This is often seen as a subtle and unimportant distinction. But when the team loses a cohesive sense of ownership for getting to done and can hand off responsibility to another sub section of the team, bad habits emerge. At it’s worst I have seen teams (thankfully not one I coached) where at stand-up one part of the team will brag about how many stories they are ahead of an other part (be it front and back end or Dev and QA). In one extreme case I saw a team decouple testing from development by splitting stories and I overheard one standup where the developers were gleeful that they were now 3 sprints ahead of testing (the sprints were 3-week sprints). It is 9 weeks before they will see value from their work or even know if their work had value, and yet they were so proud.

Dunning Kruger Effect

Adjusting your mindset to one of learning rather than certainty can be tough, especially for those that grew up in a culture that rewards confidence and certainty, but accepting that you don’t know everything and being aware that there is always the potential to improve can enable you to become far more capable, the only thing stopping you is your ego.

 

The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell

 

Advertisements

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?

 

 

 

Practicing what you preach

For this blog post I’d like to make a change from my usual style and share a personal experience.

For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.

It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .

Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.

Jack Handey

It’ll be easy he said…

Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas;  I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.

roadmap

We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.

As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.

user-story-mapping

Delivery Pipeline

The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in.  I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.

There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.

I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.

leap faith

Challenges

The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.

Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.

This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.

Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.

DevOps-cycle-Extended

DevOps

I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.

I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me.  But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.

I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.

This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.

It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.

I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.

 

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.

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!

 

 

It is all in the follow through…


Accountability of others

Holding another person accountable can be a scary thing, even just saying that sounds a big deal.  And whilst it is a big deal, it doesn’t need to be scary.  Feedback is a skill, and it one that you get much better at the more you practice.

In theory feedback in the context of accountability should be the easiest kind.  Your work colleague or partner has made a commitment to you or to the team and in doing so they are implicitly inviting you to give them feedback if they stray from this commitment. Learning to give that feedback constructively and supportively comes with practice, and frequency. If you are giving feedback regularly it is easier to give and easier to receive, eventually it will become a normal and natural interaction on a team.

If they took an action item to do something by the end of the week a polite enquiry on their progress, may serve as a reminder that the task is important and that they have committed to it. There is no need for judgement or pressure and certainly no need to micro-manage. An offer to help or an enquiry if there are any impediments you should be aware of, or can assist with, should be sufficient to reassert the importance of the task and a reminder of the commitment made.

In most cases if someone has taken responsibility and committed to something, they will be happy to be held accountable, especially if you have established trust on the team and have decided as a group this is something important, a good team player understands that group decisions impact all of us and are in all our interests to get it done, so understand and expect you to have an interest in getting it done.

Holding yourself accountable

Holding yourself accountable is much harder, after all if we could see we were slipping we’d do something about it. Which is why it is so important to explicitly ask others to help you with this or to find techniques to help you stay focused on what is important.

accountability-breeds-responsibility1

Accountability techniques

There are a couple of very easy techniques for creating opportunities for holding each other accountable. If done right these should lead to more frequent feedback, if they become a constraint and feedback becomes limited to these opportunities then try something new.

A regular stand-up meeting

Get together with your team on a regular basis, a lot of teams find once a day is a good cadence, review priorities, objectives and actions, by sharing what you are working on and where you need help you are inviting input from others, if an action item is being neglected this is an opportunity to ask why or to remind others of the importance of it. Be careful this does not become reporting to someone, this is about sharing information and looking for opportunities to assist each other.

Make your work visible

Something like a Kanban board or a todo list is fantastic for sharing with your team mates what you are working on, you and they can immediately see if an action is not being given priority and can see why or what is.  If Kanban is used then priorities of work are clear and your policies are explicit, everyone is clear just by looking, what is going on.  The key to maximising the value of this is by ensuring it is used correctly, all tasks are on the board and you follow the rules, ambiguity can ruin this technique.

If combined with a stand-up it can enhance the effectiveness of both techniques.  Also whilst Kanban boards are great for team working, they also work well for an individual, many people find a personal Kanban board is a great way of keeping focused on what is important and avoids getting distracted by less important interruptions. and having it visible in a public space too will aid you holding yourself accountable to it.

Always review previous actions

At the start of a team meeting it is important to review the previous action items, and to not lose sight of any that remain outstanding. First the team should be focused on the most important issues, and actions should be the team’s collective view on how best to proceed. If as a team you don’t care enough to want to know how those actions turned out, you have to question your buy-in to those desicions or if your team is actually focused on the right priorities.

Was the purpose achieved?

Remember the reason for the Action item. I would also suggest that an action is the result of a discussion about resolving a problem, satisfying a need, or is progress towards a goal.
Taking some time not only to review whether the action was taken, but also to review whether it achieved it’s purpose would be valuable. It is quite common for an action to not have the expected results, and in that case the underlying issue still needs addressing.

Summary

Accountability should become routine, and we can all benefit from being held accountable. If it doesn’t become easier or routine then perhaps there are other underlying problems either with trust on the team or a lack of genuine commitment to decisions.

 

 

Related reading

This is the fourth post on the theme, the five dysfunctions of a team.

The others are available here: