Value Stream

This is for my own reference:

1. You are able to tell all the product / services your unit / vertical produces / offers.
2. You are able to map the products / services back to the teams (A 1-1 mapping or multiple teams that deliver a particular product / service. Efficiency decreases / time to market increases if there are multiple teams mapped to a product / service).

Scrum Master Role & Responsibilities (Courtesy Roman Usov)

Use the following as a checklist when transitioning to a new team

Start by asking the Team -- "What do you expect from me?" (This is basically setting the expectations and ensuring both are on the same page)

Team

- Be the mirror

- Ask a lot of questions

- Observe (events,  relationships, processes, people, check team's profiles on social networks)

- Observe team dynamics during Scrum events

- Learn about team values, conventions and agreements

- Ask what I can help the team with (maybe, as an activity at a retro, what, why)

- Find small things to help the team with

- Suggest a couple of get-to-know activities for a retro ('get to know you' quiz, journey map, team canvas), learn about team expectations, find an opportunity to tell the team about how I view my role

- Go to lunches with the team

- Provide welcome treats

- Seek opportunities for one-on-ones (at coffee, at lunch)

- Have a trip to meet guys working from another office

- Learn about interactions and dependencies outside the team

- Learn about team's improvement backlog

- Notice deviations from the Scrum Guide

- Notice problems that can be helped with Scrum

- Ask questions about what I see, offer observations for issues and draw team's attention to them where appropriate, ask to ponder ideas

- Notice what team is struggling with, suggest observations, stories from experience

- Review available team artifacts and metrics

Processes & Tools

- Learn about team's development process

- Learn about CI and deployment process

- Learn about tools used by the team

Product

- Learn about product

- Review product backlog

- Learn about current PBR process

Organization, culture (what's important and why, how we do things here and why), environment

- Learn about mission, vision, strategy

- Learn about values, observe if they are really lived by

- Learn about structure, key components and interactions

- Notice problems that can be helped with Scrum

- Attend community of practice meetings

Stakeholders

- Learn about key stakeholders

- Find opportunities to meet with key stakeholders

- Learn about stakeholder needs and expectations

From Chandan Lal Patary
===================
- Enables the team to eliminate impediments
- Coaches team in scrum practices
- Protects team from external intervention
- Has continuous improvement mindset and practices it
- Is an outstanding facilitator
- Is a servant leader
- Has good influencing skill
- Knows the domain and technology
- Has substantial organisational skills
- Is an outstanding communicator
- Is an excellent conflict manager
- Capable of building self-organised team
- Has good collaboration skills
- Builds transparency into the team

Production defects, velocity and adaptation

1. Through estimation in Agile, we are not trying to predict. Predictability isn't the end goal of Agile. 
2. Predictability is helpful in knowing when a certain release will be shipped and to know how soon a team can deliver.
3. Don't stress too much on Predicting. Don't predict harder instead adapt better.
4. Instead of planning ahead, focus on adapting when dealing with unpredictability.

What to expect from an Agile Coach? (From DAD)

http://disciplinedagiledelivery.com/qualified-agile-coaches/

Here is what we’ve found to be the critical success factors for agile coaches:

1. They should have years of agile experience, not days of training.  If someone doesn’t have years of experience in something, and more importantly years of varied experience, then why they heck would you hire them as a coach?
2. They should have coaching skills and experience.  Being experienced in agile isn’t enough.  Apprenticing under another good agile coach is a great way to get coaching skill as is getting training in agile coaching (the Agile Coaching Institute is a start for this although the program at International Coaching Federation (ICF) is far more thorough).  The need for experience is a bit of a catch-22 of course – you need to already be an agile coach to be qualified to be an agile coach.  But, if someone has no previous coaching experience then at best I’d put them into a junior coaching role under the guidance of an experienced coach.  This provides them with the opportunity to gain the requisite experience and to prove themselves in practice.
3. They should have robust agile skills and knowledge.  Years of agile experience is a good start, but better yet is a range of experience at all aspects of the lifecycle in which they are coaching.  It’s reasonable to expect a delivery team coach to understand all aspects of agile solution delivery so that they can coach the entire team in the skills they need to succeed.  Furthermore, it’s reasonable to expect an Agile IT coach to have experience in the full agile IT lifecycle, including areas such as Enterprise Architecture, Data Management, Portfolio Management, and many others.
4. They should have experience in a similar context.  Ideally they should have skills in a similar context to what you currently face – someone who only has small team coaching experience will struggle to coach a large programme, someone who only has only coached in startup companies will struggle in a large financial institution, someone who has only coached co-located teams will struggle with globally distributed teams.  Context counts.

Purpose of Sprint

The whole purpose of a sprint is you are able to deliver some value end of it, if you are not able to release, what is the point even spriting? ( - Neil Killick)