More on this book
Community
Kindle Notes & Highlights
In my experience, any organisation that refers to its people as resources and believes they are fungible is going to really struggle with Scrum.
While Scrum doesn’t mandate that nobody should work on more than one team or project, its values of focus and commitment and its dependence upon teamwork do seem to call for it.
most of which revolved around not having access to the teammates they needed when they needed them.
In the trial sprint the team actually delivered more in two weeks than they had in the previous four-week sprint, mainly because of a greater focus.
The inefficiencies of context switching are widely known so I won’t delve into the science behind it.
Sometimes it will actually make sense for people to be shared across projects, as it would be a complete waste of their time to be entirely focussed on one project if their skills just won’t be needed for the whole sprint.
Most organisations fool themselves into believing that having multiple projects on the go at one time will actually increase their productivity — and the happiness — of their people.
Good ScrumMasters will find ways to help teams make the best of their situations and minimise disturbances, whether that means re-organising the team so that they are able to focus for the sprint or running interference against anyone who is looking to talk to the team about something other than their sprint commitments.
Great ScrumMasters do this at first but also tend to dive deep and find the root cause of team distractions, in this case pushing the problem of multi-tasking at a project level back up the management chain rather than making team members cope with it.
Darryl then displayed a really useful skill of a ScrumMaster—uncomfortable silence.
Allowing the team to voice the issue is far more powerful;
letting the silence become uncomfortable is a great tactic for bringing people into the conversation.
great ScrumMasters will use the conflict within the team to move them forward rather than backwards, even though it is almost always a painful process.
Team formation activities and the establishment of team norms are crucial ScrumMaster’s duties. You shouldn’t necessarily wait until the retrospective to raise issues
You should also avoid taking the first suggestion the team comes up with; instead, keep digging until you are satisfied that the team have covered the real fundamental issue.
BELIEVE A good ScrumMaster will use scrum to help bring out the best in everyone. A great ScrumMaster will use scrum to create a “new best” for everyone.
Believing in the potential of the team first of all requires belief in yourself. This is not an easy task. And yet it is vital. Great ScrumMasters have a positive view of human nature and the capacity for both themselves and others to do great things.
ENQUIRE A good ScrumMaster asks to understand. A great ScrumMaster asks so the team can understand.
You have to believe that you have more to learn from the team than you have to tell the
All great ScrumMasters enquire rather than assume; they resist the temptation to provide answers for the team.
People know when you are listening actively or simply hearing the words. Their behaviour will change simply by knowing that you are genuinely interested in what they have to say. If you listen hard enough, you can even pick up on what they don’t, or won’t, say as well.
Reducing the cost, the fear and the risk of trying something new is key, so make it fun and make it OK to fail. Remember, failure is OK as long as we fail quickly, we fail cheaply and we don’t fail the same way twice.
FACILITATE A good ScrumMaster helps the team find ways to optimise their process. A great ScrumMaster guides the team past the need for process (and a ScrumMaster).
Great ScrumMasters work relentlessly on themselves in order to become excellent facilitators. They introspect, they retrospect, they seek insights from others about their work. And they pair with other ScrumMasters in order to continue their growth.
Their own personal success is judged by how well they facilitate others to do their jobs, by how much they are not noticed or relied upon, and by how quickly and effectively they can step away from the team they have helped create.
how the scrum masters are judged or evaluated !
Scrum is an agile framework, which means it falls under the larger umbrella of the Agile Manifesto [56] and therefore shares the values and principles stated in the Agile Manifesto.
Scrum is usually most useful in environments of complexity, uncertainty and/or change volatility.
Most Scrum teams will begin by creating a release plan to gain an initial view of the viability of the project.
A release plan will take the prioritised and estimated product backlog and provide a rough answer to either “how long will this amount of product backlog take?” or “how much of our product backlog can we expect by this date?”
ScrumMaster Is a Full Time Role
common examples of the part-time ScrumMaster, all of which introduce a conflict of interests to some degree, and examine the pros and cons of each.
product owner is responsible for ensuring that we are doing the right stuff in order to maximise the return on investment of the project or product. The team is responsible for doing the stuff right; to deliver value as quickly as possible while maintaining high quality. The ScrumMaster is responsible for the integrity of the team and the process itself.
There will no longer be any neutral facilitation, no protection of the team or the process. There will always be at least a suspicion of an ulterior motive to every conversation and no sense of safety for the team to grow and experiment. I have never seen these two roles combined successfully.
the dual role of SM/TM compromises both the development efforts of the individual and the effectiveness of the ScrumMaster role, usually leading to lower team velocity, so I strongly discourage it.
Many teams solve this problem by having the SM/TM focus more on the lower risk items, letting the full-time team members tackle the higher risk and higher priority items. This mitigates risk but also means that sometimes the best person isn’t working on the right task.
SM/TMs, however, tend to miss having development work and worry that their development skills will become rusty. This can, over time, cause a significant amount of resentment in the SM/TM.
very common outcome in this scenario is that, towards the end of the sprint, the SM/TM becomes overloaded and has to choose between development tasks and ScrumMaster tasks. When this happens, the SM/TM will fail at one of the dual roles, which is both de-motivating and unfair.
Authority issues
One option to help with this issue is for teams to rotate the role, so that each member of the development team takes on the dual-role for a sprint at a time.
However, you are almost certain to have someone in the team who is either unsuitable for this role, or not happy about taking it on and therefore are almost guaranteed to have at least one sprint where the team struggles.
Almost without fail, the common denominator in all of the teams who have this dual-role is the loss of the ScrumMaster as an organisational change agent.
The people-skills required to be an effective ScrumMaster take up a lot of time. Developing a self-organising team and building the relationships both within the team and between the team and others (such as the product owner, the stakeholders and management) is not an easy thing.
People often argue that focussing on one role for two teams is typically easier, less conflicting and more productive than focussing on two roles for one team. People in this position tell me how it can be beneficial to see a bigger picture outside the scope of a single development team; they can share learning across teams easily and, quite often, resolve impediments that affect multiple teams more efficiently (the old adage of killing two birds with one stone). I have also seen people in this role have greater organisational influence when it comes to removing impediments as they can make
...more
Whenever possible, push for a full-time role Ironically, if you start off as a full-time ScrumMaster, there is a significantly higher likelihood that you could end up as an effective part-time ScrumMaster for multiple teams, as your team will develop their “hairy shoes” much more quickly and be more self-sustaining.
This is a fundamentally important and full-time role. It isn’t really a question of whether the organisation can afford a full-time ScrumMaster but rather whether they can afford not to have one.
Udaykiran Joshi liked this
