Coaches for Agile teams and organizations is a growing profession. I’ve been coaching for a long time, and I’ve used/invented/learned-about many different techniques or interventions for coaching in the context of Agile teams. I have recently started a Wiki to capture some of this information. (Originally, I was hoping to write a book, but I don’t have the time to do it on my own or even to coordinate a multi-author effort.) This is an open invitation to participate in the wiki. I won’t make it fully open (like wikipedia), instead, it will be by invitation. Connect with me on LinkedIn and mention you would like to contribute, and I will set you up with an account… and then you can go nuts If there end up being several contributors, I’ll make a block on the front page for links to contributors and/or their organizations.
The Sprint Retrospective is a key meeting where the team discusses how to improve. Like the other meetings in Scrum, the ScrumMaster is responsible for ensuring it occurs and that it is well-facilitated. There are three main purposes of the Sprint Retrospective: honestly review how the last Sprint was conducted in all aspects including skills, relationships, processes, environment, culture and tools; discover the key aspects of the previous Sprint that need to be carried forward or improved; and, plan how the Scrum Team will improve the way it does work. This meeting aids the team in inspecting and adapting the entire use of Scrum and how the team is progressing as a team. The Sprint Retrospective is a check point that helps the team to know its current state, compare to its desired state, identify gaps, and take the needed steps to improve. This meeting is also where the ScrumMaster challenges the team to look deeply at itself and its process without fear. When a Scrum Team fails to hold and participate in this essential meeting, the team is likely to become a Scrum Team in name only without the spirit of Scrum – and therefore lose many of the far reaching benefits that many other Scrum Teams have experienced.
To learn more about using retrospective to help your team improve its processes and teamwork, visit the Scrum Team Assessment.
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?