Birth of a Service: Technical Agile Coaching

Over the last several years, agile software development methodologies, in their various forms, have slowly but steadily overtaken more traditional, waterfall processes. Experience has proven time and again that successful transitions to agile have been bolstered by management support, and in many cases, by bringing in agile coaches to guide teams as they change the way they work and collaborate. Teams who learn from coaches as they work tend to work more effectively because they understand not just the hows of agile (the processes, ceremonies, etc.), but the whys – the fundamental problems inherent in software projects, and the specific ways agile addresses these problems.

While many teams have become proficient in the people-centric aspects of agile, we have found through conversations with many clients that the technology-centric aspects of agile are often given too little attention early on during a team’s transition to agile. Things like test-driven development (TDD), continuous integration and deployment, collective code ownership and team “playground rules” for making code contributions, managing change sets, and ensuring consistent build health, are often not part of initial agile transformation or coaching initiatives. These teams very quickly feel the increased demands of an iterative and incremental process (need for frequent regression testing, well-honed and repeatable deployment processes, etc.), and don’t always have the tools and expertise to deal with those demands effectively.

The story we have heard has been so frequent and consistent, in fact, that we realized that the time had come for a different kind of agile coach. A technical coach. Someone who writes software for a living, and who knows what it’s like to work on a high-caliber, all-pistons-firing agile team. A person for whom TDD has become second nature, and who knows all the IDE shortcuts that make quick work of things like test-first development and refactoring. Someone who has checked in bad code at 4:30 on a Friday afternoon, incurred the wrath of his teammates, and missed happy hour getting the build back to a happy place.

So, we gave this some thought. How would we structure a technical agile coaching engagement? What specific areas of learning would we focus on? How would we go about coaching people who have hands on keyboards 6 or more hours a day? How would we help people learn without placing undue drag on productivity in the short term? What kind of individuals would make great technical coaches?

We thought it over. We talked about it. We thought some more. And we came up with our Technical Agile Coaching service offering. The highlights, in a nutshell, are:

• • Subject areas: In order to be included as an area of learning in this engagement, a topic would have to be of direct benefit to a software developer. With that constraint in place, we identified a surprisingly long list of subjects:
    • TDD, including test-first mechanics and the art of writing testable code
    • Behavior-driven development, for teams interested in it
    • Continuous integration best practices (including personal workflows and good developer habits)
    • Continuous deployment – the art of creating simple, repeatable processes for deploying code
    • “Playground Rules” for development teams, including:
      • What collective code ownership really means (or, “No, that’s not your facade class, it’s our facade class.”).
      • Things to do before you check code into the development branch
      • What to do when the build breaks
      • What not to do when the build breaks
      • Micro-prioritization of team activities (e.g. bug fixes over new features, etc.)
    • IDE tips and tricks to make TDD and refactoring faster and less error-prone

• • Execution: We knew that in order for this style of coaching to be of interest to our customers, it would need to share certain characteristics of more traditional agile coaching. In particular, the coaching would take place during normal, day-to-day project activity, and would place minimal drag on the team. To that end, we decided on the following key tenets of our service:
    • Most learning would occur in one-on-one sessions that take the form of pair programming. These sessions would allow our coaches to get a feel for the current proficiency level of the team, and have a chance for high-impact knowledge transfer, in the many teachable moments that occur while in the throes of writing software.
    • Group learning, as needed, will occur in short lunch-and-learn sessions, not lengthy classroom presentations. By limiting the duration of these sessions, we keep the team fresh and maximize information retention. And by having the sessions during lunch, we minimize  – or fully avoid – team downtime.

• Personnel: The best subject matter, training materials, and execution style won’t matter unless coaching is delivered by someone who is effective in this sort of role. As we defined this service offering, many attributes of the “ideal technical coach” came to the surface:
  • Expertise. A successful coach must have hundreds, if not thousands of hours working on agile teams and using the practices and tools we’d be teaching.
  • Team-Oriented. There are many superb, insanely productive software developers who do awe-inspiring work while hiding out in a cubicle. But most of them wouldn’t make an effective coach. Good coaches are special people. They derive personal satisfaction from seeing others improve, and knowing that they had a hand in that improvement.
  • Disciplined and Methodical. One of the least-well-understood aspects of agile is that it actually requires more discipline, when done properly, than did more traditional waterfall processes. TDD is nothing if not methodical, and requires a great deal of discipline to do properly. And if not done properly, risk enters the project in the form of low code coverage. So technical coaches need to be willing to not only share their knowledge, but to be a champion of the cause. To help the team understand the importance of test coverage, and coding standards, and of taking steps to ensure that a code submission will not break the team build.

Once we had really thought about what it would take to offer a successful technical coaching service, we were, frankly, a bit daunted. It would take a lot of planning. Development of training materials. Careful selection of consultants who are ideally suited for this type of engagement. Training and orientation of those consultants.

But, we decided, it’s worth the effort. Our clients clearly have a need for this sort of coaching, and our mission is to provide game-changing solutions to our clients’ problems. We knew that this was something we could do, and something that could have a huge impact on the productivity and job satisfaction of our clients’ development teams. And, from a more selfish point of view, it’s the sort of thing that, when done well, gives us great pride in our work. We all like the way that feels.

So, despite the challenges ahead of us, we didn’t back down. We’ve planned curriculum. We’ve designed lunch-and-learn sessions. We’ve oriented our coaches. And we’re finally ready. We are proud to now offer Technical Agile Coaching to our customers.

You're on a roll! Try these next:

How to Make Genuine Connections While Boosting Your Agile Skills