Scrum enabled development process - role of Team Leader or Solution Architect

Question

I am just curious, since for a scrum-enabled development process the Team Leader (TL) role is merged with Scrum Master (SM) role and the team is supposed to be self-motivated, self-organised and self-driven. Without a Team Leader (and architect!) inside a team - who is making decisions on a future-proof ways on the implementation? Say, which libraries to use, client data-handling, etc. Based on the scrum concept, such decisions should be made by the team collaboratively or by the individual team member. Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come (even one or two years perspective).

How in scrum concept is this addressed, please?

Thanks

Answer 1

Scrum is only the delivery process. Technical decision making should be done by relevant responsible people. Those decisions may come after discussions and team meetings. Team members can also participate to these meetings if required. Role of the scrum master is to make sure the backlog items taken into the sprint is delivered. It has nothing to do with technical decision making. (Scrum master is responsible to remove the blockers and make the team move towards the sprint goal) The team can allocate time for architectural decision making or design/redesign process when they take in a task during the planning meeting.

For example, the TL may have a 4 hour task in scrum board to do the design. If this task involves a meeting with the architect, and the architect is offsite, scrum master should take necessary actions to schedule a meeting and make sure this blocker is removed. May be he can arrange a call between them.

Also it is wrong to think technical leader should be the scrum master. Those are two separate roles and may or may not be the same person.

Answer 2

In Scrum there are three roles defined:

• Scrum Master
• Product Owner
• Development Team

The Scrum Master helps the team to follow Scrum and to remove impediments. The Product Owner looks after the backlog of work and prioritises things.

The Development Team does everything else. There are no defined roles in the Development Team, but instead we have capabilities.

For example, the Development Team has a capability to do development. It also has a capability to do testing.

There is nothing to stop a Development Team having a capability to do architecture. For example, it might have a team member who is from an architecture background or perhaps several team members have architecture experience.

As for the Team Leader role, there is no need for that as everyone in Scrum can act as a leader. For example, if somebody in the team is really experienced in database work, they might show leadership when the team is working on database work items.

who is making decisions on a future-proof ways on the implementation?

The team does.

An experienced Scrum team will get together regularly to talk about 'the big picture'. They will think about the future of the implementation, about the way its architecture, etc.

which libraries to use, client data-handling, etc.

Who has experience making decisions on which libraries to use? They might be a good person to suggest an approach on which libraries to use. The team can then discuss it and agree on an approach. The same goes for client data-handling.

This is collaboration. Everyone has a voice and everyone is a potential leader.

Chances are they will not be qualified/experienced enough and the decision could cost millions in the years to come

If the team is concerned that they don't have enough experience to make important decisions then they should raise that as an issue. Some possible solutions include:

• Get additional training for team members
• Bring somebody into the team with more experience
• Use communities of practice to get advice

Answer 3

The Agile Manifesto directly addresses your question in the Principle that mentions self-organizing teams: "The best architectures, requirements, and designs emerge from self-organizing teams." Relative to the other well-known Agile methods, Scrum perhaps does the best job of trusting "motivated individuals" (per another Principle) to do so using what scientists calls the "group mind." My coaching practice is based on my review of scientific studies related to teamwork. These have shown repeatedly that cross-functional small groups with diverse backgrounds will out-perform a single expert in decision quality over time. Scrum facilitates this by making people plan everybody's work together and holding them accountable to the group through the scrums and Demos.

That doesn't mean you can't have a technical expert like an architect on the team or providing input to the team. I agree with Leni that it's best not to have the technical expert be the SM, as that consolidates too much social power in one role and places further psychological blocks to true self-organization. (Having a full-time SM prevents real self-organization from the social psychology perspective, so I have members rotate the role.) But those experts can serve as advisors by coordinating bottom-up standards development across teams, providing input into user stories, sitting in on various teams' Planning Ceremonies and Demos, etc.