Team Spirit in Scrum
You like to get the German PDF Version, please contact us
The role of the development team
Neither the budget nor the strategies or techniques are responsible for successful IT-projects. The successful realization goes hand in hand with the collaboration of the development team.
As the last two tutorial parts of Scrum (, ) showed, this agile method for software development knows three significant roles. The Product Owner is responsible for giving and prioritizing the requirements and with that making a product backlog. The Scrum Master is responsible for the abidance of the Scrum rules and clears out any kind of impediment that would disturb the work of the team. The third role plays the development team – in the following just called team. All three roles make up the Scrum team which should not be mistaken with the development team.
Teams that work with Scrum are self-organized. But this self-organization is not equal to democracy. Dependent on the time of the project, the experiences and the knowledge of individuals a “leader” develops. The leading of a team is not mandatory, but results from a combination of asking and the capabilities and knowledge of all participants that work together in interdisciplinary teams.
A self-organized unit/team
This self organization has two important advantages, on which the “Scrum-System” is based on. For one part at the end of every single sprint there is a “product potentially shippable” – i.e. a product that is tested and documented and therefore doesn’t change fundamentally and can be integrated in the general system at all time (see below). In this way a delivery to the customer is possible after every sprint. Another advantage of working in self organized teams is, that the combination of diverse abilities allows a view at the tasks and user stories from different sights. The team keeps an overview of the situation, recognizes problems faster and with that it also can find the solution faster.
In the means of Scrum a team is not only a group of people who are working in the same company, department or the same bureau, following the same goal. The creation of a "real" team takes a lot of time. In 1965 Bruce Tuckman presented a simple model for the creation of teams. Regarding this model a team is created in four different phases: creating a team (forming), to recognize and find solutions for conflicts (storming), tasks distribution (norming) and last but not least working together (performing). At a closer look this means for the individual phases the following:
Forming: The group gets together, the people get to know one another and relationships are created. Everyone is looking for her/his place in the team.
Storming: The members of the team identify differences in working and the methods that are used that everyone things of correct and as the best. This results in conflicts that end in discussions where the team members openly discuss their own point of view as clearly as possible. Furthermore here it is important to recognize own and personal limits.
Aid from outside
In this stage it is very important to coach the team. It has to learn to recognize reasons for conflicts and to develop strategies for solutions which should be based on Best practices. A good team coach should not actively interfere in the dynamic of the team. He only acts from the outside and gives a hand that helps the individuals to find independently a proper solution for problems. Using Scrum the Scrum Master takes that role of a coach. He is responsible for the team getting effective and productive through watching over the commitment toward the principles of Scrum. Norming: In this phase the team is defining and implementing all necessary Best Practices for the team procedure in order to clear up everything that could disturb the daily work. In addition in that stage all the capabilities, the expertise and the talents of the individual team members are identified. Performing: At this very last stage the team has developed towards independency and self-esteem. It can clear up most impediments that might appear during the product development itself. The maturity and the efficiency of the used Best Practices improve and optimize continuously and the team reaches its velocity and productivity.
The role of the developing team in Scrum makes the difference between Scrum and many other methods to develop software. Whereas with most other procedures the team gets tasks assigned and a team leader decides on how the tasks have to be fulfilled, with Scrum the team organizes itself entirely. The Product Owner presents the Product Backlog and the tasks prioritized at the planning of a sprint. It’s spoken about details and specialties, so that the team can estimate which of the prioritized tasks can be done as well in the following sprint. The decision is based on negotiation and communication between the team and the Product Owner. They both try to find a way to aim at the best possible solution.
The team as manager
The team acts as manager. Nobody says what needs to be done or which requirements are to meet in the following sprint, but rather it chooses itself from the prioritized Backlog the User Stories (requirements or items) that can be done throughout the following sprint. This is quite a strong change in comparison to the traditional software development. The team is involved from the beginning on and it is the only one responsible for all implementations of the chosen Backlog items during a sprint. Such a procedure ensures the responsibility of the team and as well their ownership. It will learn by doing what it means to develop a potentially shippable product, because at that point of time it already committed to do everything in order to reach the sprint goal set. If the team is not able to finish all the chosen functions until the end of the particular sprint, it reflects together with the Product Owner and the Scrum Master why it could not reach the goal. The reasons are discussed in order to recognize them in the next sprint just in time and to develop strategies for solutions that guaranty a certain quality even in the shortest amount of time and under all possible circumstances. All together they think about how much effort and how much time the undone work will take for the following sprint.
Traditional versus incremental
One fundamental difference between agile methods and the traditional procedures is that the development of a product is done iteratively and the developer can improve already implemented functions as well later on. Traditional procedures typically work with the method of a waterfall, i.e. a product is created in different phases and each with its own specific focus. As an example for this, the phase of setting requirements and the analysis, shall serve.
Figure 3./4. While the Gantt Chart shows the project phases in sequences, Agilo’s Burndown Chart gives the information on the actual status of the sprint
In this phase-oriented method the team tries to describe and to set all the requirements (obligation/delineation) before the actual development even starts. The term “tries” is chosen because the setup usually is based on assumptions and speculations: Only in very few cases all changes and upcoming wishes regarding the product can be recognized from the beginning on. As it is not allowed in the classical method of the waterfall to go back in the individual phases (water does not flow up a hill), this phase asks for a lot of time and effort in order to have a complete list of requirements if possible and with that the result of a good definition of the product. Only after that phase the actual development can begin. The increasing complexity of the products, the velocity that is nowadays used by the market requesting new functions and many other influences increase the uncertainty factor, which is created with the definition of requirements or as the case may be of the product before the development. In order to regulate this complexity there are often formalities and strict processes introduced to the team, which is negative for the velocity of the developing process. Another disadvantage of this method is the fact that the product is implemented and tested as a total. This requests a huge effort regarding integration and fixing bugs. Using the procedure of the waterfall the biggest and known problem is that the developers first see the finished product at a progressed point of time. Since they can first recognize bugs that late, changes are expensive and time-demanding. For example the requirement-management: a wrong requirement can be put through the entire phase of the development of a product.
To realize new ideas immediately
Agile methods such as Scrum are based on iterative and incremental procedures that allow keeping an eye on the “most important” functions. The iterative development makes it possible that the product can be defined for new requests and be improved at any time. The team can realize new ideas contemporarily and make decisions that are based on facts (the present version of the product) and not on speculations (the imagination or the idea of a function). The team has to present a finished version of the product at every end of iteration – using Scrum one sprint lasts two or four weeks – therefore it has to design the new function, implement it, integrate it into the existent software and test it. Only if those tasks are done, the sprint can be called successful. For this there is a cross-functional mode of operation of the team necessary. The aspect of the self-organization is also very important because the deadlines are extremely strict and due to that fact it’s demanded that the team improves continuously its best practices and looks together for solutions. The test automization plays an important role because the product is only done after it has been tested successfully. Without the test automization the team won’t succeed ensuring high quality of all integrated new developments within the short time of a phase of a sprint. In regard of the testing there’ve been created many Best Practices such as Automated Testing, Continuous Integration and Automated Build originally initiated by the Extreme Programming (XP) within the last 15 years.
One of the biggest accomplishments of the iterative, incremental software development is that there is a working product at the end of all iterations and not only at the end of a long development time. The result can possibly be integrated in existent software or it can serve as a basis for the following development. The Product Owner is not dependent on assumptions which functions are correct, wrong or need to be improved. He can stir the development towards the desired direction. For the team which is responsible for the development counts: Rather develop one or two features less, but therefore keep an eye on the shippable product. The prioritization of the beginning, guaranties that the functions the team does not implement during the sprint aren’t the most important ones. At the end of the sprint the Product Owner decides whether it was successful or not in respect to the acceptance criteria set before.
Five disturbing aspects
Despite all intentions and effort it might happen that a team cannot work productively. Patrick Lancioni  describes five aspects that are responsible for a team not acting successful and not “functioning”. The first thing he names is the missing confidence. Team members have to be open to one another. Therefore they have to be able to give positive as well as negative feedback to the other team members, otherwise it won’t work. Without confidence there can be no conflicts solved, which might e.g. result because someone comes up with new ideas. The second aspect is the fear of conflicts which disturbs the work. Obligatory discussions with thought-through comments are the result when the fear to make a mistake or the quest not to face any conflicts is strong. Missing commitment leads Lencioni to the third aspect. Open discussions and saying openly ones’ opinion is the key to a successful Scrum-project. When a team does not have to take responsibility it as well has no good collaboration. No-one wants to be responsible for something they don’t stand up to. It will lead to a disadvantage when the participants don’t keep their eyes on the big picture. Every individual has to put their desire behind the ones of the group as a whole. Only then they can succeed reaching their goal. The just described factors influence one another and are dependent. Without confidence, no bravery for conflicts and without commitment, no big picture.
Scrum in distributed environments
Last but not least a few sentences about Scrum and off shoring. Communication in Scrum holds an important part. Therefore it is totally understandable that the development with Scrum and many other agile methods should be preferably done at only one place (co-located development). In the long run this is not only cost-saving but more effective. One doesn’t have to be preoccupied with different time zones, cultures or breaks of communication. But of course thats not always possible, and there are solutions for distributed teams working with Scrum too.
Tools to support the daily work
The reality shows though that many companies cannot bare distributed development. In this case there need to be some exceptions considered. The team should if possible work as a total at one place which makes the Daily Scrums easier and serves as an assumption for agile methods such as the pair programming. Good online-tools can make the communication and the collaboration of the different working places easier. E.g.: A sprint planning via video conference, or all tools offer the same information at all the places. Scrum tools that are based on the web support the time zones and offer visualized data and they make the daily meetings and the planning easier through a online-whiteboard like in the Scrum tool Agilo fro Scrum. Important is and always will be: The method goes before the tool, but working in distributed environment the right software and a good infrastructure make things a lot easier every day.
Scrum uses the synergies that result from the creation and collaboration of the team. Starting at the thought of individual teams, each five to ten people working hand in hand for one single goal, developing this thought to departments that cross-work together up to an entire organization – the assumption for the realization of a successful project is set. As easy as the realization of Scrum sounds it always depends on the will of all participants to accept changes. And there will be changes – in regard of the company culture, planning of career, structure of the team and also the project leading.
- The Development Team holds the third important part in a Scrum-Project, next to the Product Owner and the Scrum Master.
- The team is self-organized and responsible for a well documented product at the end of a sprint that can be integrated in existent software.
- Since the Development Team works iterative and incremental it can realize new requirements easily and at the same time keep an eye on the desired result.
1) Marion Eickmann:Balance halten; Teil1: Die Rolle des Project Owner; iX 8/09, S. 104, 2) Marion Eickmann; Facettenreich; Teil 2: Die Rolle des Scrum Master; iX 9/09, S.122 3) Patrick Lencioni; The Five Dysfunctions of a Team; San Francisco 2002, ISBN 0-7879-6075-6
is one of the founders and the executive director of agile 42 GmbH and has been working in the section of software development for more than 12 years now. After her pedagogic formation Marion Eickmann specialized in the section of project management, communication and business development especially for the IT and software development-branch. She demonstrated her proficiency in international companies as TogetherSoft Inc. Borland Software Cooperation or NCH International, Bologna. Marion realized in the beginning of 2007 the step to self-employment. Since then she has been realizing projects with her team successfully. Their goal is the introduction and implementation of agile methods such as Scrum. Marion Eickmann publishes articles about Scrum, Traceability, Collaboration and Requirements Engineering continuously.
is the founder of agile42 GmbH and one of the 20 Certified Scrum Coaches in the world. He has been working in the software development and product management as well as the process optimization arena for more than 15 years.
Andrea trained and coached a diverse range of teams and helped many companies in various industries: finance, telecommunication and automotive in implementing agile methods like Scrum. His background includes experience in software and product development, business and functional analysis, lean coaching, organizational change, system architecture and project management.
Andrea serves many customers as a strategic advisor and agile coach and consultant to the IT organization, helping in implementing Scrum effectively with distributed teams. Scrum Alliance Profile: Andrea Tomasini