Why Does an Agile Coach Need to Know a Specific Programming Language?

I must be in quite the mood today. I am disagreeing with just about everything I see online. I saw a tweet today for an opening for an agile coach who needed to have C++ in his or her background. Why???

Is the coach going to be developing? I hope not. Testing? I hope not? Let's see. The hiring strategy for an agile coach is that you need someone with great problem solving skills, skills learning your technology and product, the adaptability to fit into your group and the cultural fit to fit with your people.

In a job analysis, I would expect someone with substantial initiative and flexibility. Someone who could take technical leadership, but not always make it look like he or she was the leader. Someone responsible and independent, but responsible to the team. Someone who can work with a team of 3-7 and work individually. Someone who can help the team see what they are doing, without offending the team members.

I would expect the coach to sit with the team members to help them split stories, to help them see how to automate the system tests. I would expect the coach to help the team members learn how to create acceptance criteria. And, if the team members don't already have unit tests, to help the team members write unit tests.

I would expect a coach to know some programming language because otherwise it's too difficult to speak the language of the developers and some of the questions are too code-centric. I would also expect the coach to understand the way testers think about testing and how to automate tests and when not to automate tests, because otherwise it's too difficult to speak the language of the testers. I would also expect the coach to be fluent in potential metrics such as burnup charts, burndown charts and cumulative flow diagrams, and when to use regular agile boards and when to use kanban boards to show bottlenecks better.

I am suspicious when a job opening wants an agile coach to know a specific programming language that they don't want an agile coach. I suspect they want an extra pair of hands. That's okay. Well, it's not, but if the coach knows what he or she is getting into, maybe it's okay. That position is not an agile coach. It's a something else.

Maybe there's a darn good reason for this position to ask for a specific programming language. I'm dubious. Seems like an overconstrained job description to me. But what do I know? I'm just an agile management coach (among other things).

8 Replies to “Why Does an Agile Coach Need to Know a Specific Programming Language?”

  1. Johanna – in many cases I agree with you however alot of my work is to coach team members on technical skills i.e. TDD, Unit Testing, OOP, etc. In those cases my understanding of C/C++/C#/Java/… is critical.

    However I do agree that in general an Agile Coach doesn’t need to be uber-technical.

    Mark Levison
    Agile Pain Relief Consulting

  2. I guess it depends what you mean by a ‘coach’. My first two XP teams had coaches who were programmers. IMO they would not have earned the respect of the programmers on the team, nor been able to help the team learn practices such as TDD and refactoring, if they had not been experienced programmers.

    If the team needs to learn technical practices, they’d better have a coach who can sit down and work alongside them to help them learn.

    For a more general “agile coach”, helping the team to change its culture and successfully adopt agile values and principles (which is much harder IMO!), I agree with what you say in your post. The coach needs to have credibility, but this doesn’t mean being an expert Java programmer or whatever. It’s important that the coach makes sure the team has the technical support, training, and time to learn that it needs, though.

  3. The only reason I can think of that an Agile Coach needs to know a specific language is because Unit Testing and Refactoring techniques can be very language/framework-centric, even if the basis are the same. But unless Agile is being adopted at a very local scale (ie, single project as a pilot), it is better to have different people coach the process and the technical practices (like Refactoring and Unit Test). In other words, I think it is better to have a coach for the Strategy and another coach for the Tactics if Agile is being adopted company-wide.

  4. As an Agile Coach with a technical focus, I help programmers learn TDD, Refactoring, and evolutionary design skills in their programming language, in addition to non-technical team skills like agile iteration planning/release planning, and so on.

    C and C++ have many features that get in the way of evolutionary design and TDD, and C/C++ has few refactoring tools. It takes expertise in C/C++ to teach mocking/faking and refactoring in C/C++.

    C# has great tools for TDD and Refactoring but many of my clients are unaware that those tools exist.

    I have coached people learning TDD and refactoring in languages where I am not an expert. In those cases I had to rely on their expertise in that language to avoid traps specific to that language. The concepts of TDD and Refactoring are not language-specific, but their application can be very language-specific.

    Sometimes I am brought into coaching a team where expertise in their chosen programming language is in short supply. So it’s not just “agile” skills they need to learn. You can’t always rely on the client to make up for your lack of language-expertise.

  5. Unless I had a very strong technical team already, I’d want my agile coach to have technical knowledge. It’s not like we are going to hire a coding coach AND an agile coach (more power to you if you are), but that’s gotta be rare.

    Like Mark said, a lot of agile coaches do cover topics like TDD, continuous integration, refactoring, etc. While not exactly the same thing, these are important things to do when doing agile (arguably anytime, but especially when doing agile). After all, if you don’t have a comprehensive test suite and try to do releases every week, you’ll probably just end up tripping all over yourself.

    Another example: when you try to explain to someone to do work in functional slices (as opposed to doing a full database layer, full GUI layer, etc). I’ve seen developers who’ve never done this before push back on this, claiming they can’t do it that way, mostly because they’ve never seen it done and don’t know how. But what can a nontechnical person really say or do to help in that case? Nothing.

    Actually this comes up a lot, where the developer comes up with technical arguments against agile practices, because they haven’t seen it done before. Testing is a big part of it, especially GUI testing. Another example is speeding up the deployment process. It’s not enough to tell the programmer “It can be done, go Google it!”, you’ve got to help them accomplish it.

    Quite frankly, imagining an agile coach who can’t program trying to dictate to a programming team is a terrifying thought. Maybe you just mean that the agile coach should be technical, but doesn’t need to proficient in their specific technologies, but even that is shady. Sometimes you need to get in there and get your hands dirty, and show how it’s done, not just talk about it.

  6. The joy of being a generalizing specialist, or whatever term Scott Ambler uses. On an Agile team, you will be best at one thing but also know how to do everything…. that’s tough to do, and finding such people sounds difficult. Have other commenters found that to be a problem on Agile projects?

  7. Agile Coach just a term for people who coaches in Agile, and since Agile is kind of epic, there are many themes which requires different technical skills. While hiring an Agile Coach dedicating in engineering practice especially in Unit Test or TDD, I would suggest programming language as essential. But for a Coach more focus on product development management or organizational transformation, programming languages may not be that critical, but still it’s a plus…

  8. So do you guys see a coach being a team member or being outside a team?

    And in an agile context aren’t you there to teach ‘inspect and adapt’ rather than specific methods?

    It’s the mindset that needs to change. The methods ate commodities

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.