The Winter 2009 issue of Methods & Tools contains an interesting article from Rachel Davies about Agile Coaching Tips. She shares her experience that is also available in the excellent book that she wrote with Liz Sedley. When I reviewed her book this summer, I started thinking about the coaching role that external people are now assuming versus the traditional consultant position. On the same question I saw a recent blog post discussing the utility of agile coaches. The author said that you should accept advice only from people that had achieved themselves something big, citing personalities like John Carmack or Linus Torvalds.
Software consultants are people hired on a temporary base mostly for what they are able to achieve. They will develop part of a software system or manage a project (I don’t want to talk here about consultants that are just hired to produce PowerPoint presentations). They will also provide some knowledge transfer to internal employees that are new to a specific technology. On the other side, the goal of agile coaching is more often to improve behavioral skills. Sport teams provide the first example of a coaching role that could come to your mind. There are however some differences. The agile coach aims at producing a self-organizing team and he acts only when issues occur to suggest solutions. The sport coach has authority over teams. He directs players’ roles and activities, although you should not minimize the roles of players as leaders especially in professional teams. The situation of coach of individual champions is also different, as the athlete usually chooses them… and fires them also.
The current agile adoption trend favors coaching and the economic crisis could be a catalyst to change work practices. However, I have few illusions that most of the corporations’ managers are truly embracing agile values. Getting up in higher management is still predominantly a power struggle, with more political consideration than the goal to empower employees. Many managers’ main objective is to justify their job (did you ever wonder why there are so many meetings?) and creating a self-organizing team is not intuitively something that helps to achieve this goal. Upper managers mostly don’t care about the type of software development process. They want working software applications delivered quickly and for a minimum cost. They will pay for Agile practices as long as they think that it could provide what they want and “cure” the problems that they attribute to their current software development model. They did the same thing before with Structured Analysis, Information Engineering, RAD, Object Orientation, CMM, ISO 9000 or UML – RUP (you can add your own silver bullet approach in this list). The name of “coach” or “consultant” can be used for external help, but ultimately companies will pay for people that deliver short term results and improving developers working condition is not always included in the list of valuable results. This is sad for Agile and developers as it could be one of the few approaches that value “Individuals and interactions over processes and tools“.
Interesting to hear your thoughts on how the economic crisis may be pushing agile adoption but also short-term thinking.
Also please can you fix minor typo in spelling of my name above it’s Davies not Davie.
thanks,
Rachel
Sorry for the typo Rachel. As far as short-term thinking is concerned, I think it is sadly a constant in many organizations. I don’t mean that everything should be long-term, but to have a better balance between the two horizons.
These observations sad, but true. Don’t forget that many of the people in organisations reach high management positions precisely because they’ve adopted short-term solutions to immediate problems. By the time the consequences of their actions are apparent, they’ve often moved – upwards in the organisations, or to other companies.