I’m going to post this response here and I guess the other thread lol
Can a baseball team function without a coach and one of the players acting as the coach? Yes. Then why does every baseball team have a coach? A Scrum Master is meant to be like a Scrum Team coach.
It’s not that you as a developer cannot do the duties of a Scrum Master, obviously you are Capable of it but it’s more a matter of splitting your time and the consequences of that. Which could be…
- It takes away from your development time and could cause more stress on yourself than necessary possibly affecting your own sustainable pace.
- If you look at what a scrum master does, I don’t see how you could be fully doing a SM job while focusing on development. What I imagine you are doing is more of facilitating ceremonies (which is just one responsibility of a SM) if you are doing more than this then it goes back to my point number 1.
- I’m giving you this from my perspective but a good SM does whatever it takes to make the team successful. @cusack gave me a great quote last week which i’ll put here… “A Scrum Masters primary role is to help the team discover new opportunities for continuous improvement, while protecting the team from outside influences and distractions”
Part one of the sentence is an ongoing and never ending responsibility. It’s vague yes but that’s intentional because every day it will require something different. If a SM has time to focus on continuous improvement he can help the team improve on a daily basis on more of an Agile Coach role for the team.
Part two states that he should be protecting the team from outside influences and distractions, also I believe removing impediments should also be part of this sentence. Daily there could be impediments that need to be removed some examples could be…
- Devs computer needs new ram, or he needs a new computer.
- I had a situation on my india teams where every thursday the power kept shutting off and the team was sitting in the dark in 100 degrees getting bit by mosquitos. Now WHY they didn’t just work from home, that’s a discussion for another time. As a Scrum Master, I had to deal with this issue to ensure this problem didn’t happen anymore.
- AN impediment could be something as simple as, a team member has a new baby and got 2 hours of sleep last night. They show up to work and are exhausted already and they know they have a full day of work ahead of them. As a SM it’s his/her job to help this person, help the team in an effective way. What does that entail? Well that’s up to the individual, maybe I have to go to starbucks and get a triple shot.
I’ve been learning a lot from Dave Prior recently about his past experiences as a Scrum Master at Skype and Netflix I believe. He has told me a few stories…
One team he was the SM for, the most brilliant person was an Alcoholic and could not function without drinking. Some mornings he would have to drive to the dudes house and drag him out of bed.
Another team, a guy would get stoned at lunch and go play racquetball and come back high and sweaty every day.
Another team someone was a crystal meth addict. The SM has to deal with ALL people issues which is going to be different from team to team.
Team Dynamics…
-
There are team dynamics that the scrum master should be removed from to help improve the team. Meaning people have issues, egos, different ways of working etc. The scrum master should not be involved in these team dynamics, he should be a neutral party.
-
Example: A team member felt like they were being treated unfairly by other team members because they were asked to do other work outside of the scope of the sprint that he felt other team members were not asked to do. I wasn’t aware of this because this person never spoke up about it until it came to a climax and he was approaching me privately. As a SM there are a few things I had to do here, one is find out WHY outside influence and distraction was happening to my team. Once I figured that out, I had to deal with team dynamics and try to get them back to at least norming state. I had one on ones with different team members until I felt like I understood what the hell was happening and came up with a solution which in the end thankfully worked and the team is doing very well right now. This is not to pat myself on the back as of course i’m giving you a small success story and not any mistakes haha but the point is, this took TIME, energy, soft skills like ability to listen, discern, and comfort, and lastly problem solve. If I had to do all this WHILE trying to meet a commitment to sprint as a developer, I don’t see how it would be possible. And this is just one small example of a million I could potentially give.
And last thing I’ll say about this is… Check out this checklist of SOME of the duties of a scrum master and honestly tell me if one person can do this WHILE being a full time developer and not having it affect the team performance and commitments.
http://scrummasterchecklist.org/pdf/ScrumMaster_Checklist_12_unbranded.pdf
" A Full Time Facilitator?
An Example Checklist for ScrumMasters
Michael James (mj4scrum@gmail.com) 14 September 2007 (Revised 2 Feb 2016)
An adequate ScrumMaster can handle two or three teams at a time. If you’re content to limit your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation at your organization, and probably nothing catastrophic will happen.
But if you can envision a team that has a great time accomplishing things no one previously thought possible, within a transformed organization, consider being a great ScrumMaster.
A great ScrumMaster can handle one team at a time.
We recommend one dedicated ScrumMaster per team of about seven when starting out.
If you haven’t discovered all the work there is to do, tune in to your Product Owner, your team, your team’s engineering practices, and the organization outside your team. While there’s no single prescription for everyone, I’ve outlined typical things I’ve seen ScrumMasters overlook. Please mark each box with √, ∆, ?, or N/A, as described on the last page.
Part I – How Is My Product Owner Doing?
ScrumMasters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog and release plan. (Note that the Product Owner is the one responsible for the prioritized backlog.)
☐ Is the Product Backlog prioritized according to his/her latest thinking?
☐ Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the
backlog is emergent.
☐ Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more granular towards the top, with general epics at the bottom. It’s counterproductive to overanalyze too far past the top of the Product Backlog. Your requirements will change in an ongoing conversation between the developing product and the stakeholders/customers.
☐ Could any requirements (especially those near the top of the Product Backlog) be better expressed as independent, negotiable, valuable, estimable, small, and testable user stories1?
☐ Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be to write automated test and refactoring into the definition of “done” for each backlog item.
☐ Is the backlog an information radiator, immediately visible to all stakeholders?
☐ If you’re using an automated tool for backlog management, does everyone know how to use it easily? Automated management tools introduce the danger of becoming information refrigerators without active radiation from the ScrumMaster.
1 http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Copyright © 2007-2016 Michael James. All Rights Reserved.
☐ Can you help radiate information by showing everyone printouts?
☐ Can you help radiate information by creating big visible charts?
☐ Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?
☐ Does everyone know whether the release plan still matches reality? You might try showing everyone Product/ Release Burndown Charts2 after the items have been acknowledged as “done” during every Sprint Review Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery of scope/schedule drift.
☐ Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product Owners who ship adequately tested products on time re-plan the release every Sprint. This probably requires deferring some work for future releases as more important work is discovered.
Part II – How Is My Team Doing?
While you are encouraged to lead by the example of collaborating with team members on their work, there is a
risk you will get lost in technical tasks. Consider your primary responsibilities to the team:
☐ Is your team in the state of flow? Some characteristics of this state3:
• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with
one’s skill set and abilities).
• Concentration and focus, a high degree of concentration on a limited field of attention.
• A loss of the feeling of self-consciousness, the merging of action and awareness.
• Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that behavior can be adjusted as needed).
• Balance between ability level and challenge (the activity is neither too easy nor too difficult).
• A sense of personal control over the situation or activity.
• The activity is intrinsically rewarding, so there is an effortlessness of action.
☐ Do team members seem to like each other, goof off together, and celebrate each other’s success?
☐ Do team members hold each other accountable to high standards, and challenge each other to grow?
☐ Are there issues/opportunities the team isn’t discussing because they’re too uncomfortable?4
☐ Have you tried a variety of formats and locations for Sprint Retrospective Meetings?5
☐ Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the Product Backlog Items committed for this Sprint.
2 Mike Cohn, Agile Estimation and Planning. (2005).
3 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
4 Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships (2003). Also consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable.
5 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).
Copyright © 2007-2016 Michael James. All Rights Reserved.
☐ Does the Sprint taskboard reflect what the team is actually doing? Beware the “dark matter” of undisclosed tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to those commitments.
☐ Does your team have 3-9 people with a sufficient mix of skills to build a potentially shippable product increment?
☐ Is your team’s taskboard up to date?
☐ Are the team self-management artifacts visible to the team, convenient for the team to use?
☐ Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside the team may impede team internal transparency and self management.
☐ Do team members volunteer for tasks?
☐ Has the need for technical debt repayment been made explicit in the definition of done, gradually making the
code a more pleasant place to work?
☐ Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects of agreed work (testing, user documentation, etc.)?
Part III – How Are Our Engineering Practices Doing?
☐ Does your system in development have a “push to test” button allowing anyone (same team or different team) to conveniently detect when they’ve caused a regression failure (broken previously-working functionality)? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
☐ Do you have an appropriate balance of automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?
☐ Is the team writing both system tests and unit tests in the same language as the system they’re developing? Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset of the team knows how to maintain.
☐ Has your team discovered the useful gray area between system tests and unit tests6?
☐ Does a continuous integration7 server automatically sound an alarm when someone causes a regression
failure? Can this feedback loop be reduced to hours or minutes? (“Daily builds are for wimps.” – Kent Beck)
☐ Do all tests roll up into the continuous integration server result?
☐ Have team members discovered the joy of continuous design and constant refactoring8, as an alternative to Big Up Front Design? Refactoring has a strict definition: changing internal structure without changing external behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling between objects, etc. Refactoring with confidence is only possible with automated test coverage. Neglecting
6 http://blogs.collab.net/agile/junit-is-not-just-for-unit-testing-anymore
7 http://www.martinfowler.com/articles/continuousIntegration.html
8 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).
Copyright © 2007-2016 Michael James. All Rights Reserved.
refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers willing to work on bad code.
☐ Does your definition of “done” for each Product Backlog Item include full automated test coverage and refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.
☐ Are team members pair programming most of the time? Pair programming may dramatically increase code maintainability and reduce bug rates. It challenges people’s boundaries and sometimes seems to take longer (if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.
Part IV – How Is The Organization Doing?
☐ Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to achieve this, and rarely the best.9
☐ Are teams independently able to produce working features, even spanning architectural boundaries?10
☐ Are your ScrumMasters meeting with each other, working the organizational impediments list?
☐ When appropriate, are the organizational impediments pasted to the wall of the development director’s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But
11 learnfromKenSchwaber’smistakes:“AdeadScrumMasterisauselessScrumMaster.” )
☐ Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer “no” if there’s a career incentive12 to do programming or architecture work at the expense of testing, test automation, or user documentation.
☐ Has your organization been recognized by the trade press or other independent sources as one of the best places to work, or a leader in your industry?
☐ Are you creating a learning organization?
Conclusion
If you can check off most of these items and still have time left during the day, I’d like to hear from you.
There’s no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in your situation.
