Why is there resistance to change - mindmap

Courtesy - entrepreneurshipinabox.com, Paycor.com

My Experiences

============

1. Loss of individual power - Ex PMs now turned into SMs disliked the loss of exercising power in an Agile team. 
2. Loss or increase of power at org level -- Operations team feared their existence as well as loss of being able to exercise power.
3. Economic factors -- with reduced manpower, projects / products, and reduced budget, people feared an impact on their perks, forced retirement packages, redundancy packages (if not salaries per se).
4. Loss of image, prestige, etc.: For program managers, project managers that once had a handle to hire & fire, and in fact be in command about how certain things need to be within the organisation, now found themselves at the mercy of technical teams / organisational change agents, or those designing the organisational teams.
5. Resource reallocation, realignment, etc.: During early days of org design, squad, chapter, guild formations, there was lack of clarity of specific roles, how existing roles will move over to the new roles, what happens if there is no direct mapping of an existing role with new one, and especially what will be the new R&R (the mandates provided a generic outline of duties), as also how their previous R&R aligned to their contracts with the organisation would change and accommodate their aspirations. In some cases there appeared to be a too steep learning curve for some veterans.
6. Impact to personal plans: 
7. 
   

Handling bugs in Agile - Bradley Bug Chart

Should be this.

1. Is it a bug? If yes, proceed and fix it first based on priority, else get it into the product backlog.
2. If it is a bug, can it be deferred to next sprint? If no, proceed below, else move to next sprint. If it is a bug and needs to be addressed in the current sprint, then proceed below.
3. Can the bug be fixed within 2 hours? If yes, fix it and forget rest.
4. If no, then get it into the current sprint backlog and remove another item of approx size.

Mulesoft - Eric Stahl on Youtube

Shamrock Mapping - Mike Coon

1. You may use the Shamrock mapping for retros, or to elaborate on an Element's Dynamics along Autonomy and Mastery.
2. This is probably derived from Daniel Pink's Drive -- Autonomy, Mastery and Purpose. 
3. Place an element (as in this case "Compile") along Autonomy - Y Axis, and Mastery - X Axis. 
4. Then, identify the "accentuators" and "Drags" on both axis. 
5. Lift are those that allow the element to move to greater autonomy, whereas weight brings it down. 
6. Likewise, Thrust propels the element along Mastery, while Drag hold it back.

Changing Organisational Culture - Michael Sahota

http://agilitrix.com/2018/07/change-organizational-culture/

Wardley Maps

Wardley maps (by Simon Wardley) have been in for a while. I have attended a session too by Neil Killick in Melbourne (shall upload the slides / snapshots).

https://blog.gardeviance.org/2015/02/an-introduction-to-wardley-value-chain.html

DEEP Agile

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.

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)