Scrum considers tracking the time individuals spend on individual tasks to be wasteful effort. Scrum is only concerned about time when it comes to the time boxes of the Sprint and Sprint meetings. Scrum also supports sustainable development, which implies working sustainable hours. When it comes to the completion of tasks, the team is committed to delivering value. The tasks in the Sprint Backlog represent the remaining tasks that the team has identified for delivering on its committed increment of potentially shippable value for the current Sprint. The tasks themselves have no value and therefore should not be tracked. Scrum is only concerned about burning down to value delivered. Time spent on individual tasks is irrelevant. What if I track my hours or my “actual” time on tasks? This promotes a culture of “bums in seats” – that it is more important for people to be busy at any cost instead of getting valuable, high-quality results. This also promotes bad habits such as forcing work into billable hours even though it is not. Overall, time tracking in a Scrum environment does much harm and can undermine the entire framework.
Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual. The team reporting structure should be flat. This does not necessarily mean that all Team Members are peers in the org chart. For example, one team member could be quite senior, and another quite junior. However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do. Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team. If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team. If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.
All tasks done by individuals on a Scrum Team must be chosen voluntarily. If one Team Member, in any way, tells another Team Member what task to work on, this breaks the principle of self-organization that is essential to creating a high-performance Scrum team. Team leads, project managers, functional managers and other people in roles of authority to assign tasks must give up that authority completely when it comes to the people on a Scrum team. This self-organizing behavior allows individual team members to consider their own talents, capacity, interest, motivation etc., when choosing a task. All of those inner conditions are not as well known by other people and so assigning tasks tends to be sub-optimal. When a Team Member considers those inner conditions about him or her self, and also takes into consideration the needs of the team, an optimal task choice can be made. If someone in a position of authority does assign tasks, it creates a habit of deferring to authority which quickly destroys any possibility of a high-performance team developing.
The Sprint Retrospective meeting supports the Scrum value of Openness and the principle of inspect and adapt. This rule of Scrum also aligns with the Agile Manifesto principles “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members which in turn is necessary to use the Retrospective to find improvements in how the team functions. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership of improvement efforts. Lack of in-person participation increases the likelihood that the team will fail to implement improvements because the openness and inspect and adapt will lack effectiveness. This, in turn, hinders the team from reaching a high-performance state.
This rule of Scrum aligns with the Agile Manifesto principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” In-person attendance of all Scrum Team members allows for the plan to unfold with minimal communication overhead and for the team to keep the meeting within the short time-box. In-person attendance also allows the team to effectively collaborate in the work of creating the plan. The efficiency and effectiveness of the Product Owner’s presentation of the Product Backlog is optimized as well as the Development Team’s ability to collaboratively assess and select what it can and will accomplish in the Sprint. It also allows for everyone to be clear about the Sprint Goal and why the Development Team is building the increment. In-person attendance also allows the Development team to efficiently and effectively come to a decision as to how it will build the increment of functionality. In-person participation of all team members also increases the likelihood that the team will create the right design for the increment. If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the planning becomes compromised. Compromised collaborative planning yields compromised collective ownership. The successful delivery of the Sprint Goal requires full commitment on the part of the whole team. Lack of in-person participation increases the likelihood that the team will fail to deliver on its Goal because the planning will lack effectiveness. People are prone to estrangement from hazy goals reached through ineffective planning. In-person planning, therefore, is paramount to succeeding with Scrum.
The Agile Manifesto is the founding document of the Agile movement. It can be found at http://www.agilemanifesto.org and if you haven’t read it, it is strongly recommended! Living values and principles is an act of striving for excellence. There are no mechanisms in Scrum to force people to live the values and principles of the Agile Manifesto. Scrum relies on individual team members to strive to develop an understanding and practice of Agile values and principles in and of their own volition. If Team Members do not live the values and principles of the Agile Manifesto in their team many other things will take priority such as creating a complex document. The team could think of Scrum as a tool for project delivery, without really working to change the culture of their organization. Since Scrum empowers individuals and makes obstacles visible, if the team doesn’t live the Agile Manifesto principles then they may be disconnected from the roots of Scrum and make it a lesser version of itself, sometimes known as Scrumerfall (where you blend some elements of Scrum with other elements of waterfall which provides little to no benefit).
The Definition of “Done” for a Scrum Team makes transparent how close the team’s work is coming to being shippable at the end of every Sprint. Expanding the Definition of “Done” until the team is able to ship their product increment every Sprint is a process that every Team Member helps advance. Team Members expand the Definition of “Done” by learning new skills, developing trust and gaining authority to do work, automating repetitive activities, and finding and eliminating wasteful activities. When every Team Member is systematically expanding the Definition of “Done”, the team builds its capacity to satisfy business needs without relying on outside people, groups or resources. If Team Members are not actively working on this, then many of the obstacles to becoming a high-performance team will not be discovered.
Scrum Team Members, excluding the ScrumMaster and Product Owner, must be completely open-minded to learning new skills. Skills can be technical, business, personal, tools-based, etc. A Team Member is sensitive to the needs of the Scrum Team and will learn skills by multiple means as the needs of the team evolve. A Scrum Team where people are not willing to learn new skills will suffer from bottlenecks, time pressure, quality problems, and often will become generally demoralized as the willingness of some people on the team turns into apathy and cynicism when others refuse to learn. In a team where everyone is willing to learn new skills, there will be a consistent raising of capacity and the team will be able to do more and more work more effectively. This attitude is a key requirement for the formation of high performance teams.
A Scrum Team Member is aware of the work that other Team Members are doing, notices if others are struggling with their tasks, and if so, offers to help them. A Scrum Team Member is not just focused on their own personal tasks. This help can be offered as ideas, powerful questions, sharing the work of the task, or even offering simple encouragement. If Team Members are constantly seeking to help each other, this actively contributes to team cohesion, cross-training, and the development of a high-performance team environment. Of course, if people don’t help each other, then individual Team Members may struggle for a long time without making progress and overall productivity will be dramatically hindered.
The Product Owner brings Product Backlog Items to the Scrum Team to estimate their effort (cost). In order to create the right environment of safety and accountability, no Product Backlog Item is estimated by a single member of the Scrum Team, or even a subset of the team membership. By having all the members of the Scrum Team participate in the estimation work for every Product Backlog item, it becomes impossible to blame a single Team Member for a poor estimate. At a practical level, it is should be very rare that a single Product Backlog Item is fully implemented by a single Team Member. Therefore, estimates should consider the collective effort of the Scrum Team, and this can only be determined by having all the Team Members participate in the estimation work. If the team delegates estimation to a single person, or if one person dominates the estimation work, the other Team Members will not have ownership of the estimates and will be able to deny accountability. The pressure on the team from collective estimation encourages teamwork, cross-training and these behaviours in turn promote the development of a high-performance team.
Purpose: estimate the effort for User Stories (Product Backlog Items, Value Drivers)
Prerequisites: all items have a value estimate, each item is written on a separate note card, full team membership is known and available for planning, each team member has a set of planning game cards
- The team goes through all the items and chooses the one which has the lowest effort. Write the number “2″ on this card (usually in the bottom right corner).
- The team looks at the item with the highest value.
- Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20″ card. It is not permissible to select two cards.
- Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over.
- If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.)
- The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item.
- For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning.
- Once explanations are complete, the team members collect their cards and go back to step three.
- it is extremely important that the voting for an item continues until all team members unanimously vote the same way (this way team members and outside stakeholders cannot blame any individual for “wrong” estimates)
- in Scrum, it is normal for the Product Owner to be present during this process, but not to participate in the voting
- in OpenAgile, it is acceptable for people serving as Growth Facilitators for a team to participate in the voting
- voting should not include extensive discussion
- if more than one person has the lowest or highest vote, usually just one person shares their reason in order to help the process move quickly
- the first few items will often take 10 or 15 rounds of voting before the team arrives at a unanimous vote
- later on, items may take just one or two rounds of voting to arrive at a unanimous decision
- some teams, where trust levels are high, will discard with the use of physical cards and just briefly discuss votes
The planning game is used at the start of a project with the full list of user stories. In this case, it is reasonable to expect the team to average two minutes per user story, and an appropriate amount of time needs to be set aside to accommodate going through the whole list.
The Planning Game is also used any time that there is a change in the list of user stories: re-ordering, adding or removing user stories, or changes to a single user story. When such a change happens, the team can re-estimate any user story in the whole list. When starting a Cycle or Sprint or Iteration, all the user stories in the list should have up-to-date estimates so that estimation work is avoided in the Cycle planning meeting.
Finally, the team can decide to re-estimate any user stories at any time for any reason. However, it is important for team members to remember that estimation is non-value-added work and the time spent on it should be minimized.
Last week I ran an Agile Coach Training session in-house for a large Canadian organization. It was just myself and five other participants. We were discussing possible things to do if there is a person on an agile team who is not able to work effectively in that sort of environment. One “intervention” we discussed was to “Assign Work”…
Now hopefully everyone who just read that phrase “Assign Work” had all sorts of alarm bells go off in their head!!!!
As an Agile coach, I would only do this under extreme circumstances. And I would always be fully aware of the consequence of assigning work. I would be removing that person from the team by Assigning Work. A person is not in an Agile (self-organizing) team if they need to be assigned work.
Guess what?!? THAT is the BIG difference between Agile Teams and Project (or Functional) Teams.
On a project, the Project Manager gets someone onto the team by assigning them work!!!!
On an Agile Team, a person is removed from the team by assigning them work.
Have you seen this happen? How did the assignee feel?
I’ve been researching teamwork lately. I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”. I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team. First stop, Google and a search of “list of teamwork skills”.
Strangely, not much turned up on the first page. The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site. So, here’s my adaptation of their list:
Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects. Active listening requires the ability to not think of your own responses until after a person has finished speaking. One simple way of doing this is to echo what a person is saying in your silent internal voice. When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind. Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.
Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model. Asking questions is easy. Asking good questions is much harder. We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question. For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions. Instead, saying “I do not understand the reason you did that. Could you please explain it to me?” can be a much more gentle way of getting to the same information.
When presenting an idea or position, being able to logically support it is important to exploring the truth of it. This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion. Being able to avoid fallacious logical methods is also important.
Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have. This does not mean that you have to let teammates get away with inappropriate behavior. In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.
Offering help and actually following through with real assistance are aspects of helping. When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions. This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together. When we help someone, we share their burden.
Sharing our knowledge, time, skills or physical resources are all aspects of sharing. Sharing among team members is focused on those things which will help a team reach its goals. This is similar to helping except that it tends to be more of a transaction than an ongoing activity. The transaction is that you give a gift and then the other person uses that gift to meet their needs. Sharing does not require reciprocity. If you share something with another person, you should not expect that that person will return the gift at any time in the future.
It’s probably obvious, but in order to effectively be on a team, you need to participate! Participation itself is mostly obvious: do work with the other team members. However, there are also some less obvious aspects of it. You are not participating when the team is having a discussion, you find it boring, so you check your email. You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree. You are not participating in a work team when you are mentally checked out because of a crisis at home.
All of these skills are critical teamwork skills… but there may be others. Do you think there are other skills missing from this list that are critical for effective teamwork?
Recently I’ve talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?