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)

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