This article was published on the Scrum Alliance in Aug 2008.
The Impact of Scrum Mechanisms on People and Task Orientation
Motivated teams develop a reputation of achieving goals and surpassing customer expectations. Sustaining this level of teamwork requires a fine balance between people orientation and task orientation. Scrum is a great way to achieve that balance. Let us see how.Two sides, One Objective
In team situations, there is often a conflict between people orientation and task orientation. If too much attention is given to either aspect, the other could be neglected, impacting the team objective. Scrum mechanisms can help resolve this conflict when implemented in the right spirit and with correct understanding; however, if they are implemented with incorrect or incomplete understanding, they can be counter-productive.
In the following sections, we will discuss several scrum mechanisms as well as the implications for correct and incorrect implementation.
If not implemented correctly: A clear distinction is necessary between stories that the team needs to deliver immediately and stories that can follow later. If the product owner marks everything in the backlog as high priority (perhaps as motivation to encourage teams to fit more work into the sprints), the teams may come out of the planning meeting with the wrong features in their iteration. Misallocated stories results in a product with features not immediately needed by the end user, which only hurts the business.
If not implemented correctly: If a team sets itself non-challenging goals in the sprint planning meeting (translating into less task orientation), it may feel good in the initial sprints when the sprint goals are met but soon will get bored, as there is no thrill in achieving their goals. Eventually, management or the business will take note of the team’s under achievements, resulting in a bad situation. On the other hand, if excessively difficult goals are habitually pushed down the throat of teams in every sprint, there also will be negative effects on the team, leading to situations like burn-out, non-accomplishment of iteration goals, demoralization, key people leaving the team, and so on. Incorrectly deploying this practice can be a team’s downfall. Teams need to realize this and work towards finding the right balance in subsequent sprints even if they started on the wrong foot.
If not implemented correctly: Task-oriented managers may consider the daily scrum meeting to be a boon. The daily scrum gives these managers real-time information about how team members (read individuals on their team) are performing; it could also give them an opportunity to force their viewpoints upon team members. If the task-oriented manager continues to use the daily scrum as a platform for gathering progress and pushing his viewpoints, the team will be demoralized. Team members may eventually stop attending daily scrums or begin withholding information, either of which would be extremely harmful to team performance.
If not implemented correctly: If the concept of inspection and adaptation is not well understood by the team, retrospective meetings could turn into a finger-pointing, blame-game session. If discussions in retrospective meetings are used for political gains by some team members, open participation could be hampered and decisions taken in the meeting could be reluctantly accepted. Excessive focus on improvements or on strengths is harmful. While the first could lead to decreased team confidence, the latter could lead to an unnatural stiffness and acceptance of way of working, thereby indirectly discouraging the team from looking at new/better ways of doing things. If retrospective meetings do not have a problem solving focus, they will be perceived as a waste of time, and teams will quickly become disillusioned with the process. That would be unfortunate.
If not implemented correctly: As with any feedback, giving feedback out-of-context can be very unhelpful in team situations. For instance, if feedback is generalized, it could either create an impression of excessive under-achievement or unreal over-achievement by the team, which would lead to the degradation of team performance in subsequent sprints. Highly task-oriented customers and management can sometimes be too critical of the team’s achievements. That can be disastrous.
Implementing Scrum Mechanisms
Product backlog prioritization
If implemented correctly: Product backlog prioritization gives the business the chance to specify how the team can deliver value to the customer. The team concentrates on the most important activities, as defined by the business, and comes out of the planning session with the best possible scope that it can fit into the iteration. If product backlog planning is implemented correctly, team members know that the work they are doing is important to customers and therefore crucial for the business. This motivates them to deliver faster and with better quality.If not implemented correctly: A clear distinction is necessary between stories that the team needs to deliver immediately and stories that can follow later. If the product owner marks everything in the backlog as high priority (perhaps as motivation to encourage teams to fit more work into the sprints), the teams may come out of the planning meeting with the wrong features in their iteration. Misallocated stories results in a product with features not immediately needed by the end user, which only hurts the business.
Sprint Planning Meeting
If implemented correctly: Sprint Planning meetings give the team an opportunity to display commitment and risk-taking capability. A team whose members jointly give the estimates and agree on them, is more likely to achieve the goal than a team whose members work on the basis of estimations done by someone else. With Scrum, it is the combined responsibility of all team members to meet the commitment. Combined responsibility translates to team members working together during the sprint and supporting each other to meet the sprint goal set at the beginning of the sprint. It is up to the team members, the ScrumMaster and the Product Owner to ensure that the team takes up a challenging goal in the sprint planning meeting. It is important that all team members participate during the sprint planning meeting so that everyone agrees that achieving the goal together is possible. When the team achieves a challenging goal, not only is the task orientation aspect of the project satisfied, but team members get a great sense of accomplishment as well.If not implemented correctly: If a team sets itself non-challenging goals in the sprint planning meeting (translating into less task orientation), it may feel good in the initial sprints when the sprint goals are met but soon will get bored, as there is no thrill in achieving their goals. Eventually, management or the business will take note of the team’s under achievements, resulting in a bad situation. On the other hand, if excessively difficult goals are habitually pushed down the throat of teams in every sprint, there also will be negative effects on the team, leading to situations like burn-out, non-accomplishment of iteration goals, demoralization, key people leaving the team, and so on. Incorrectly deploying this practice can be a team’s downfall. Teams need to realize this and work towards finding the right balance in subsequent sprints even if they started on the wrong foot.
Daily Scrum Meeting
If implemented correctly: Daily Scrum meetings make visible to the entire team those issues which, without daily scrums, would be partly or totally invisible. Not only do daily scrums help uncover dependencies, impediments, and the real-time status of tasks, they also indirectly show patterns that can help team members realize how they are performing as a group. Individual traits such as performance (good or bad), need for training, ramp-up, and helpfulness are showcased during these daily Scrum meetings. This often creates peer pressure in lagging team members, making them perform better than before, and leads to better team performance from a task-orientation perspective. From a people-orientation perspective, daily Scrums are a time to address the genuine needs and constraints of team members and for team members to support each other in times of need. Regular contact also brings positive feedback, such as appreciation for things one team member did to support another that might otherwise go unnoticed. This makes even small contributions to the project visible to everyone. As a result, people feel cared for, which helps create an environment that motivates them. Many small contributions add up to a big positive impact on the project.If not implemented correctly: Task-oriented managers may consider the daily scrum meeting to be a boon. The daily scrum gives these managers real-time information about how team members (read individuals on their team) are performing; it could also give them an opportunity to force their viewpoints upon team members. If the task-oriented manager continues to use the daily scrum as a platform for gathering progress and pushing his viewpoints, the team will be demoralized. Team members may eventually stop attending daily scrums or begin withholding information, either of which would be extremely harmful to team performance.
Retrospective Meeting
If implemented correctly: Scrum teams use the sprint retrospective meetings as an opportunity to fine-tune and make changes to their performance based on experience gained from each sprint. This meeting ensures that team sustains continuous improvements and gives team members a forum to share concerns. It is important that the meeting be moderated well so that the viewpoints of all team members are brought to the table and discussed. From a task-orientation perspective, by looking at both the strengths and weaknesses of the processes that the team followed, this meeting challenges the team to perform at a higher level and achieve better results in each new sprint. From a people-orientation perspective, this meeting boosts team confidence and participation. This happens through sharing and expressing appreciation for the good incidents and help offered / received during the previous sprint. If this meeting is done well, the team takes ownership of action items and implements them in subsequent sprints. The result is an engaged team, in which continuous improvements are sustained.If not implemented correctly: If the concept of inspection and adaptation is not well understood by the team, retrospective meetings could turn into a finger-pointing, blame-game session. If discussions in retrospective meetings are used for political gains by some team members, open participation could be hampered and decisions taken in the meeting could be reluctantly accepted. Excessive focus on improvements or on strengths is harmful. While the first could lead to decreased team confidence, the latter could lead to an unnatural stiffness and acceptance of way of working, thereby indirectly discouraging the team from looking at new/better ways of doing things. If retrospective meetings do not have a problem solving focus, they will be perceived as a waste of time, and teams will quickly become disillusioned with the process. That would be unfortunate.
Sprint Review Meeting
If implemented correctly: Sprint reviews give the team an outlet for demonstrating the valuable additions they have made to business owners and other stakeholders. Sprint reviews also provide the team with valuable feedback about the functionality they have delivered. It is important that the feedback be given and taken in the context of functionalities delivered in the current sprint. Positive feedback keeps teams motivated while constructive criticism helps team create better output in subsequent sprints.If not implemented correctly: As with any feedback, giving feedback out-of-context can be very unhelpful in team situations. For instance, if feedback is generalized, it could either create an impression of excessive under-achievement or unreal over-achievement by the team, which would lead to the degradation of team performance in subsequent sprints. Highly task-oriented customers and management can sometimes be too critical of the team’s achievements. That can be disastrous.
