4 ms·

What responsibilities does an "Agile Technical Coach" have and what did you do for the business? (I'm curious because in most of the industries I've worked in,

What responsibilities does an "Agile Technical Coach" have and what did you do for the business? (I'm curious because in most of the industries I've worked in, the teams have been extremely skeptical of Agile coaches/consultants)

DanielBMarkham 9y ago
in most of the industries I've worked in, the teams have been extremely skeptical of Agile coaches/consultants For good reason. I don't blame them. The way I see it, there are very few of us around, although tons of people advertise using this term. I'm the last of the general contractors when it comes to IT consulting. From where I sit, it looks like a vanishing breed. I'm a full-stack technical lead who has had tons of experience in different industries and technologies and ended up, somehow-or-another, training organizations in how to use teams. That's where the Agile comes in. The work is this huge mix of technical and organization levels. A recent contract had two weeks of executive/director-level work setting up a roadmap for change, followed by a "dog and pony" show with the usual slides and games, followed by a deep-dive with a team of leads where we set up the entire production and CI/CD/DevOps pipeline/stack and learned TDD/ATTD and the rest of it while writing code for an upcoming project. (This was hands-on technical work along the lines of "how to automate cloud deployment using AWS/Ansible", "Ping-pong pair programming in Java/Javascript/Angular", and "Architecting a build pipeline for a team, program, and org") I prefer the technical stuff, since so many coaches can't actually do the work (and I used to be a show-off). The fact that most coaches in many cases can't do the work sucks big time for the client. But it's not just technical. All of it is important. Unless you get the execs straightened out they'll screw up your org change without even meaning to. Unless somebody is running interference/coordinating with middle management nothing ever happens. And the place to start with the devs is with the leads/architects. Get them actually coding something. Oddly enough, there are a helluva lot of leads and architects out there that can't code. They need to get up to speed and to understand what success looks like. If you miss any of those levels, it's not going to work. So wether I want to or not, I end up working at all org levels, and the best title I've got for that is "Agile Technical Coach" I've been bugging Bob about doing some Clean Coder material on backlogs, since they seem to be the thing that crosses all org levels and they're constantly a mess. Bob keeps hammering on doing things right when I think it's much more important to focus on doing the right things before you worry about what kind of craftsman you are. I've even pitched him on a couple of ideas. Who knows? You might see something there from me in the future.
- Caveman_Coder 9y ago
  Thanks for the response. Sounds like your work is kind of an development/efficiency/automation/process-improvement SME that works with all levels of employee, from the devs to the CTO, which requires understanding of both IT systems/dev and business. I've seen co-workers with a similar set of responsibilities but they called themselves "Corporate Efficiency Analysts," with the better ones coming from tech backgrounds (sometimes having acquired an MBA after years of development), and the poorer ones only having "general business" experience.
  - DanielBMarkham 9y ago
    Yep. There are way too many Power Point Rangers and Six Sigma Astronauts in that bunch, however. It's tough finding a good label. The key here is that software is everything. It's not just an add-on to some orthogonal business model. Any more, software is the business. The tech skills are just as important as the rest of it. Most companies today are like a group of medieval princes whose job is to correspond with other princes -- but none of them can read or write. They kind of know what they want, but for whatever reason, they feel that it's beneath their dignity to actually make it happen. The way we treat development? It's as if we were to start hiring people to write our emails for us. And then complain at how correspondence is always so difficult. Sorry for the rant. Thanks for the chat!

DanielBMarkham 9y ago

in most of the industries I've worked in, the teams have been extremely skeptical of Agile coaches/consultants For good reason. I don't blame them. The way I see it, there are very few of us around, although tons of people advertise using this term. I'm the last of the general contractors when it comes to IT consulting. From where I sit, it looks like a vanishing breed. I'm a full-stack technical lead who has had tons of experience in different industries and technologies and ended up, somehow-or-another, training organizations in how to use teams. That's where the Agile comes in. The work is this huge mix of technical and organization levels. A recent contract had two weeks of executive/director-level work setting up a roadmap for change, followed by a "dog and pony" show with the usual slides and games, followed by a deep-dive with a team of leads where we set up the entire production and CI/CD/DevOps pipeline/stack and learned TDD/ATTD and the rest of it while writing code for an upcoming project. (This was hands-on technical work along the lines of "how to automate cloud deployment using AWS/Ansible", "Ping-pong pair programming in Java/Javascript/Angular", and "Architecting a build pipeline for a team, program, and org") I prefer the technical stuff, since so many coaches can't actually do the work (and I used to be a show-off). The fact that most coaches in many cases can't do the work sucks big time for the client. But it's not just technical. All of it is important. Unless you get the execs straightened out they'll screw up your org change without even meaning to. Unless somebody is running interference/coordinating with middle management nothing ever happens. And the place to start with the devs is with the leads/architects. Get them actually coding something. Oddly enough, there are a helluva lot of leads and architects out there that can't code. They need to get up to speed and to understand what success looks like. If you miss any of those levels, it's not going to work. So wether I want to or not, I end up working at all org levels, and the best title I've got for that is "Agile Technical Coach" I've been bugging Bob about doing some Clean Coder material on backlogs, since they seem to be the thing that crosses all org levels and they're constantly a mess. Bob keeps hammering on doing things right when I think it's much more important to focus on doing the right things before you worry about what kind of craftsman you are. I've even pitched him on a couple of ideas. Who knows? You might see something there from me in the future.

Caveman_Coder 9y ago
Thanks for the response. Sounds like your work is kind of an development/efficiency/automation/process-improvement SME that works with all levels of employee, from the devs to the CTO, which requires understanding of both IT systems/dev and business. I've seen co-workers with a similar set of responsibilities but they called themselves "Corporate Efficiency Analysts," with the better ones coming from tech backgrounds (sometimes having acquired an MBA after years of development), and the poorer ones only having "general business" experience.
- DanielBMarkham 9y ago
  Yep. There are way too many Power Point Rangers and Six Sigma Astronauts in that bunch, however. It's tough finding a good label. The key here is that software is everything. It's not just an add-on to some orthogonal business model. Any more, software is the business. The tech skills are just as important as the rest of it. Most companies today are like a group of medieval princes whose job is to correspond with other princes -- but none of them can read or write. They kind of know what they want, but for whatever reason, they feel that it's beneath their dignity to actually make it happen. The way we treat development? It's as if we were to start hiring people to write our emails for us. And then complain at how correspondence is always so difficult. Sorry for the rant. Thanks for the chat!