Intent and Impact - Speaking and Listening (Inspiration from Ed Batista)

1. Any speaker (Agile Coach for example) trying to influence a listener has an underlying frame of reference, which is a part of the larger belief system of the speaker.
2.  The speaker has an "Intent" and will expect an "Impact". The speaker / evangelist, Coach needs to be aware of this intent as well as the Impact he's expecting from the listener. 
3. The listener will likewise have his own frame of reference within his belief system. Surrounding all this is a "Halo" or a Context / World View supported by a Shell of defence and impulse. Anytime an external "threat" or challenge touches this belief system, there is a reaction.
4. The speaker must be aware that people cannot simply change or modify their belief system based on logic or entreaties to conscience. 
5. The coach must therefore be able to "create an environment" where the existing belief system may grow to encompass a Delta, and outgrow the present limitations / inadequacies of thought to adopt or at least be open towards an alternative view, thereby allowing a mindset shift. 
6. And this is what a coach tries to achieve.

The Agile Coaching Role (AgileVelocity.com)

Remove Counsellor. There is no place for Counselling in the Agile Coaching toolkit. Counselling can be replaced by "Leadership Coaching". "We talk about the future, but don't dive into Therapy to resolve the past". (Niall McShane).

Key Agile Success Factors (Mitch Lacey)

Key Agile success factors:

1. Demand technical excellence: make XP practices mandatory. Neglecting these is one of the reasons why teams are not able to produce shippable code at end of sprints.
1. Sustainable pace
2. Collective code ownership
3. Pair programming
4. Test driven development
5. Continuous integration
6. Coding standards
7. Refactoring
2. Promote individual change and lead organisational change
1. Individual response to change is not enough
2. Organisation should also be able to respond to change. Institutional transformation is essential. 
3. Make sure management is educated, trained, on board and participating in agile/ scrum implementation
3. Organise knowledge and improve learning
4. Maximise value creation across the entire process

Lean books

• Lean Software Development Mary Poppendieck , Tom Poppendieck
• The Lean Enterprise (Jez Humble , Barry O'Reilly , Joanne Molesky)
• Leankit flow metrics, and slides here Lean-Metrics-Slides
• Lean Mindset by Mary Poppendieck
• Principles of Product Development Flow by Donald G Reinertsen
• Lean UX 2e by Josh Seiden
• Lean Startup by Eric-Ries
• Personal Kanban by Jim Benson
• Lean from the Trenches by Henrik-Kniberg

Things needing long lead times

1. Firewall burning
2. Setting up BAC alarming
3. Security
4. Vulnerability testing

Obsession with customer delight, and obsession with early and frequent delivery of value

The core of Agile can be summed up or seen as two views complementing each other -- obsession with customer & customer delight, and obsession with early and frequent delivery of value. Everything else, even the last 2 that Stephen Denning proposes (Law of Network and Law of small team are mere enablers to these two) are very critical but in my view enablers.

Starting Agile Journey

1. Start without calling yourself Agile.
2. Don't buy into standard stuff practised elsewhere and adopting in your workplace -- Spotify, Netflix, etc. have a context; Simply monkeying them in your organisation won't make you agile.
3. Grow your Agile organically.
4. Understand the context of your organisation, the whys and wherefores and why exactly you want to go Agile.
5. Implement a holistic agile framework --
1. Make your entire organisation agile
2. Consciously and diligently remove organisational impediments to agility
3. Restructure your teams -- self organising, self sufficient teams, fix procurement, fix operations teams, fix support teams, etc.
4. Fix your funding model
5. Fix your procurement
6. Fix your portfolio management; make it lean
7. Define agile framework pertinent to your org.
8. Grow home capability; if you must hire, hire people including agile ones in permanent roles.
9. Kick out consultants, you don't need them. 
10. Coaches are good, however ensure you have only very senior folks who have implemented it in other organisations. Get them into the organisation fold instead of contracting. 
11. Avoid remote work for Agile coaching. It won't work.
12. Likewise as far as possible avoid remote work even for day to day Agile.
13. Remove the stupid concept of hot desks. It isn't working anymore, and for Agile it definitely doesn't. Instead have a dedicated room / space for the teams. 
14. Reduce vendor dependency. Bring down the vendor count.
15. Don't allow HR to lead the Agile transformation. 
16. 
    

Sprint goal is list of US picked up for sprint

Antipattern

Team instead of creating an objective statement as sprint goal, decides to use the list of user stories as Sprint Goal.

Solution

• Avoid reasoning -- this is a best practice, is in the scrum guide, etc.
• Ask power questions
• What is the purpose of this specific iteration in relation to the product?
• Why do we have this Sprint?

PO Characteristics

OKR -- Objectives and Key Results (portal.netobjectives.com)

SM Mindmap

Tuckman's Stages and Team Conflict... - Researchgate

Contribute to Team's Welfare...

Remuneration and perks motivate upto a certain point. Beyond that, we need to tap into an employee's intrinsic motivation. Intrinsic motivation comprises -- Autonomy, Mastery and Purpose. [Daniel Pink]

SM 360 Degree

Approach to teams

Whole Team Approach

Whole team approach means everybody in the team is responsible for quality and success of the product. It is unlike the previously held view that quality can be a outside in thing (inspected and fixed - software testing), and can be injected. Quality is in-built into the product, and it is the team as a whole responsible for it. Success likewise cannot be driven by a project manager or another outside (of the team) role. It is for the team to organize, collaborate and succeed. 

Approach to Teams - another way to look at it

1. Team Formation
2. Training
1. Overview
2. PO Training
3. SM / Team Training
4. Gamification
5. Estimation
6. XP Practices (Pair / Mob Programming, Refactoring, TDD, etc.)
3. Skill Gap Analysis
4. Develop T, M Skills
5. Trainings - internal external as required
6. Inspect & Adapt

Overcoming Agile Challenges

• 
  

DoD Chinese Menu

Courtesy - Dmitriy Blinov

Telstra Role - Mindmap

Funding in Agile

DataOps Cookbook

Link to DataOps Cookbook

https://www.datakitchen.io/content/DataKitchen_dataops_cookbook.pdf

Why It Makes no Sense to Have an Agile Project Manager?

Source: vitalitychicago.com

• Intermediary: between the management / customers and the team. In Agile this is not required.
• Resource Coordinator: in traditional projects, lots of teams onboard and offboard, and there is a need for someone to keep track off, and coordinate these activities. In Agile we have a dedicated and self-organizing team, therefore there is no need for a resource coordinator.
• Hierarchy / Smart one - The project manager speaks on behalf of the team, directs the team, commands the team whether or not there is a direct line of reporting to the project manager. 
• Document producer - scope of documentation is exceptionally high in traditional projects, and much of it led by the project manager. 
• 
  

Daily Standup - no need to stick to 3 question format -- Courtesty Sanjay Kumar on LinkedIn

• No need to religiously stick to 3 question, 15 min format. 
• Healthy interaction is more important than above.
• As a team coach, check for these signs / dynamics within the team
• Are people in the team tuned in to the meeting?
• Is there energy within the team?
• When sharing updates, are people looking at one particular person or addressing the entire team?
• Did the updates indicate (tone) a sense of urgency?
• Did members pay attention to work items than their own?
• Are members asking each others questions?
• Are members offering help to each other?
• Are there lighter moments when people smiled and laughed?
• Did the meeting end on a positive note?

7 Pitfalls to avoid during organizational transformation - Tarang Baxi and Anupam Kundu [Thoughtworks}

I would like to add (These are views based on my experience):

• Not having a Change Strategy: Yes, it may seem strange, but many times, changes are implemented without a strategy in place. Orgs may have a Why, an organizational goal perhaps, but not a strategy for How they are going to go about it. This results in parachuting a bunch of consultants / coaches, waiting for miracles to happen, and dip checking every now and then to craft metrics around these "miracles". 
• Big bang change: Planting seeds  / catalysts of changes is one way to ensure the practices inspire others to create an environment of pull. Many times, either due to commitment to market, or for another reason, companies end up "creating work" for the engaged consultants / coaches instead of a judicious, methodical and carefully planned approach to chose the initiatives.
•  Unwilling / ignoring / hoping to clear roadblocks / blockers to organizational change. During organizational transformation, as and when the organizational blockers keep surfacing, it is critical to clear them. If not, their presence