Scrum roles vs roles and responsibilities

Whilst I totally get the point of it

Can you explain the point of it to us, here? What purpose does the "charter" actually serve?

It rather sounds as though it constitutes an organizational mapping, when organizational change is required for Scrum to succeed, and for its benefits to be obtained.

Everyone on a Scrum Team is either a Product Owner, a Scrum Master, or a member of the Development Team.

No additional roles are recognized by Scrum, and both the Development Team and Scrum Team are self organizing.

Within that context, how able are the various Development Team members able to self-organize, to make the best use of everyone's talents, without being held back by additional layers that have been added due to the organization or culture?

For instance, despite the difference in job titles, can a Development Team find its own way of planning the work, or is there an expectation of deference from a junior dev to a senior one, that means constructive dissent and proper self-organization are impeded? If there is an architect on the team, do the Development Team accept shared accountability for the architecture, and would they be willing to make a collective decision, even if it contravenes the professional opinion of the architect?

Which of these roles might exist outside of the Scrum Team? I suggest taking a look at the suggested reading for the Professional Agile Leadership certification. This covers the role of managers and others in leadership positions. It's possible that specialists may take on the role of a servant leader, whereby they enable others to self-organize to achieve better results. For instance, I've seen this in the past with QA engineers, who stepped back from the Scrum Teams, and acted as advisors and coaches in terms of helping the Scrum Teams take overall responsibility for quality. They also provided additional support, such as making sure the automated testing framework kept running, and providing transparency over general quality trends, whilst enabling the teams to solve the problems themselves.

Can any of these functions work against Scrum? If so, what opportunities are there to help such people move away from their existing responsiblities, into a way that helps them contribute, either within, or in collaboration with, the Scrum Team?

Can you explain the point of it to us, here? What purpose does the "charter" actually serve?

I was more referring to the exercise which was to map out what certain team members are doing and what other team members would expect those people to be doing to try to ascertain where there is crossover in the roles and if some roles are doing more than they should be doing.

The charter workshop is going to tomorrow and I have no experience of a team charter (my previous employer did not use this). I was told the charter sets outs the team vision and defines the way of working, and that the output of the first workshop will feed into the charter to define what perceived roles such as a developer vs a senior developer vs a lead developer should be doing. 

It might be worth pointing out that the teams are all quite new, having only recently formed and the adoption of Scrum is in its infancy (not sure if this is relevant).

No additional roles are recognized by Scrum, and both the Development Team and Scrum Team are self organizing.

So I actually mentioned this at the start of the session, as I said I was confused by the exercise and had thought the teams should be self organising with only these roles recognised and I was told by the person running the workshop that the exercise was an exercise in how the team will self organise, and that agile is very flexible.

 If there is an architect on the team, do the Development Team accept shared accountability for the architecture, and would they be willing to make a collective decision, even if it contravenes the professional opinion of the architect?

I think this was another reason for the meeting, because it seems that actually they were defining the responsibility of the architect role (amongst others), so for instance one of the responsibilities of that role was "Solutions Assurance" and "Proposes and design new solutions", which at least to me indicates the whole team would not feel accountable if a solution is either proposed or assured and it is wrong.

Again that is just my understanding of this and I guess the reason I thought I could reach out to others with experience of Scrum, and possibly team charters and see how they work together (if at all).

This discussion reminds me of step 5 from this blog by The Liberators: How To Kickstart A Great Scrum Team (10 practical things to do)

A more common division of skills (and possibly associated with job titles) is to have front-end, back-end, ops and full-stack developers on a team. Likewise there are some people who have preferences or particular strengths, but are willing to work in other areas, as needed. There's no reason, in principle why business analysis or architecture shouldn't be handled in the same way; but it has to work for the team.

It can get messy if there are organizational expectations on one person to do this, and then the team are told to self-organize in this area. How committed is the organization to setting aside mandated individual responsibilities and accountabilities, and give them to the team?

A healthy Development Team containing an architect will probably lean heavily on that member for advice in its decision making. It will probably attempt to cross-skill as appropriate, so that others also gain enough of this rare skill to function in the architect's absence, to provide sufficient alternative perspectives to enable healthy debate, and also to facilitate their own better development decisions throughout the day. The architect will also recognize the needs of the team, and seek to bring out the best in others, rather than being the hero who solves every architecture related problem.

Even on the link I shared (written by a Professional Scrum Trainer), the image (written in Dutch, but partially understandable for an English speaker) shows someone with the role "Dev / Team Lead". Having a team lead is not Scrum. Scrum doesn't explicitly forbid it, but I'd argue that it almost always impedes self-organization.

Occasionally finding the balance between challenging the status quo, and allowing teams to work within existing external constraints can be the best option.

In any case, it's important to have transparency where extra layers from outside of Scrum have been applied on top, and the potential they have to inhibit the team's effectiveness.

That's a great article, so I guess that team is considered to be in the forming\storming phase and is creating the charter so that they can agree on what the norms are as they operate, and what is expected of each member and move into the "norming" phase.

I am planning to run the same roles workshop for my team next week (facilitated by someone else), I am still unsure on the charter aspect and I am wondering if we can use a simple team manifest over a charter that sets out things such as what a role should do.

I would like us to do Scrum properly, and I had planned that we would not have any hierarchies within the team (I am lead engineer but don't want to act with more authority) and I had hope we can self organise effectively.

When I think about self organising I just imagined we would collaborate as a team to break down tickets and people would pick up tickets they are able to complete themselves rather than being dished out and this would happen organically rather than having to be drawn up beforehand.

As an example, a story is broken down and part of it involves architecture work, the architect would naturally pick this work up,  a sub task to create a new API endpoint, picked up by a developer, a change to a react front end, picked up by a developer and so forth. In hindsight this was probably naive to think would just naturally happen.

I had planned that we would not have any hierarchies within the team (I am lead engineer but don't want to act with more authority) and I had hope we can self organise effectively.

I like the way you're approaching the subject, and from your posts on this forum, you come across as sincere. Such sincerity is likely to help build the trust that's needed for teams to be successful.

Are you aware of the "invisible gun effect"? This is a phenomenon whereby your position within the organization creates a power imbalance, and your ability to use that power ("fire the gun") means that others may see you holding that gun, even if you haven't any intention of ever firing it. In fact, you might not even be aware that you're carrying a gun, and it's totally invisible to you; but when you enter a room, it's the first thing everyone sees.

See: https://www.agilealliance.org/wp-content/uploads/2016/01/AgileAntipatte…

Typically, a Scrum Team includes five to eleven people who share the various tasks and responsibilities related to the delivery of the project/product. It is a group of self-motivated individuals who work collaboratively towards successful product delivery. A high level of communication is expected between the Scrum Team members to ensure they are focused on the same goal while maintaining mutual respect throughout the process. Also, they share a common set of norms and rules.  

The three pillars of a Scrum Team are as follows: 

• Transparency

Everyone in the team will have an easy and transparent flow of information about the common goal and the roles and responsibilities of each individual.  

• Inspection

All team members are entitled to do timely checks on the progress towards a common goal.  

• Adaptation 

An agile Scrum Team adapts to changes as soon as possible to optimize the product value. 

Hi Malleshkumar, As of 2020 Scrum Guide, the recommended Team size is typically 10 or fewer. Is your mention of Scrum Team size being five to eleven from your organization or past experiences? You may want to qualify it as such as not to confuse anyone learning Scrum.

Not suggesting that empirical pillars can't be applied in a Team sense, but this is not from the Scrum Guide and may be misleading to folks learning the framework. There is a key connection between the pillars and Events and Artifacts and Commitments...

Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.

 Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.

For Scrum Teams and the Accountabilities within, being cross-functional and self-managing are important along with Scrum Values.

This all converges with the following statement where the Scrum Team embodies the values which brings pillars to life...

When these values are embodied by the Scrum Team and the people they work with, the empirical Scrum pillars of transparency, inspection, and adaptation come to life building trust.