In this lesson, I want to address two ways in which Scrum teams differ from teams on traditionally managed projects. First, Scum teams are cross-functional. Second, scrum team are self-managing. In a traditionally- managed project, each person has a specific role. The tester tests, the coder codes, and the designer designs. And if the project needs more than one person in any of these roles, the Project forms specialized teams. We might have a test team on the third floor, programmers are on second, and the designers, they're not even in the building. They're from an outside agency. On a Scrum team, we do it differently. We create what is called a cross-functional team. A cross functional team is made up of individuals who together have all of the different skills needed to build whatever it is being developed. So instead of a test team or programming team and a design team Scum will feature a team that has testers, programmers and designers on it. A big advantage to a cross-functional team is that it is self-sufficient. It isn't reliant on another team to do something before it can do its work. As an example, think about the projects that I referred to with designers from an outside agency. The programmers can't start their work until the designers finish the designs, and testers can start working until they hand over some code. When teams are structured like this, there tends to be a lot of waiting time. Cross-functional teams greatly reduce waiting times and the effort to manage dependencies. The common myth about cross-functional teams is that each person needs to have every skill, not at all. The team as a whole needs all of the skills to take an idea from the product backlog and fully implement it. Sure, it's great to team members who can do multiple jobs, a tester who could do some programming, for example. But expecting everyone to every have skill is absolutely not necessary. A second way in which Scrum teams differ from traditional teams is that Scum teams are self-managing. A self managing team chooses how best to accomplish its work. Since the team is closest to the work, we want to give them the freedom and flexibility to figure out how to do it. When team members are empowered to self manage, they develop more pride and ownership of their work A common fear around self-management is that the team will just do what they want. Management asks them to build an e-commerce website, and the teams decides making a video game would be more fun. The first book to mention Scrum, Wicked Problems, Righteous Solutions, by Peter DeGrasse and Leslie Stahl, addressed this concern back in 1990. the author said that control is still exercised, but it is subtle and much of it indirect. How a team self-manages is greatly influenced by leadership decisions. Who is put on the team, the size and nature of the challenge given to the teams, how team members are evaluated and rewarded, How tolerant management is of mistakes, and so on. So self-managing teams in Scrum are not running amok working on whatever team members choose. Rather, self management is about allowing a team to determine how they will tackle a problem.