On the subject of Self-Organisation

“Organise the work, let people self-organise”
Many agile frameworks include the idea of ‘self-organising teams’ as an essential ingredient. For example, Scrum calls for long-life, stable teams where individuals have no titles and there is no hierarchy. With no hierarchy, there is no ‘boss’. When I introduce these ideas in training, most audiences react with incredulity, citing a myriad of objections such as:
  • We must have accountability* – a single individual I can rely on to ‘make it happen’
  • Junior folks couldn’t organise themselves – they need a team lead or project manager to tell them what to do and make sure they do it
  • If someone isn’t in charge, it’ll be chaos…
  • How can we make sure people aren’t ‘slacking off’ if we’ don’t have someone keeping an eye on them?
  • If people are allowed to decide what they’ll work on, you’ll have people doing work they aren’t capable of and making lots of mistakes
  • How do I tell a senior developer with 10 years hard won experience that they now have the same title as the intern?
  • We decide on pay scales based on title – we aren’t going to pay everyone the same so how else could we do it?
  • Whats a career path without titles and hierarchy? What will motivate people to work hard and do a good job?
  • Some people like to be told what to do – they aren’t comfortable making decisions for themselves
  • Isn’t no titles or hierarchy just for an ideal world – can’t we be agile without the self-organisation bit?
*See a recent blog post on accountability in agile organisations

So if you take away titles and hierarchy, it leaves a lot of open questions. Lets tackle some of these one by one.

Firstly, do we really need self-organising teams to be agile? Not all of what are considered agile** frameworks  require self-organising teams – in fact some like Kanban don’t mandate teams at all. But frameworks like Scrum and XP are based firmly around the idea of cross-functional teams. But why ‘self-organising’? The logic is that teams based on a hierarchy, with power at the top, but most of the detailed knowledge and awareness of the work at the bottom, are two slow to sense and respond to complex, fluid situations. In a traditional environment, people on the front line must articulate the changing context to those up the hierarchy, while decisions must be fed down through the ‘chain of command’ till they reach those that will implement them. To speed up this process, teams can delegate power to the front line. However, delegation implies the person delegating, i.e. temporarily passing the power to another, still has ultimate responsibility. Therefore, delegation is usually carefully qualified and bound. Heavy oversight and a fear of a loss of control can hugely restrict the intended benefits. In self-organising teams, on the other hand, the decision making power is not delegated, it is distributed. That is, there is no one individual with the power who is temporarily delegating it to others. The power is everyones, and everyone on the team is responsible for using it to the benefit of the team objective. So in summary self-organiing teams are not a mandatory requirement of agile, but their ability to be agile (sense and respond rapidly and effectively) is an important aspect of a successful agile organisation.

**What is and isn’t an agile method is highly subjective, but mostly I consider whether it shares the values of the Agile Manifesto

The next question is ‘how do we ensure everyone on the team is contributing in the most effective way’? If we don’t have a ‘boss’ telling us what to do, how do we know what to do? The answer is a shared goal, and commitment to that goal. 

‘Make the mission your boss’

The team should have agreed a shared objective that everyone on the team will pursue. In Scrum this may be the sprint goal (short term), release goal (medium term) and company or team strategy (long term). To use a rugby metaphor, the short term goal is to score a try, medium term to win the match and long term to with the championship. It is this shared goal, unattainable by any one team member or subgroup, that causes the team to ‘gell’ in a network of interdependancies and mutual accountability. This is where the transparency agile calls for is so important – so people can see where they can best help the team to reach the goal, where the problems and blockages are, who is contributing what. If everyone is working to a single goal, one that is not too far out (e.g. a day, a sprint), then alignment of activities happens ‘implicitly’ through face to face discussions, the team board, programmers and testers working on the same things at the same time, etc. And since everyone is mutually accountable to each other to do their utmost to achieve the goal, there is no place for people who will sit around waiting to be told what to do. I’ve seen this approach transform a group of shy, junior, fearful engineers into a cohesive, dynamic and super effective team within just a couple of weeks. A good agile coach/scrummaster will create an environment where the mission is the boss, where there is no fear, and where the team has everything it needs to do a good job.

In the next few posts I’ll discuss some of the other questions raised above – e.g. hiring effective team members, career paths, performance management, etc.

Who’s to blame if it all goes wrong? Accountability in agile organisations

It’s amazing what you can accomplish if you don’t care who  gets the credit, (or the blame). Harry S Truman ( in brackets added by me!)

Many agile frameworks, noticibly Scrum, propose self-organising teams to increase productivity, agility and creativity. One aspect of self organising teams is accountability.

In hierarchical teams, common in traditional organisations, it’s clear who is accountable for the outcome of the work. Most teams include some type of leadership or manager role, such as team lead or project manager. If the project doesn’t go well then there is clearly somebody to hold accountable. Of course, you can’t hold someone accountable for an outcome unless you also give them the power to control the resources and coordinate the work. This leads to that person taking control of what the team is doing, which means you no longer have a self-organising team.

So if you want a truly self-organising team, with distributed rather than centralised decision making, then you must also distribute accountability. The two go hand in hand.

(Note that I avoid the term delegated authority in the above discussion. Delegated implies the power and authority are temporarily and voluntarily moved from one person to one or more others. A similar scenario usually underlies the term empowered team. But here we mean that the power and accountability belong to everyone – they are not being given them by another person who really owns them).

You may have heard the saying ‘if everyone is accountable then no one is accountable’. This usually is meant to apply to ‘joint accountability’ where not one but a number of people are accountable for an outcome. But on a self-organising team, I find a much more powerful concept is ‘mutual accountability’. Everyone on the team is individually accountable to everyone else on the team.

So I am accountable to my peers and they are accountable to me. If you are having a problem, I am accountable for recognising that and helping, while you are accountable for letting me know the issue and seeking my help. This directly encourages, or even demands, that we stay aware of our colleagues progress and actively make sure we are helping everyone succeed.

On a practical level, this might manifest itself as a renewed interest by the team in the daily Scrum or stand-up meeting. If I need to be aware of how others are getting on so I can help out if necessary, then the scrum is certainly something I don’t want to miss!

But many of you might still be thinking ‘We still need someone to be accountable for the outcome’, or, in other words: ‘Who should take the blame if things go wrong?’.

Why do we hanker after accountability? Why do organisations strive for demarcation of accountability and role definitions? Is it so that they have somebody to blame if things go wrong? Which leads to the question: are the terms ‘accountable’ and ‘blameable’ interchangable in this context? Are we really looking for someone we can blame? And an obvious follow on question is ‘Are we  designing our organisations for failure?’ So we have someone to blame if things go badly. Or you may prefer to take a more positive spin on this: we need demarcation of roles and accountability to encourage people to work to make the outcome a success. But this is the same justification from a different angle.

What if we designed our organisations for collaboration and success, rather than failure and blameability? What would such an organisation look like?

 


The Super Chicken Story – as told by Margaret Heffernan

An evolutionary biologist at Purdue University named William Muir studied chickens. He was interested in productivity — I think it’s something that concerns all of us — but it’s easy to measure in chickens because you just count the eggs.He wanted to know what could make his chickens more productive, so he devised a beautiful experiment.

Chickens live in groups, so first of all, he selected just an average flock, and he let it alone for six generations.

But then he created a second group of the individually most productive chickens — you could call them superchickens — and he put them together in a superflock, and each generation, he selected only the most productive for breeding. After six generations had passed, what did he find?

Well, the first group, the average group, was doing just fine. They were all plump and fully feathered and egg production had increased dramatically.

What about the second group? Well, all but three were dead. They’d pecked the rest to death.

The individually productive chickens had only achieved their success by suppressing the productivity of the rest.


To encouarage mutual accountability, where everyone on the team is charged with everyone else’s success, the differentiation of role, job and competence is key.

In most organisations, a role is synonymous with someone’s job: if you are a project manager, your role is project management. If a tester, your job is to test. However, in a self-organising team, where everyone is responsible for team success, this construct restricts our ability to help each other be successful. An alternative is to think of individuals bringing various competencies, skills and knowledge to the team, but not being confined to only practice those skills that are defined as part of their job. Instead, each individual is tasked with helping the team be successful in any way they can – whether or not that is by applying their strongest skills. In this sense, the role, or roles, a person is playing can change day by day, depending on what the team needs at the time. Roles are defined seperatly from individuals. The team has a competency in UX, and one individual usually carries out this role, but it is not only their responsibility. And if they can help another team member by applying the competency, or sharing it, or performing a completely different task, then that’s what they do. Because they are accountable to those others on the team.

Another way of looking at this is in terms of ‘span of control’ vs. ‘span of influence’. In hierarchical organisations, accountability is usually confined to a person’s span of control – that is, what they control directly – the individuals who report into them, whom they control. But in flat, team based structures, there is no direct control. Here accountability applies to your span of influence – that is, each team member is responsible for those they can influence. Depending on the organisational structure, this might extend to your self organising team, or beyond to others in the organisation. For example, some organisations use the ‘advice system’ to support distributed decision making. Here anyone can make any decision on behalf of the organisation, but only after seeking advice on the decision from a number of others. But the decision maker doesn’t have to act on the advice they get from those others – the decision is theirs, and theirs alone. The only rule is that they seek out and listen to the advice. This allows others on the team to exercise their ‘span of influence’. And mutual accountability means each person giving advice must do their best to help you make the best decision. And the decision maker is accountable for seeking out and considering that advice to the best of their ability.

So how do you cultivate a culture that values collaboration and team success over individual performance? There are a few tactics you can employ immediately:

  • Measure and reward ‘helpfulness’. The best people to measure this might be the team members themselves, so look at peer to peer measurements. For example the old 360 degrees evaluations could be developed to this purpose.
  • Define a single, compelling team goal that provides a challenge but is still achievable. Such a goal will ideally require intensive collaboration across the whole team. It will not be achievable by any individual or subset, and so require collaboration to achieve.
  • On your teams, don’t use job titles that refer to a persons job rather than competency, don’t impose a hierarchy or seniority structure, and instead allow a natural structure to emerge. From experience, this results in those that are truly respected by others in the team, for their skills, knowledge and, more than anything, helpfulness, to naturally emerge as the leaders. These are true ‘servant leaders’, elevated to leadership positions by the team because they serve the team so well. They will therefore naturally serve as role models for collaboration, respect and mutual accountability.

The above discussion raises many questions regarding career paths and planning, performance management, hiring, alignment, and so forth. These are topics that more advanced agile organisations are addressing on their journey – and AgileInnovation is helping such companies make the deeper, cultural and structural changes to go beyond mere changes to practices and agile frameworks. If these are challenges you are also facing, get in touch at services@agileinnovation.ie

Conferences on Agile | DevOps| Testing, Dublin, 19 May – 20% Discount

AgileInnovation can offer you 5 FREE tickets and a discount on further tickets on the UNICOM Agile Showcase Dublin on 19 May. Delegates may attend any sessions from across the three events:

Agile Showcase Dublin:

Implementing and Scaling Agile

19 May 2016, The Gresham Dublin Hotel

Co-located with:

Testing Showcase Dublin:

Testing Challenges, Opportunities and Digital Transformation

19 May 2016, The Gresham Dublin Hotel

DevOps Showcase Dublin:

Fundamentals of DevOps

19 May 2016, The Gresham Dublin Hotel

 

How to Apply for Complimentary Places:

If you would like to attend the conferences, please follow the steps outlined below, and a member of the UNICOM team will contact you to confirm your place.

  1. Please confirm urgently by email [info@unicom.co.uk] saying that you would like to take up the offer, including the following information for each delegate aiming to register:
  • Primary conference track of interest: 
  • Full name:
  • Job title:
  • Company:
  • Email address:
  • Telephone: 
  • Reference Code: AgileInnovation Offer
  1. If you accept a place and subsequently find that you are unable to attend, please either nominate a colleague to attend in your place or advise UNICOM in advance so that they can offer it to someone else.
  2. These 5 complimentary places are on a first come first served basis, we recommend applying urgently to avoid disappointment! If the offer is oversubscribed in the interest of fairness UNICOM may have to limit the number of participants from the same organisation.
  3. The offer cannot be applied retrospectively if you have already registered for the event. Refunds cannot be provided for places already booked.

If you have any questions about the conferences, please contact UNICOM directly and their team will be delighted to help you: +44 (0) 1895 256 484 | info@unicom.co.uk.

Discount for AgileInnovation clients:

We have arranged with the organisers, UNICOM, an exclusive 20% discount on the ticket prices for any of these events. To claim the discount, when booking, simply apply the Voucher Code “AGIN20“ when booking online.

Whichever of the three events you book for, you are welcome to attend any sessions from the co-located conferences.

Contact for information:

If you have any questions about the conferences, please contact the organisers directly, their team will be delighted to help you.

UNICOM Seminars Ltd | Tel: +44 (0) 1895 256 484 | www.unicom.co.uk | info@unicom.co.uk

 

AgileTour 2015 Dublin – Presentations now available for download

Following a great day of presentations, discussion and networking last Thursday, the slides from several AgileTour speakers are now available – I’ll be adding others over the coming days:

Please attribute any slides you use or modify to the original author.

Galway Agile Meet-Up 5th Oct 7pm

The Agile meetup in Galway ran out of steam a few years back. But a friend I met when delivering agile training, Xabi, has decided to give it another go! So we’re meeting 5th Oct 7pm in Galway (venue to be finalised). The format we use will depend on numbers, but if you have any ideas please get in touch!
Join the meet-up group here for updates. Hopefully see you on the 5th!

AgileTour Dublin Oct 10th 2013 – FULLY BOOKED

This conference is now fully booked – the sponsors have a limited number of reserved tickets – please contact us directly if you are looking for a ticket and we may be able to source a ticket for you.

The final program for this years AgileTour event is now available. We have limited capacity of 100 seats and we expect them to be snapped up in the next few days so REGISTER NOW.

A full 1 day conference with quality speakers, experience reports, great networking opportunities – in the center of Dublin and all for a 10 euro fee! Learn from others, share your experiences, gather tips and have some fun!