More on this book
Community
Kindle Notes & Highlights
A good ScrumMaster holds a balanced retrospective. A great ScrumMaster holds a focussed retrospective
A celebration may make the team feel good but it won’t necessarily help them improve. Equally ineffective is listing all the things that went wrong. It may be thorough but it certainly won’t lead to a motivated, engaged team who are hungry to improve. Therefore, it is imperative that a ScrumMaster holds a balanced retrospective.
All the great ScrumMasters I have seen ensure their retrospectives have a hook as well — something that sets the scene for what is about to happen while also pulling people in, grabbing their interest and energising them.
Great ScrumMasters have no issue with starting the retrospective with a challenge based on their own observations,
Even after many years of experimenting with Scrum, the path is still not well trodden and there is still no blueprint for how organisations should be structured and organised in order to be successful.
A good ScrumMaster encourages teams to share skills. A great ScrumMaster encourages teams to share responsibilities.
This often means people need to act outside of their job description and take responsibility for tasks that they are not technically responsible for, or necessarily highly skilled at.
If there is a bottleneck in skills, the team have a responsibility to do what needs to be done, to the best of their collective ability. And sometimes doing nothing (not adding code that can’t be tested) is the best response.
Better yet, they should have found ways to minimize the size of their handoff to the testers in the first place by involving the testers earlier and finding ways to test something.
In contrast, the growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.
Esther Derby says that the only way to deal effectively with turnover on teams is for each member to be doing one thing, learning another, and be teaching a third
Pairing developers with testers can allow testing to be undertaken during coding, and allows that code to evolve in response to the feedback of the ongoing testing process. It is much more collaborative and agile at heart than pairing developers to feed testers.
Another option is for the team to implement some form of kanban-type limits on the stages within a sprint. For example, the team would set a limit of a maximum of two items to be “in test” at any one time. Once that limit is reached, the team then “swarm” around the items at the bottleneck stage to clear the blockage.
they need to understand how taking on new tasks and learning new skills will affect their current jobs, potential incentives, and future promotions. As such, ScrumMasters would do well to facilitate discussions in a clear and gentle, yet firm, manner (and possibly include an HR presence).
A good ScrumMaster helps a team meet their definition of done at the end of the sprint. A great ScrumMaster helps a team extend their definition of done
Great ScrumMasters avoid scrummerfalls and get stuff done inside a sprint by encouraging teams to find ways to integrate testing and development (and other tasks).
Scrum teams, especially new ones, often need to slow down to speed up. As counter-intuitive as it might seem, taking fewer items into the sprint when a team is new and learning allows the team to find ways to work together to get those items done. Plus, partially completed work is of no value to a product owner.
Members of a Scrum team should also be aware that they do not need to be busy 100% of the time—in
Remember the goal is not for each individual to be as productive as possible but rather for the team to be as productive as possible. The former does not necessarily lead to the latter and, in many cases, individual optimisation leads to a diminishing of team productivity.
that it would have been better to try to get one feature completely done than to have many features partially done.
It also avoids the risk of months and months of development of features that end up being misunderstood, incorrect or faulty when we eventually get to the testing and integration phases.
Sometimes, teams find it impossible or impractical to meet the potentially releasable definition of done that Scrum sets. A good ScrumMaster will help the team craft a definition of done that is as good as possible at that moment in time. ScrumMasters will typically find a lot of their time in the early stages of Scrum adoption will be taken up with helping their team find ways to meet that definition of done, even if it is a watered-down version of what Scrum has asked for.
A good ScrumMaster facilitates the sprint review to look back and review the product built in the previous sprint. A great ScrumMaster facilitates the sprint review to look forward and shape the product in future sprints.
The sprint review shouldn’t be a celebration or a narrative report; it shouldn’t need any slide-based presentations or dashboard reports. It should be very tangible, interactive and practical. And there should be a discussion about what the sprint results mean for the team and the project—this
The development team agreed that it had been helpful and also commented that it had been quite nice to sit back and listen to the product owner effectively say to the stakeholders “Look what my team have done this sprint – aren’t they great?”
This product owner–led sprint review, though a bit unconventional, turned out to be one of the best sprint review meetings I have ever seen. Perhaps ironically, it actually broke one of the rules of Scrum.
The more effective Scrum teams involve the product owner continually throughout the sprint, getting feedback on features in real time so that, at the sprint review, the product owner is not surprised about what has or hasn’t been done and the team are not surprised by features getting rejected at the last minute. The more the product owner is involved during the sprint, the less time the team need to spend demonstrating functionality. If there are no surprises, it frees up time during the sprint review for the product owner, stakeholders, and team to proactively collaborate on the future
...more
New Requirements?
New Priorities?
New Estimates?
New Velocity?
New Design?
New Release?
New Process?
Great ScrumMasters will also find out what motivates the people they are serving.
TIP: Find out what motivates the individuals within your team and what motivates them collectively as a team. These are unlikely to be the same thing. You may also be surprised by what you find out and how simple it may be to meet those needs.
“So are you suggesting that we go to Greg and suggest that, by skipping a group of higher priority items and instead bringing some related lower priority items into this Getting To Know You sprint, he could end up with 25% more Greg Dollars than if we just focussed on the highest priority items?”
Both top-down and bottom-up sprint goals can be brilliantly effective. The one approach that I don’t recommend, however, is a forced-fit. In a forced-fit approach, the team take the top priority items from the product backlog and then try to define some sort of sprint goal that fits the items. That is usually unsuccessful and often uninspiring because of the unrelated nature of the high-priority items.
Autonomy The desire to be self-directing and have control over if not what you do then how you do your work
Mastery The desire to get better at what you do
Purpose The knowledge that what you are doing has a reason; that it is contributing to something worthwhile...
This highlight has been truncated due to consecutive passage length restrictions.
A good ScrumMaster updates the sprint burndown to free the team from overhead. A great ScrumMaster helps the team find a fun way to manage themselves visually.
Teams that rebel against the sprint burndown usually are rebelling against the use of the burndown by other parties (perhaps the ScrumMaster or the product owner or even those outside of the direct Scrum team) and will cite a lack of time or unnecessary overhead as an excuse not to continue with the burndown. So while a good ScrumMaster will remove any impediments and reduce the overhead on the team, the great ScrumMaster would reduce that overhead (make it easy for the team to update the burndown or even make it automatic) and also remove any external pressure that may be causing the team to
...more
“We need four hugs a day for survival. We need eight hugs a day for maintenance. We need twelve hugs a day for growth.”
almost laissez-faire paternalistic attitude in their approach to team growth. Great ScrumMasters are very protective of the team, ensuring they are not undermined, distracted or sabotaged and, at the same time, ruthlessly encourage the team to self-manage and self-regulate.
TIP: Facilitate your team to come up with their definition of a great team, drawing from their experiences of great teams in the past. Ask them to spell out the benefits of a great team and what is required both to become a great team and also to maintain that greatness. Look for values and principles that can be applied to any situation as well as specific behaviours that can be applied immediately.
A good ScrumMaster notices areas for improvement in the team. A great ScrumMaster recognises and highlights strengths for the team to build on.
Part of respecting people includes holding a generally positive view of human nature. Because we respect our colleagues, we believe that most people want to do a good job.
Great ScrumMasters help teams first of all become aware of their strengths and then decide how to use them to develop even further.
A good ScrumMaster helps every member of the team grow. A great ScrumMaster fosters the team’s growth.
