What is the engine behind what needs to be done in Scrum? The Scrum Team.

This 2nd article about Scrum of mine will help you familiarize yourself with the Scrum Team and its delegates as well. Here, you'll get a vision of exploring small teams to bigger teams, learning how to cope with challenges and emerge victorious.

1. Commitment

You'd better not look down on this. The need of commiment is vital when it comes to building a Scrum team. Team members needs to internalize the necessary discipline and drive in order to see the project through completion, so if they are unable to commit, then the Scrum process is in danger.

Indeed, the ability to commit is a direct result of how self-empowered a team feels. Of course, commitment can be encouraged by the Scrum Master, the actual one made by each team member is up to him/herself. In short, the first criterion of choosing a candidate for working in Scrum team is that he or she can commit and own the project along with the rest.

2. Building a Scrum team

Remember that a development team should always have some good qualities. These are ideal requirements, despite real-life scenarios in which any organization has to work with what it has. So it's is the Scrum Master that teaches Scrum methods to those who aren't up to speed yet.

Below are some of team attributes which includes:

• Being experieced (yeah, this, we don't often see in real life )
• Being motivated
• Being fully committed
• Being proficient
• Taking pride in their work
• Being able to collaborate with others
• Being autonomous

Being autonomous is one of the colosal parts of being on the team. Creating a well-functioning team involves a part called "giving members the autonomy needed for the project". As Scrum pushes the level of making decision downward along the hierarchy, it's essential that members feel they have the autonomy to become truly invested in the project.

The concept of autonomy contradicts the environment that prevails in many organizations having heavy governance. It is the autonomy that is the component which developers often lack, which prevents them from fully investigating themselves in a project. For example, in some Japanese-style organization, programmers have to get an approval for any source code modification from their superiors like manager/technical leader/team leader along with at least two other members. This kind of dominance might create stultifying impact on a team.

A good measure of real autonomy is necessary here. Before taking pride in the their work, commiting themselves fully and internalize the common goal, team members have to believe that they are the ones "owning" the project". Therefore, if you can't grant the team sufficient autonomy, challenges in transitioning to Scrum is inevitable. Keep in mind that talking responsibility for the project holds the same meaning with owning it and that's the way Scrum teams work.

3. Key Personnel

3.1. The Scrum Master

The ScrumMaster is the team leader of the Scrum team, who makes the project go and keeps it on the right track. It’s up to the ScrumMaster to guarantee that the team meets the sprint goals defined by the Product Owner.

Scrum Master's responsibilities:

• Implements Scrum methods, values & practices
• Teaches Scrum to the Product Owner and the team
• Acts as the leader (aka Project Manager aka Team Leader)
• Facilitates daily meeting
• Eliminating roadblocks/ostacles from the team's path
• Deals with members' problems
• Be ultimately responsible for the success of the project

In the best scenario, experienced teams come together and the chemistry works to get the project off the ground. But it’s the ScrumMaster - the team leader’s job that he/she makes sure all members are motivated.

3.2. The Product Owner

In Agile and Scrum, the factor "customer" is always present through a representative called the Product Owner. The Product Owner takes charge of providing the Scrum team with the requirements for the project.

The Product Owner should be readily available, ideally collocated with the Scrum team. Typically the Product Owner:

• Is a Product Manager himself and talks in terms of requirements and gathers requirements
• Knows all the requirements - SHOULD'NT HAVE TO REFER TO A THIRD PARTIES CONTINUALLY
• Is the voice of the Customer
• Knows the customers' desires and gathers as well as supply that information immediately
• Always is accessible to the team
• Manages Product Backlog
• Sets prioritizes and acceptance criteria for requirements/stories
• Validates the functionality/product delivered in reviews and decides what will actually be delivered

The Product Owner can be a challenging role because it involves being committed to both the Scrum team and the customer. In addition to that, it’s also a tough role due to the heavy responsibility to get the project requirements right. If those are inaccurate and the team goes in the wrong direction as a consequence, accountability lies with the Product Owner.

The team should treat the Product Owner as the final trustworthy source of project requirements, in another word, the go-to person when there’s a question. However, in many case, lack of knowledge is a bottleneck in standard projects, because the Product Owner is often unclear about the answer and thus, needs to refer to someone else. This procedure usually involves phone messages, conferences, and inevitably, delays.

The Product Owner can participate the daily meeting, which can significantly help maintain effective communication although it's not always mandatory.

3.3. The team itself

The team should be seasoned self-driven professionals that are able to coordinate with each other but also given sufficient autonomy to take responsibility for the project and own it at the same time. Being the primary driving force, the team needs to embody all needed to successfully complete the project.

A team’s attributes usually consists of those following:

• Team size of 7 to 12 people
• Cross-functionality
• Full-time commitment
• Being self-organizing, self-directed & self-motivated
• Being autonomous and owning the project
• Being collocated (while distributed teams are possible, they can complicate the process considerably)

The team pick items from the product backlog and moves them to sprint backlogs, based on the priority set by the Product Owner. They estimate how much time they will spend in a sprint to achieve a task and track their progress in burndown charts. They get the work done and take ownership for the project.

4. Rock'n Roll with a distributed Scrum Team

"Distributed team" situation tends to occur within large organizations, in which team members may be anywhere around the world. Although that consitutes some challenges to the Scrum process, there are certain ways to deal with them.

When you have a distributed team, you might run into several significant obstacles:

• Time zone differences
• Communication infrastructures
• Multiple copies of documents
• The impossibility of daily meeting

The backbone of working within a distributed Scrum team is document coordination. Documents help set goals and track progress but it's even more crucial to make everyone has a current copy of all schedules and charts in a distributed way.

(to be continued)