Collective responsibility – ask the team!

Collective responsibility is one of the artefacts of agile software development realized those days in many companies and teams (also called Scrum). When I talked with stakeholders about details of software project management strategies they are pushing forward – want to do, often I heard answer as “ask the team”.

Simply and easy understandable answer, hm – is it really answer ? .. let’s imagine:

  • Question: “Who is responsible for coding standards?”
  • Answer: “Ask the team.”
  • Question: “Who should supervise quality of task management?”
  • Answer: “Ask the team.”
  • Question: “Do we have clear definition of competencies and responsibilities in our scrum team?”
  • Answer: “Ask the team, discuss with them about it.”

I had a feeling there are questions without answers, nothing concrete only easy general answer “ask the team”.

Hey! This is not organization – this is not the world of strictly defined rules, definitions (what engineering really is), this is nothing more than plebiscite…

Nowdemocracy you are speculating – dictatorship can’t work, authoritative approach doesn’t work generally – what you are writing about, buddy? Let’s discuss about democracy in teams – teams are different, contain different people, with different meanings, different skill sets and different characters.

IT world is slightly different from other jobs – and often the developers are not so easy to manage, and definitely authoritative approach can’t be applied. On other side, in a teams there are juniors, seniors, developers, qa people, analysts with different project background, different communication skills and traits. In democracy every vote has the same value – let’s apply it – such team will discuss about development artefacts with analysts, organization issues with young developers or coding details with qa…

Thus discussions about organizational and technical aspects of software development can lead to unsolvable and neverending shouting matches without reasonable and usable results for the project. If you are not so good speaker, there will be no result in the end – and you wouldn’t get not only answers to questions mentioned above (and many other), but in good case your project will suffer from unclearly defined rules and responsibilities. Be aware – it doesn’t mean that you shouldn’t discuss in team – you have to – but there has to be clearly defined responsibility assigned to concrete person for concrete area.

As we know from history, every people’s organization based on collective responsibility doesn’t end well, as wikipedia explains:
Collective responsibility also known as “Collective Guilt” is a concept in which individuals are responsible for other people’s actions by tolerating, ignoring, or harbouring them, without actively collaborating in these actions.
Read it at … do you see there something what you really want to see in your IT project?

If you define responsible persons for defined areas with trackable goals and assigned competences, you will gain more than misleading sense of freedom.

Ask the team about it 🙂

Requirement Engineering, Business Analysis, Agile, Analysis and Design with UML, Java/J2EE, Liferay, Javascript, Embedded C++, MDD, Executable UML, Project Management