Hello Scrum Master.
In general, when you attempt to get a certified Scrum Master or your organization asks you to develop an Agile Team or you are hiring a Scrum Master in your team, what are you actually looking for in person? Or looking for in a Agile?
I am sure, most peope are interested in understanding whether the candidate knows scrum artifacts, ceremony or user stories/points, or about Burn-down charts. Even in the 2 days of intensive training of CSM, the coach primarily focuses on Scrum-Agile. The coach generally is not keen to provide the real vision of a Scrum Master. The coach starts with the scenario of a perfect agile organization and they remain in that boundary. I am not against this pattern, because these 2 days of training intended to accomplish this for CSM only.
Now come to the hiring process of a Scrum Master, what qualities are required for it.
Should the candidate explain Scrums book word? For example What is a Daily Scrum or what you do in retrospective? 90% of interviewers expect to receive what is written in the holy scrum book.
Must the candidate work in scrum tools like TFS or JIRA?
Uhh! Enough now.
My question is, what should we do irrespective of the definitions in the scrum holy book.
In my list the following are processes and activities:
- Create 3 teams, name them D, W & M and list the names. I generally meet about or discuss:
- D: Daily Team, I will include PO, ST and myself. These are the keen people to whom I discuss or chat more. (More than with my GF :) )
- W: Weekly Team, I will included Delivery Manager, Contract person and IT team
- M: Monthly Team, I will include HR, Director, Head of Delivery manage
- Keep the actual activities in all ceremonies, for example 12-01-2014 Ankur reach 9.6 am, not like should Ankur not be late today.
- Do not depend on a single checklist. Each feature or PBI is quite different. Although with a team, mutually understanding creates a common checklist based on Development and Testing. It does not mean to ignore an organization's checklist.
- Checklists and DoD are like Heads and Tales of a Sprint's coin. As a Scrum Master, I would see the agreement of DoD by the PO-Scurm Team on each sprint. There could be chances for multiple DoDs in one sprint. This is because a feature may be different. I will post a separate DoD.
- Look at the Burn Down chart.
- Code Coverage.
- Unit Testing.
- Integration Testing.
- +2 days in Sprint.
- A meaningfull Retrospective Meeting.
If you have sprint of 2 or 3 weeks (10 working days) than you must add 2 extra days. I recommend adding 2 days for the first 3-4 sprint. The Sprint Team needs 4 sprints to be mature, understood, respected, transparent and communicate effectively and efficiently.
Let your team decide and work independently. Which drag scrum master to wait for something to happen? But I would say do not wait. Be predictable, envision and focus. For this, you must create an environment where pure transparency lives. Create a Risk Register. You need to analyze where your member is lacking. For example, a project has been contracted to using jQuery. And one of your members does not use jQuery, instead they use JavaScript because he knows it. When you understand this and then speak to the member personally and then speak to the Project Head and ask for required training for this member.
If something happens in one project, that does not mean the same process must be implemented in your project.
For example, you, your team and PO are locally working in the named Z-project. And another globally team X-project works on it. Both projects are based on Scrum-Agile. X project works on VDI. They (the X project) is not allowed to deploy on the staging environment and not in the production environment. The separate team is handled somewhere in this planet.
For your project (the Z project), there is no VDI, everything is done locally. When times come for staging, your team does not allow IT recommendations.
As a scrum master, what will you do? I recommend you transform your team impediments. And if nothing happens, do not wait for it to happen J. Add 1-2 days to your sprint.
Sprint goes well
Do not be proud. Remember it's a team effort. I would include all people, the PO, ST, HR, Training, Head of Project, Delivery Head, Users and QA.
Sprint goes not well
Do not feel bad. No single person is responsible for scrap. It is easy to blame others. Remember, It's team collaboration. So I urge beginning of any project/sprint or introduce a new member in your team, must apply “Learn from mistakes” and DRY.
Appraisal Performance
Scrum-Agile never taught you about this. In general HR is based on points. Here Agile works on a team, not individual points. I recommend that the project head reads the retrospective meeting points and discusses them with the individual and it is good to involve the scrum master too.
Remember Scrum Master is 24 hrs profiles
Good luck Scrum Master