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).