Written by Pan-Wei Ng and Mark Magee

If software development is about wiring code, then coaching is about re-wiring the neurons in each practitioners head and re-wiring their relationships. Yes, coaching is about changing people. You cannot expect a one-size fit all solution, so you need to adapt the recommended practices and approach.  This paper discusses how to work with people, how to manage the coaching progress and setting objectives and expectations. This paper also talks about coaching not being just about helping the team learn, but also for you to learn and grow. You have to be agile to coach agile.

Organizations eager to solve the problems they see in their projects or processes often decide to adopt Scrum in the belief that it will immediate solve all those problems. Although Scrum can and often does resolve some problems immediately, it also has the potential to expose or exacerbate other existing problems and can even appear to create a few problems of its own.

In some cases, this can be seen to be a “failure” of Scrum, even when implemented by an organization that was initially enthusiastic and determined. This perceived failure can cost the organization considerable time and money if the Scrum team continues along the same path they are on, despite the unresolved problems. These costs, as well as frustrations and even pressures from inside or outside the Scrum team can cause Scrum to be abandoned without ever demonstrating its full potential.

Written by Alan Atlas, CST, CSC, Agile Coach, Rally Software and Mark Kilby, CSM, Agile Coach, Rally Software

Coaching and training are indispensable to Agile transformations. This can be difficult for some organizations to accept.  Agile frameworks are simple to understand, but there are many nuances to handling the complexities involved in an Agile transformation.  While it is often helpful to tap into outside resources (books, websites, courses or consultants), the organization will need someone who understands the subtleties of Agile transformations and the context of the organization to make the transition as successful as possible.  We refer to this role as the “internal Agile coach” and we often encourage clients to identify one or more such individuals as the organization's need for Agile knowledge and understanding grows. Being an Agile coach requires a wide range of human qualities, skills and experience, and selecting one for the company should be done carefully.  In this article, we discuss when you need an Agile coach, what an Agile coach does, and a few tips on how you might create your own internal Agile coach.

“An agile coach is three parts go-giver[1] and one part go-getter”.

As a go-giver the agile coach focuses on putting others’ interests first and continually adding value by serving an individual’s, teams’ and organization’s needs and helping them effectively and pragmatically deal with both their day-to-day and long-term challenges.

An agile coach helps the individual, team and organization envision where they are going and the best way to get there; like depicted in Figure 1.

Agile consultants often take on the responsibility of helping an organization adopt Agile Methodologies.  This is a challenging task to say the least.  Introducing new ideas into an organization requires social intelligence, advanced communication skills, and persuasiveness, not to mention a sound grasp on Agile principles and practices.   In many large organizations, the Agile consultant must also contest the deeply embedded mentality of traditional waterfall.  The software industry changes constantly, but people's habits and minds aren't always amenable to change.

Let the Fun Begin!
As children, we learn through play. Because play is so much fun, it creates a virtuous circle where we play and learn. As adults, with the help of educational or “learning” games, the lucky ones among us find ourselves playing to learn once again. Judging by the popularity of learning games, we can still learn a lot through play. For some, it may even be the best way to learn.

What is the Purpose of Coaching?
In our work environments and personal lives we’re always looking to make clear, thoughtful choices, speak them clearly, and execute them in effective ways.  We want to optimize our time and energies to create valuable outcomes.  All this can happen spontaneously and without a plan, but with foresight to think and plan before taking actions, especially for larger goals, there’s a higher probability for getting quicker and more reliable results.

The modern world of systems-software product development and delivery presupposes we work faster and better, do more with less, change continuously, and invent new ways of working. The modern formula for work appears to be:

More Success + Greater Speed + Fewer Resources + Constant Uncertainty +

Increased Competition + Quicker Time to Market.

Mastering the “art” of agile and lean system-software product development and delivery requires you ask yourself, “Do I really understand the science/technical and the art/behavioral nuances and aspects associated with this undertaking?”

1. Tsunami Development
Moving to agile development (or doing anything new) is not easy. Beyond learning some of the technical stuff, the new terms like SCRUM, stories and so on, it is about changing mindsets. How do you change mindsets? How do you understand mindsets, and to do so quickly? I do this by drawing diagrams, and have project teams identify where they are and where they want to be. Of course, these diagrams should be easily understandable, and so that the project team’s response can be quick. You either win them over in 2 minutes, or you lose them completely. The diagrams should also be easily reproduced such as on a white board, so you are always ready.

By Dr. Myles Bogner & David Elfanbaum, Asynchrony Solutions

Figure 1 (Right) - The Domains of Agile Methodology and Enterprise Change Management

Introduction
Agile software development is designed to thrive within even the most dynamic business and technical environments. In fact, the name “Agile” was chosen because its founders viewed “adaptiveness and response to change” as the most essential concept of the methodology.^[1]

All Agile methodologies include integrated practices and processes that manage evolving requirements to efficiently develop a continuous stream of new software capabilities. However, what Agile does not address are changes related to enterprise support of the Agile process or tasks that fall outside the scope of the project work, including: