User:KSmith (WMF)/Technical Agile Coach

Overview

A Technical Agile Coach (TAC) combines technical software development experience with agile coaching skills. In addition to normal agile coaching duties, a TAC can provide guidance in areas like code review, refactoring, and automated testing. A TAC might help mentor a developer to increase their debugging skills, or could help a development team make better decisions about how they might take on or pay down technical debt.

A TAC would typically engage with individuals, teams or other groups for some specified time period. That could be a one-off conversation or presentation, or two weeks of intensive pairing or otherwise working closely. An engagement could also be a small recurring time commitment over a longer period of time, such as a weekly hour-long consultation over several months. But there would be regular checks to make sure an ongoing engagement is still providing high value.

A TAC will use various coaching styles as appropriate. Sometimes they might take on more of an expert/teacher role, while other times they might simply be a sounding board. In some engagements, the TAC might feel some responsibility for their client achieving some goal, but more often the TAC would only be responsible for helping them increase their understanding. At all times, the TAC must remain humble, recognizing the truth that software development is complex, and there are always new things to learn.

This TAC role is an informal label, not an official WMF job title. It is part of a broader idea that some agile coaches at the foundation might specialize in different areas. The first example was the creation of a Senior Agile Coach: Organizational Collaboration title in 2016.

Examples of potential activities

Code review

• Offer to participate in pairing sessions doing code review
• Brownbags/coaching on how individuals can CR most effectively
• Help develop conventions around the larger CR process

Automated testing

• Brownbags/workshops/coaching on TDD
• Offer to participate in pairing sessions doing TDD
• Brownbags/coaching on unit vs. acceptance vs. integration vs. browser testing

Refactoring

• Brownbags/coaching on refactoring techniques
• Offer to participate in pairing sessions doing refactoring
• Coaching devs on how to "sell" refactoring to POs
• Coaching POs on the value (and risks) of refactoring

Code smells and style

• Coaching on code smells
• Evangelize for Lint-like tools; McCabe complexity
• Coach teams on integrating code metrics into their workflow
• Coaching on treating warnings as errors
• Coaching on treating log noise as errors
• Coaching on reducing the need for comments through good naming and structure

Working incrementally

• Coach teams/POs on how to slice stories vertically/incrementally
• Coach devs on how to slice tasks vertically
• Brownbag/coaching on prototype vs. spike vs. MVP
• Coach devs on small/micro commits (relates to TDD and refactoring)
• Coach devs on simplicity/YAGNI (related to TDD)
• Brownbag/coaching on continuous design

Software craftsmanship

• Brownbag on the concept of software craftsmanship
• "How you can become an effective mentor"
• Coaching on Pair programming (or pair debugging)
• Offer to sit in as a pair so people can experience pair programming
• Coaching on "Mentoring via Code review"
• Coaching on other ways to distribute skills throughout a team

Open source/FLOSS

• TBD

Hackathons

• Help connect people with projects
• Coach hacking teams to focus on achievable goals
• Help teams put together effective showcase presentations

Frequently asked questions

How is a TAC different from an agile coach?

Unlike a TAC, agile coaches usually won't have extensive experience as a software developer. So they tend to engage with teams through process and dealing with interpersonal dynamics. A TAC can get more technical, so for example they might recommend specific refactoring practices, or describe the pros and cons of different automated testing frameworks.

A team that is already working closely with an agile coach might want to bring a TAC in from time to time, to help them work through a specific issue, or to build team capacity in a certain technical area.

Don't senior engineers and tech leads and engineering managers already do this work?

In some cases, yes. However, even this work seems important enough to be worth some additional attention.

Both engineering managers and tech leads tend to be very busy. They also generally focus on one or a few teams, so are less likely to be in a position to cross-pollinate effective practices from other teams at the foundation. Sometimes an external and/or neutral perspective can help a team get unstuck.

Many tech leads focus on the technology, and don't put as much emphasis on mentoring and guiding other developers. Tech leads are individual contributors with their own deadlines, so might not find the time to build team capacity through brownbags or pairing sessions.

Engineering managers are responsible for the professional development of coders, but might not dive into specific technical details. Managers are also in a position of authority, and some conversations might be more comfortable among peers.

Does a TAC need to be experienced with MediaWiki development?

Not necessarily. It would make some things easier, of course. But many/most patterns apply across different languages, frameworks, and projects. Performing an "extract method" refactoring is a universal thing, even if the language or programming environment makes it easier or harder to do in some specific context. Test-Driven Development (TDD) isn't tied to a specific technology.