Sunday, March 11, 2012

ScrumMaster’s Checklist - roles & responsibilities



Last few days many have asked me about the roles & duties of a Scrum Master ( and some even the need of an SM in organization ).

Following is one of the best checklist which I could find. I am willing to help anyone if they need further clarifications.

A ScrumMaster’s Checklist
Posted by Michael James on August 13, 2007


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 you didn’t previously consider 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, especially 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, I’ve outlined some things I’ve seen ScrumMasters overlook.

A.     How is my Product Owner doing? You improve the Product Owner’s effectiveness by helping maintain the Product Backlog and release plan. (Note that only the Product Owner may prioritize the backlog.)

  • Is the Product Backlog prioritized according to his/her latest thinking?
  • Are all the requirements and desirements from all stakeholders for the product captured in the 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 stories?
  • Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle may be adding automated test and refactoring to the definition of “done” for each backlog item.
  • Is the backlog an information radiator, highly 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.
  • Are you working with the tool supplier to use it to its fullest capacity, or to change it to serve you better?
  • Can you help radiate by showing everyone printouts?
  • Can you help radiate by creating big visible charts?
  • Have you helped your Product Owner organize backlog items into appropriate releases (or front burner, back burner, fridge)?
  • Do all stakeholders (including the team) know whether the release plan still matches reality, based on the current velocity (story points per Sprint)?
  • 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 replan the release every Sprint, usually deferring some work for future releases as more important work is discovered. You might try showing everyone the Mike Cohn-style Product/Release Burndown Charts after the items have been acknowledged as “done” during every Sprint Review Meeting. This allows early discovery of scope/schedule drift.


B.    How is my team doing?

  • Are team members spending some of their time in the state of flow? Some characteristics of this state (from Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi)
    • Clear goals (expectations and rules are discernible and goals are attainable and align appropriately with one’s skill set and abilities).
    • Concentrating and focusing, 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.
    • Distorted sense of time – one’s subjective experience of time is altered.
    •  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? See Crucial Conversations: Tools for Talking When Stakes are High. Or consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable
  • Have you tried a variety of formats and locations for Sprint Retrospective Meetings? See Agile Retrospectives: Making Good Teams Great (Esther Derby/Diana Larsen) for some ideas.
  • Has the team kept focus on acceptance criteria? Perhaps you should conduct a mid-Sprint checkup to re-review the acceptance criteria of the product backlog items committed for this Sprint. Will the current Sprint Task list satisfy the acceptance criteria of each committed product backlog item?
  • Does the Sprint Task list reflect what the team is actually doing?
  •  Are your team’s task estimates and/or your taskboard up to date?
  • Are the team self-management artifacts (taskboard, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use?
  • Are these artifacts adequately protected from micromanagers?
  • Do team members volunteer for tasks?
  • Are technical debt repayment items (sapping your team’s velocity) captured in the backlog, or otherwise communicated with the Product Owner?
  • Are team members checking their job titles at the door of the team room?
  • Does the entire team consider itself collectively responsible for testing, user documentation, etc.?
  • Is management measuring the team by collective success?


C.    How are our engineering practices doing?

  •  Does your system in development have a “push to test” button so that anyone (same team or different team) can conveniently detect when they’ve broken it? Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
  • Do you have an appropriate balance between automated end-to-end system tests (a.k.a. “functional tests”) and automated unit tests?
  • Is the team writing both system “functional” tests and unit tests in the same language as the system they’re developing (rather than using proprietary scripting languages or capture playback tools only a subset of the team knows how to maintain)? It’s possible.
  • Has your team discovered the useful gray area between system tests and unit tests?
  • Does a continuous integration server automatically sound an alarm within an hour (or minutes) of someone causing a regression failure? (“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 refactoring , as an alternative to Big Up Front Design? Refactoring has a strict definition: changing the internal structure of a system without changing its 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. Holes in test coverage and deferred refactoring are cancers called technical debt.
  • Does your definition of “done” (acceptance criteria) for each functional Product Backlog Item include full automated test coverage and refactoring?  Youʼre unlikely to build a potentially-shippable products every Sprint without learning eXtreme Programming practices (as described by Kent Beck, Ron Jeffries, etc.).
  • Are team members pair programming most of the time? Pair programming dramatically increases code maintainability and reduces bug rates. But it challenges people’s boundaries and sometimes seems to take longer (if we put quantity over quality). Rather than force people to do this, lead by example by initiating paired workdays with team members. Some of them will start to prefer working this way.


D.    How is the organization doing?

  • Is the appropriate amount of inter-team communication happening? Scrum of Scrums is only one way to achieve this.
  • 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 remember Ken Schwaber’s discovery: “A dead ScrumMaster is a useless ScrumMaster.”)
  • 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 incentive 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 helping to create 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.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a sign you're on the right track.

–mj
Software Process Mentor

  1.  http://blogs.collab.net/agile/2007/08/13/a-scrummasters-checklist/?q=blog/michaeljames/a_scrummasters_checklist
  2. http://scrummasterchecklist.org/pdf/scrummaster_checklist09.pdf


When you send  the email to MJ please keep me also in CC. I will also love to hear if you are able to check all the items and still have time :)

Agile/Scrum Bug fixing: Myths & dysfunctions


I can push bugs to backlog.
We can complete a story without fixing all the bugs
I have to finish all the stories first; the bugs can be fixed later.
Before the release I will have a maintenance sprint which will have only bug fixes.

The list is big. If you are doing anyone of the above please stop doing it before it is too late.
One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with.

My simple advice is to slow down for higher velocity. For short term if try to ignore bugs, it will catch up with you in long term bringing the entire system to a standstill. Yes. I have seen this happening.

Go through the following article. It might help you.
http://www.theagileschool.com/2012/02/scrum-quality-teams-not-delivering-high.html

Tuesday, March 6, 2012

Commitment vs. Forecast : a small but important change to Scrum



This is a great article by Jose Luis Soria

One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of“forecast” in regards to the work selected for a Sprint. We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications.

Read the full article @

http://www.scrum.org/commitment-vs-forecast

Sunday, March 4, 2012

Daily scrum misconception, scrum meeting objectives and different stages of meeting

I talk a lot about scrum. Many times when I speak I hear people saying that they are also doing scrum and they have daily scrum status updates. No other ceremony is so blatantly misused. It’s a misconception that scrum is only about stand ups. I have seen a project manager doing a scrum update with a big team, the status update itself took 1 hour, and the information passed was so huge that nobody remembers anything. By the time the last person updated his “status” the first person would be sleeping. Starting a daily meeting and asking for status update does not falls under Scrum. Many are thinking about “what are the scrum meetings rules” rather than thinking about “why do we need this meeting”. I prefer calling this as Scrum Planning meeting.

This is the planning meeting for the day. I can add the following objectives to the meeting
  • To see if the team is on the correct path, will they complete the committed task if not what changes should be made to accomplish the objective.
  •  Discuss and take actions on the risks faced by the team in meeting the commitments.
Apart from this status update mentality there are some dysfunctions also which should be avoided.

  1. Coming to meeting un-prepared - I have seen many occasions when team members come to meeting without any preparation. They are even unaware of the tasks which they are supposed to work on. 
  2. Big team - Having a meeting with teams bigger than 8-10 people is not effective. The complexity of communication will be huge & time consuming. There will be a high risk of meeting being derailed
  3. Status updates mentality - In many meeting team updates the status of work, there will not be any information about the task to be taken next. They end up updating this information to Scrum Master, Product Owner or other managers if they are present  
  4. The manager Product Owners Many managers are transitioned as Product Owners. They find this meeting as a forum for status update. They go around each one and ask the updates.

  
Even though daily scrum is time-boxed for 15 minutes, there are some pre & post actions which every team should consider.

Stages of a Scrum meeting

Pre – Planning
  • Before the Scrum meeting at least 15 minutes should be spend updating the task boards and other metrics if any. 
  • If any doubt regarding the types of tasks to be pulled then it should be cleared before the actual meeting.
  • If all the committed tasks are finished then team should plan to work on the next item from backlog. They can even do some research work on the items in the product backlog.  
Actual Scrum planning meeting
This is the actual scrum planning meeting
Follow the rules @ http://thetechjungle.blogspot.com/2012/03/daily-scrum-meeting-rules.html

Post Planning actions.
During scrum team might bring something of importance to notice which needs further action/discussions. All such meetings and follow-ups should be taken as the post scrum meeting actions.

Saturday, March 3, 2012

Daily Scrum Meeting Rules

Following are some of the rules which I could think ( & found from other sources) regarding the daily Scrum planning meeting

  • Scrum meeting should be for a small team of 4-8 members. Having a meeting for a bigger team is not beneficial. There is a high risk that it will become a status update.
  • This should be a timeboxed meeting of around 15 minutes. 
  • Hold the Daily Scrum in the same place at the same time every work day. The best time for the meeting is first thing in the day so that Team members think about what they did the day before and what they plan to do today.
  • Stand up – Ensure that team members are standing for this meeting. This will ensure that meeting will not exceed the normal duration as people will be eager to sit down. This will also help to focus on the discussion  otherwise people may get distracted with email or other “tasks”. 
  • Team members should address the Team. This is not a "Reporting to the Scrum Master" meeting. 
  •  If Product Owners are attending the call, they should refrain from asking status. Scrum has a separate meeting for this purpose – Sprint Demo/Review. Status can be obtained from taskboard also.
  •  All Team members are required to attend. If for some reason a Team member can't attend in person, the absent member must either attend by telephone or by having another Team member report on their status.
  •  Team members must be prompt. Team should start the meeting at the appointed time, regardless of who is present. Any members who are late pay a fine that is donated to a worthy charity! 
  • Decide some order for update like start with the person immediately to Scrum Master's  left and proceeding counter clockwise around the room until everyone has spoken. 
  •  Even Scrum Master is not required to attend this meeting. In Scrum Master’s absence or non-availability team should start the meeting.
  •  All team members should be present physically and mentally.
    o Avoid using cell phones, laptops, tablets etc.
    o Team members shouldn’t leave the room after giving the updates. They should remain till the end. 
    o Team members should actively listen and participate in updates from others. 
  •  Each Team member should respond to the following questions:
    o What have you done since the last Daily Scrum regarding this project?
    o What will you do between now and the next Daily Scrum meeting to achieve the sprint goals?
    o What impedes you from performing your work as effectively as possible? 
  • During the meeting only one person talks at a time. Everyone else listens without any side conversations. 
  •  When a Team member reports something that is of interest to other Team members or needs assistance from other Team members, any Team member can immediately arrange for all interested parties to get together after the Daily Scrum Meeting.
  • Non - Team members are welcome to attend the Daily Scrum Meetings but they are not allowed to talk, make faces or otherwise make their presence in the meeting obtrusive.
  • Bring experienced scrummasters or agile coaches to these meetings who can notice the problems and provide a constructive feedback.
These rules are more for new teams who are just beginning to use Scrum. If your team is following scrum for more than one year then you should definitely look into the next version of scrum meeting (scrum 2.0 :D ) 


How Salesforce.com delivered Extraordinary Results through a “Big Bang” Enterprise Agile Revolution

A story of Agile transformation @ salesforce.com
94 % Increase in feature requests delivered - 2007 v. 2006

38 % Increase in feature requests delivered per developer - 2007 v. 2006
Read the following slide for some more staggering data!!!
http://www.slideshare.net/sgreene/scrum-gathering-2008-stockholm-salesforcecom-presentation