rob bowley » teams

The roles and responsibilities of a Software Team

rob — Sat, 25 Jul 2009 09:59:15 +0000

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

Team principles

rob — Wed, 29 Apr 2009 11:41:52 +0000

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)

Have you done something similar? What are your team’s principles?

the responsibilities an agile team needs to be successful

rob — Sat, 19 Apr 2008 21:19:27 +0000

Why do we need roles in an agile team?
Self-organisation is the goal of an agile team, but this does not happen unless the environment is provided. It is the responsibility of the leaders in a team to create and maintain this environment. However, we need to avoid creating bureaucracy and dogma so should try and steer clear of tightly defined roles and responsibilities. The boundaries need to be loose enough so we can get the most out of individuals and customise the roles to the requirements of the specific team.

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.