Burnout

Infographic and content - Lindsay Braman.

The voice of burnout is not YOUR voice. Burnout will say you aren’t cut out for it, that you don’t enjoy it, that you aren’t good at it. Don’t make career decisions while you are burned out. Switch employers, cut down hours, get a side gig selling slotted spoons on eBay, do what you gotta do to equal out your stress and your support resources.

Burnout is:

• NOT a simple response to Stress
• NOT Weakness
• NOT incompatibility with field
• Burnout happens when we are exposed to more stress than we can cope with. 

Agile requires a "sustainable pace." You should be coming into work every day fully rested and able to do your best work. Burn out is very real, but if you see it, the org isn't Agile. If work is so stressful that you burn out even working "normal" hours, you're also not Agile. - Allen Holub

Use this link to check burnout of your team

http://www.uapd.com/wp-content/uploads/Maslach-Burnout-Inventory-MBI.pdf

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.