Basically, if you’re finding yourself in the situation (as, lets face it, we often are) of taking sides and forming prejudice about other teams or groups á la Lord of the Flies you’re succumbing to a base, instinctive behaviour which was probably quite useful when we hunted in packs, but has little value in modern society.

Next time you find yourself in this situation, think about what superordinate goals you share with the “opposing group”, so that rather than back-slapping each other about how amazing your group is and gloating about how weak and feeble they are, you can all work together to get what you want.

- Principles Behind the Agile Manifesto

I’ve often had people say to me that we’re not really self-organising because we’re not all taking part in all the decisions made at our organisations, such as how the company is run or what products we should be making. This is a misunderstanding of how self-organisation occurs. The fact is we’re constantly self-organising, it’s just most of the time we’re completely oblivious to the fact it’s happening.

For example, within a group of people (such as a workplace) there are many social sub-groups, such as the early morning runners, the ones that go to lunch together and the after work drinkers. They all naturally self-organise around shared goals & desires. Even within a team where a highly autocratic management approach is in place, members of the team will self-organise around anything they can (such as making the tea or going out to buy some biscuits). The thing with self-organisation is it’s actually harder not to be doing it!

If you define self-organisation as when everyone in a team is able to control everything that affects it where do you stop? Your team? Your department? Organisation? City? Country? See where I’m going?

Self-organisation always occurs within boundaries defined by it’s context. For example, a football team might be a football pitch for 90 minutes, a group of friends on holiday the holiday villa they’re staying in or your department at work by the responsibilities it has.  Something or someone always sets these boundaries. If they did not exist self-organisation couldn’t occur.

What causes self-organisation?

A complex system* will always be vulnerable to external events which are outside of it’s control, such as the opposite team, the weather or your customers or stakeholders. Self-organisation emerges when it becomes important to respond to these uncontrollable events in a manner which benefits the system. The ability to do so results in the system being adaptive. We know that software development is complex so we can determine we’re in a complex adaptive system. It’s a huge subject and not the particular focus of this article so I won’t try to go into any more detail, but if it’s a new concept to you I strongly encourage you to investigate further.

How to take advantage of the fact that it occurs

When self-organisation is on your side it can be extremely valuable. If you’re working in a complex adaptive system it’s shown that by far the most effective way to allow that system to operate is to allow it to self-organise, because that’s what it will naturally try to do.

The problem is it’s not always on your side (if you’re an oppressive Arab dictator, for example) and will often work against your goals and objectives. I’ve often seen self-organisation criticised because this happens. I’ve also seen it criticised because a team is unable to self-organise effectively when allowed to do so. In both cases you may be tempted to blame the individuals in the team. This would be unjust because in reality it is the system to blame (and probably you as the controller of the system).

To enable self-organisation to work in your favour you need to understand and ideally define the system – set it’s boundaries and try to organise it in a manner which will encourage self-organisation to occur in a way which supports your objectives. This is often called Systems Thinking. Again this is a large and well documented subject so there’s no need for me to elaborate further (if you’re looking for a good place to start though I thoroughly recommend Jurgen Appelo‘s excellent book, Management 3.0).

*It’s widely held that software development in general exhibits the properties of being complex (as described in the Cynefin Model).

We’re currently going through a highly transformational period at work introducing many new concepts to people intended to better manage the flow of work and the long term sustainability of the organsation. It became clear there was a need to have some means by which to guide people as to what was expected from them and the previous job descriptions were no longer appropriate. This article contains the new responsibilities and the justification for them which I thought may prove useful to others.

Firstly, credit to Portia Tung and Pascal Van Cauwenberghe as their article on the Roles and Responsibilities of an Agile Team inspired much of what follows.

Roles

Disclaimer: These are quite generic descriptions which I hope may prove useful if you are required to formulate such things, however they are still specific to our needs. We don’t have business analysts, project managers or architects for example (and currently do not feel the need for them either) so if you feel there’s something missing from where you work that’s because it probably is.

Team Member
Developer / Tester
Lead Developer
Team Leader
Principal Developer

Some more details

• Everyone is a Team Member first and foremost. It was interesting when drawing up these job descriptions how almost all the responsibilities are applicable to a Team Member with the other roles (in most cases) adding little more than extensions to the same responsibilities.
• Some of the roles aren’t positions in themselves. For example, the Team Leader role does not map directly to a project manager (we don’t have any) – it is held by whoever is most appropriate (it could be the Lead Developer but it could be a tester or developer).
• Each responsibility follows the format of the explanation of the responsibility (in bold) followed by the justification e.g.

To ensure deliverables meet the acceptance criteria given so that we do not waste time reworking them.

I think this is really important. I’ve rarely ever seen a job description which justified itself. It’s like a User story with the “so that…” part missing.

Obective

The overriding objective was to provide a description of the desired environment within which self-organisation and self-empowerment are the preferred management approach. This can be directly related back to two principles in the Agile Manifesto:

The best architectures, requirements, and designs
emerge from self-organizing teams.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

“Respect for People” is also a one of the two main pillars of the Toyota Way (the other being continuous improvement), In my mind there is no better way to grow people within your organisation than empowering them and respecting and trusting them to do their job (interestingly it appears this pillar is commonly overlooked resulting in the Toyota Half-Way). ]]> http://blog.robbowley.net/2009/07/25/the-roles-and-responsibilities-of-a-software-team/feed/ 1 http://blog.robbowley.net/2009/04/29/team-principles/ http://blog.robbowley.net/2009/04/29/team-principles/#comments Wed, 29 Apr 2009 11:41:52 +0000 Rob http://blog.robbowley.net/?p=452 On my new team we’ve just started our first proper iteration. We’ve agreed to commit to the following principles:

• No multi-tasking
• All new or changed code must be thoroughly unit tested
• No more than 2 pieces of work in “Active Work” at any time (our team is 3 developers)
• We always work on the highest priority task
• Our definition of done is “In UAT”
• Leave it in a better condition than you found it
• No hidden work
• No overtime
• No disruptions
• Don’t SysTest your own work (we don’t have a tester yet)

Why add more roles at all then?
In my organisation either you’re a Developer or a Team Lead. This is not a fair reflection of the value our colleagues bring to the organisation. A great developer is worth exponentially more than an average developer and excellence needs to be appreciated. Also, what makes a developer good are not necessarily the same skills we’re looking for in a team lead.

The responsibilities an agile team needs to be successful
Below I’ve listed responsibilities desired in an agile team. Whilst I have grouped them by the roles of Team Leader and Lead Programmer they are by no means mutually exclusive and do not even have to be the responsibilities of either. We want to be creating teams that have senior people capable of taking on as many of these responsibilities as possible and then allowing them to decide who is best suited to do what. This will have the dual effect of empowering our teams (therefore reducing their dependency on management) and allowing people the flexibility to develop themselves in the areas they enjoy the most rather than feeling they are competing for a single position or even worse, not seeing one that’s suited to them at all.

Team Leader
Communication champion.
Gets the most out of the team.
Empowers the team.
Provides direction (can be technical and process).
Resolves conflict.
Removes blockages.
Makes sure everyone is happy.
Ensures standards and processes agreed within the team are maintained.
Ensure all members of the team have a proper understanding of the customer’s requirements.

Lead Programmer
Code champion.
Responsible for the quality of the code base.
Responsible for the underlying architecture for the software.
Responsible for technical decisions.
Ensure all members of the team have a proper understanding of the technical vision.
Train and informs developers on coding best practices.