Kane Mar

With the increased interest in Agile software development, Agile coaching has become more and more popular. Companies are introducing Agile coaches to their teams firstly as contractors and then as permanent staff. They often do this without fully considering the role of the Agile coach within the organisation, or of a career path for the coach.

To make the situation even more difficult, the attributes that are appropriate for an Agile coach are quite different than those for traditional project management. For example, rather than being able to track individuals and tasks, the Agile coach needs to know how to motivate the team into forming a self organizing group.

This article discusses what some of those attributes are, and presents a model for maturing Agile coaches.

Introduction
What previously worked in an environment modeled on Taylorism [1], is no longer appropriate in an environment that is continually changing. Agile projects require different skills and these should be recognized and rewarded differently. Specifically, a Taylorist view of the world rewards greater specialization of skills. This can be clearly seen with methodologies such as RUP which categorize people into specific roles such as Analysts, Developers, Architects etc.

In contrast an Agile environment favours individuals who work together as a team. It favours group decision making and, by implication, those individuals who have the ability to facilitate and abide by the group decision. Agile projects are at a disadvantage with someone who does not directly contribute to the overall success of the project in some way.

In an Agile model, the project manager that only wants to update the project plan and report to manager senior management is overhead for the team. Similarly, the architect that never wants to mentor staff but only wants to draw UML diagrams and dictate a solution to the team is detrimental to overall progress.

Desirable Characteristics of Agile Teams
So, exactly what attributes of team members are advantageous in an agile environment? What charateristics should be rewarded?

• Team work. Agile environment are all about team work. Everthing is done as a team and agile projects are designed to ensure maximum communication between team members. Naturally a good measure of how well someone works in a team would be the opinion of their fellow team mates. The highest compliment that a team member can bestow upon you is to clearly and publicly state that they would be willing to work with you again in the future.
• Breadth of knowledge in addition to depth of knowledge. It’s becomming more and more important for the project team to have a broad understanding of the business and entire software development process in addition to a detailed understanding of their domain of expertise. For example, it’s is no longer sufficient to simply understand how to write good code without also understanding how to test code [3] and Test Driven Development [4]. The best team members understand the complete chain from the needs of the business through to deploying a solution.
• Experience with an Agile process. Agile software development is a conceptual change from traditional project management. The Agile project manager has to learn new skills that are simply never encouraged with traditional software development. In adddition, the selection of process practices and/or engineering practices that are followed by the project team have to be chosen carefully. For example, should the team have fixed duration iterations [yes], should the team estimate with Story Points [maybe], should the team implement Continuous Integration [yes], [5]?

  Some of these practices (but not all) are dependant on each other, and to drop one practice without knowing the implications and consequences can be very detrimental to the team. Consider for example the pratice of refactoring. Doing refactoring without Continuous Integration or Test Driven Development is very risky. An experienced Agile coach, mentor or project manager will understand which practices are dependant on each other and if a practice can be safely ignored by the project team.

  I often find that it takes several projects for the coach to start becoming aware of how the role changes in an agile environment. And it may take as long as a year for a coach to be able to work fully independantly.

• Agile Certification especially ScrumMaster training. There is mixed feelings in the Agile community regarding Ken Schwaber’s Certified Scrum Master (CSM) training courses [2]. I feel that it’s valid to included it here for two reasons:

  1. Ken saw a need in the market place and he did something about it. Companies have been requesting some form of certification for a long time [for at least 5 years, as far as I'm aware]. Rather than try to codify a unified Agile approach, which would have been difficult if not impossible, Ken opted for the simpler solution of certifying his flavour of Agile (ie Scrum). Other companies that are still discussing a unified approach have not made any progress.

  2. Ken’s CSM training continues to gain in popularity over other certification processes. Success is very difficult to argue with!

Summary
I’ve discussed a model for Agile Coaching and highlighted some of the attributes that I consider to be most important. The full model can be found here.

Of course, every situation is unique and the basic model will need to be refined for your specific environment. I look forward to your feedback and comments.

References
[1] “Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency”, by Tom DeMarco
[2] Message #9959 in the Yahoo Scrum Development group.
[3] http://www.testinglessons.com/
[4] “Test Driven Development”, by Kent Beck.
[5] Martin Fowlers web page on Continuous Integration.