Agile Technical Coaching 101

Hello, I am Llewellyn Falco a technical coach. That means that I coach teams on how to get a handle on their code and become high-performing teams.

A few quick stories of successful coaching

Two for One

Why does development take so long?
Like many other code bases, this system had been forked and modified for two clients. Sure, it started as 1 code base, but now each had its own unique behavior. No one quite knew what was different. We started using techniques for removing duplication that was first introduced during the learning hours`. Turning 2 code bases into ... 3? Yes, a core code base and two small client-specific modifications. This reduced the total lines of code from 20k to around 10k but more importantly kept things in sync. This means features and bug fixes only had to be done in 1 place to maintain both services, and the testing was also cut in half.

Winning tomorrow

How do you get a team to work 10 times faster?
While coaching a team in legacy code (RGP) we had a task that was scheduled for 4 weeks. This estimate was made before I joined the team, based on previous work. So when I joined everyone assumed we would dive right in and start implementing the feature. However, a short glance at the (very) long function immediately changed my mind. We started learning to clean the code and make it understandable and changeable. This took a while and while the code was getting cleaner, the deadline was approaching. 3 weeks and 2 days into we finally had a nice clean function and now it only took us 2 days to complete the feature (1 day early!) Not a big win, until we had to implement the next change which now could be done 10X faster than before.

Rapid Development

How quickly can you respond to challenges?
A team a had been working with for around a year had been internalizing modular code and unit testing to the point that they were now producing new features every other day and releasing them. This introduced them to some high throughput situations which meant they were running into the limits of different frameworks they used. However, they had been coached on how to separate business logic from a framework so they could experiment and adopt new frameworks when they hit scaling issues. How did I know this was happening? Simple, each time I would visit they had adapted a new technology. I've never seen a team move so fast.

Do you need a Technical Coach?

What to measure

Here are three easy things to look for.

1. Bugs

How many programmer hours do your teams spend fixing bugs and responding to incidents? If you can reduce the amount of time you spend fixing bugs (much less writing them) you can have huge improvements in team effectiveness.

% Time fixing issuesIncreased VelocityThe Math
5%   5% ⬆1 🐜 + 19 πŸš€ ⇒ 20 πŸš€
10%  11% ⬆1 🐜 + 9 πŸš€ ⇒ 10 πŸš€
33%  50% ⬆1 🐜 + 2 πŸš€ ⇒ 3 πŸš€
50%100% ⬆1 🐜 + 1 πŸš€ ⇒ 2 πŸš€
75%300% ⬆3 🐜 + 1 πŸš€ ⇒ 4 πŸš€

πŸš€ = Features
🐜 = Bugs
⬆ = improvements

How to measure bugs.

Check your bug tracking system and your task tracking (often Jira). You can get a sense of both what percentage of your tasks are bug fixes and how many person-hours you are spending on them.

2. Features shipped per quarter

But we aren't here to fix bugs, we are here to build new things! How fast are your teams doing this? Would you like them to go faster? Without increasing headcount?

How to measure Features

There are two things to look for here. The first is simply to count the number of features, maybe you use story points which can help, but be aware that one team's story points can be completely different than another team making it hard to compare.

There is also a less quantitive metric. Ask yourself if simple changes seem hard to do for the teams. If so, they are probably under a lot of technical debt and there are large improvements that can be made. Another way to measure this is to check your code metrics for the number of methods you have that are over 100 lines long. Over 1,000 lines long? These are also easy signs of technical debt that are costing your team's productivity.

3. Time to resolve urgent issues

In terms of risk, the worst firings occur when mistakes are made. Of course, it's not about not making mistakes, everybody makes mistakes. It's about not making costly mistakes. The truth is, most of the cost of a mistake is the time it takes to fix it. How are your teams doing in regard to this? Simple, look at the time it takes between an urgent issue being noticed and when it is fixed in production and no longer an issue.

How to measure time to fix

Again, Jira is probably the best place to measure this, but there is another heuristic that can help. Fear of releasing? If your teams are scared to release on a Friday or block off a whole weekend when releasing that is probably because when things go wrong they are hard to fix. Also, if you have recently dealt with a security issue, ask yourself how much trouble it caused: A few hours? A few days? A few weeks? Longer?

Coaching vs Teaching

I am a coach, not just a teacher.

Teaching can be done as part of coaching, but a coach does much more in addition to teaching. Teaching conveys information. Coaching conveys information and empowers your team to use it. Teaching is often done in an artificial environment designed to focus on the skill being taught. Because the environment is tailored to the material, students feel invincible until they have to face the reality of their work environment. Coaching happens in the actual code your team works with every day, so your teams learn how to apply their knowledge when the environment isn't perfect. Teaching rarely results in long-term behavior changes because simply knowing something isn't nearly enough to apply it. Coaching on the other hand is focused on behavioral change.

The measure of a coach is not what they do while they are there, it is how the team behaves differently when the coach is gone

Who's Llewellyn Falco

Here are a few videos to get a sense of me:


Next Steps

If the above resonates with you and you are interested in going further,
the next step is to set up a 30-60 minute call.
It's free and we can get a clearer understanding of what your situation is and if and how I can help.
Email me to set up a time.

No comments: