Thursday, December 22, 2011

Responsibilities of the SM

The responsibilities of the SM are a long list:

PROCESS: Responsible for the entire Scrum process - Leader and
motivator about doing Scrum:
. ensures Artifact quality
. helps and coaches Roles to do their job: product owner, customer, developers
. ordering of activities, meetings, time-boxes
. sets up, conducts and facilitates ALL meetings
. ensures Engineering practices are followed
. Ensures the Team has a good social context, a good environment, and it is SWARMING!
. Enforces ALL rules
. Promotes ALL values: transparency, honesty, courage
. Insurance for "doing things right. Intervene only if necessary!

TEAM: Flips between Coach, a Watchdog, a Mentor and a Project Manager,Rep to Management
. Recommends or finds initial members of team
. Responsible for team balance: how many BAs, developers, testers, etc. of what kind?
. The Scrum Master is responsible for setting the team up for success
. Removing the barriers between development and the customer so the customer or the user directly drives development
. Ensuring team actually did what they said they would do: checking testing reports, etc.
. Balancing the team workload - e.g. pass work to early finishers
. Shielding the team from outside disturbances
. Removing Impediments and resolving issues
. Promoting creativity, collaboration and knowledge sharing
. Improving the lives of the development team e.g. flexible hours, flexible days, payback for heroics, etc.
. Improving the productivity of the development team in any way possible: training, tools, system-level things
. Improving the engineering practices and tools so each increment of functionality is potentially shippable
. Promote team pride
. Organizes Celebrations after releases or sometimes after Sprints

CUSTOMER: Teaches the customer how to maximize ROI and meet their objectives through Scrum
PO: Responsible for training and keeping ongoing communication with Product Owner (good PB!)

ADMIN: Maintaining the Sprint Backlog and producing Sprint Burndowns
. Posting the Sprint Burndown as Visible Status: Wall, Wiki, email, etc.
. Ensuring Scrum Board gets updated

MANAGEMENT: representative to team for management

MULTI-TEAM: Participating in the Scrum of Scrums such that both how their team affects other teams, and how other teams affects his team are understood, if no other team member is available
. Coordinating participation of their team in either the "big room" Sprint Planning Meeting, or in a staggered Sprint Planning Meeting understanding dependencies, or coordinating with architects when they exist
. Coordinating participation in the Sprint Review Meeting, both independently and with the rest of the multi-team, the latter is specially important in releases to production where many dependencies exist
. Coordinating with integration Sprints when they exist
. Coordinating integration issues with other Teams
. Working with their team or theme PO and with the CPO (chief product owner), to ensure their teams can choose portions of the Product
Backlog (usually though themes)
. Coordinating with their individual teams on dependencies or modified work found at the Scrum of Scrums

If you can do all of the above while "developing code".. More power to you, but don't compromise the above tasks for speed i.e. getting more code done, because you may compromise the work of everyone in the team instead.

This article is by Mike Beedle and borrowed from

Saturday, October 15, 2011

Agile Testing

I had an opportunity last week to present a session on agile testing to a group of QA teams.

It was a wonderful session, we had a group of people from different QA teams all part of some or other waterfall way of projects. Every one asked lot of questions and were quite inquisitive about how agile project progress.

I am attaching the presentation which is quite simple but lead to a lot of good discussion.

Monday, September 5, 2011

Doing year end appraisals in SCRUM projects

This is a wonderful discussion, I'm sure it'll be very helpful in the industry often. Just want to preserve it.

Begin forwarded message:
From: Madhur Kathuria <
Date: 5 September 2011 11:18:38 GMT+08:00

Though there can be essays written about how an appraisal method is better or worse than the other one, it is important that there is a pragmatic approach taken to identify the facets of the appraisal process which answer concerns from all functions

By simply saying that non-engineering functions do not understand Scrum seems to me like running away from the responsibility of taking everybody along on the same journey path to Agile benefits

So, I would recommend the coaches to take inputs from the previous data and some of the experiences provided in similar forums like this and decide what works for them by involving everyone in the process mapping exercise.

On 3 September 2011 17:17, ashu tosh < wrote:


Year End appraisals in software industry are considered to be medium for final Ratings which impacts your compensation & promotions.

Now as SCRUM is team work and team decides for tasks to be given to whom so I am not sure considering contributions will help people in accepting the ratings

On top of it, now a days HR has started introducing Quaterly appraisals which can have negative impact on team members because on one side we are talking about removing obstacles and delivering more and on another side we are discussing the output as part of appraislas.

Since there are organizations who adopted SCRUM at a large level like salesforce or yahoo so it can be good if we can try to get some inputs from these organizations.

May be we can decide this as the topic for next scrum meet in Delhi region.

--- In, Vikrama Dhiman <vickydhiman@... wrote:
Madhur wrote:
Typically, 60-70% of the rating of a team members should be governed by the teamfulfillingtheir team goals every sprint.
I am not sure about that one. If compliance with team goals is what is being measured, teams will never set a stretch goal and you are also likely discouraging failure and risk. In the best case, this sorts of rewards right estimation, which again is something debatable. If a team set a goal at 100 and achieved 80, and another set a goal at 60 and achieved 65 - who did better [assuming all goals are standardized - which again is highly unlikely.]
The number 1 challenge in an appraisal process is what data to collect and second is how to assess people on it. Data I have recommended is [collected and appraised quarterly]:
See how the team thinks it did in a quarter
See how PO thinks it did in that quarter
See how team thinks each team member did it in a quarter - on parameters like learning, performance, contribution
See how the manager thinks each team member did in a quarter OR The Scrum Master provides information to HR about that [note the SM is not judging the performance, just providing the information]
See how the individual member thinks he did in a quarterSee the obstacle list at the start of the quarter and end - and find out if there are major obstacles that are stopping team across the board from achieving potentialHave the team present a report on what they have achieved in the quarter to an appraisal panel - comprising of random members from across the organization

Make sure you have clear numbers and data. You can keep a track of qualitative data too - for instance, if you want to reward going beyond the call of duty or collaboration, managers need to record that data regularly.
Now, with all this data, you can see what appraisal/ increments should be given. Share the criteria and formulas used publicly and debate them before adoption.
Also, here is what you should do as a Priority Number 1
Make sure HR/ Accounts/ Management understands Scrum. Organize a workshop for them and involve them as part of the change.
Most often these functions don't understand Scrum and that's where disconnect happens.
I have never seen a "fair" and "objective" appraisal process interfere with Scrum. What hampers Scrum is different perceptions on "fairness" of appraisal process. Address that and you'll be good.
Happy to answer any further questions!
--- On Fri, 9/2/11, Tarun Sharma <superchamp1232002@... wrote:
From: Tarun Sharma <superchamp1232002@...


I completely agree with Madhur and just to add below can also be helpful for appraisal -

1. Sprint Backlog can be used to know individual velocity over a period of time to understand invidiual contribution to the team.
2. Rotating coordinator roles such as Standup coordinator, user story and QA coordinator, show and tell cooridnator, testing coordinatoretc helps to understand
and review the way individuals take initiatives in the team

From: Amit Mehra (Bgh) <amit.mehra@...
Sent: Friday, 2 September 2011, 6:42
I read Madhur's reply after sending my email. Just want to add that I agree with what Madhur has stated. These are the line of thoughts on which teams need to experiment.

Amit Mehra

Sent: Thursday, September 01, 2011 9:25 PM
Hi Ashutosh,
Team factor is a major area in appraisals for the agile team.
Typically, 60-70% of the rating of a team members should be governed by the teamfulfillingtheir team goals every sprint.
about 10-20%weight-ageis given to an individual members through the ratings received from other team members. This can be done through a 360 degree feedback survey
Rest of theweight-ageis given to the team member fulfilling his/her learning and growth targets for the appraisal year.
As part of the appraisal, it is essential that the manager is part of the team review and planning meetings (more as a silent chicken) and get the smells and the undercurrents from the teambehavior.

As i have been stating in my earlier posts, by no means is the above suggested combination the final word towards a good agile team appraisal. This can more be a guide rail with the final division being decided based on the team environment and management considerations
With Regards,
Madhur Kathuria, CSC, CSP, CSM, CSA
On 1 September 2011 15:59, Riju Kansal <riju.kansal@... wrote:

This is the most difficult part of the year.
My 2 cents: Ideally there shouldnt be any competition within a scrum team. It was a team effort and each team member helped achieve successful done state for each story. So if the team's work got appreciated and was visible clearly to the management they all should get appropriate equal ratings. This may differ in case there were clear attitude issues with a team member.
-Riju VK
On 1 Sep 2011, at 13:50, "ashu tosh" <goyalashutosh11@... wrote:
Recently I have switched to SCRUM methodology in executing the projects. MY CSM training and this blog is helping me alot.
I wanted to know how appraisals should be done differently in SCRUM based projects because during sprints we never focused on the couting defects leaked by individual team members. At that point of time, focus was to identify improvement areas and deliver better.

Sunday, September 4, 2011

Day 1 at scrum team

We have just got started with our scrum team today.

We are a team of six plus PO, SM and BA. We had our daily standup meeting with updates from "The Team" including Dev and QA guys. We also had SCRUM Master, Delivery Manager, QA Manager and BA present during our stand up but they did not give any updates.

Our new scrum master gave us a quick overview of how we are going to proceed, little bit about the meetings and how the backlog will be filled. We plan to have a quick planning meeting in the afternoon where we are going to discuss the ongoing tasks. So now a little background, we are an existing team with developers and testers taking on delivery items from two to three lines of business. The businesses directly contact testers and devs to giv and teak the detail and get started with the work. The QA team has to give signoff for the changes and it is considered as go ahead for a release.

So we are basically in our sprint zero the delivery manager and scrum master have taken this task of roling out SCRUM for the team and they are trying hard for it.

Lots of Good Luck to the new SCRUM Team.

Please access the attached hyperlink for an important electronic communications disclaimer:

Saturday, September 3, 2011

The indispensable traits of a Scrum Master

The indispensable traits of a Scrum Master are:
- emotional stability
- consistency
- diplomacy
- empathy
- good communication
- intuition
- good negotiator
- courage

These are all "soft" skills, so technical knowledge is irrelevant.

But if the SM determines that she wants to lead the team into adopting technical practices (unit testing, acceptance testing, simple design, refactoring, TDD etc.), some level of technical knowledge is beneficial to "getting the word across", and even providing initial training.