Getting stuff done.

Here is a week in the life of a technical coach.

I started the week by flying. I'm about an hour's drive from the airport, and this particular flight was only a couple of hours. When I land, I have about a half-hour to forty-five minutes standing outside in a taxi line, then an hour's drive to my hotel. The hotel is wonderful. I have fish-n-chips in the hotel restaurant and check in for the night.

The next day work starts.

I was working with a team (which remains anonymous). We had a quick talk, then picked up some work to do together. We agreed to try mob programming all day, with punctuated bits of explanation along the way.  I asked that we do real work all week.

However, I know it's threatening to pick someone's work that was done in private so far, and then put it on the board in front of everyone and spot code smells and issues. It just seems unfair. As a result we decided to do some real work that nobody had been working on yet.  I suggested that it could be in the existing code base so that we can work on "legacy" skills, but also if it were fresh code that would be fine.

The PO had a service that he thought would be very useful in his company, and since none of us had invested in the code already we agreed to do that work.

We began by establishing safety -- picking a stack, setting up an environment, establishing version control, installing test libraries -- so that we could start on the right foot.  The team picked a language that I was largely unfamiliar with (which is fine) and which most of them were only lightly familiar with (which is fine).

There were sets of features discussed. This was the "three amigos" meeting but done with a whole team instead of just a few people. We all pretty well knew what we were going to be doing.  The features were all too big to be cranking out several completed ones per day, so we took a little slice of a basic and essential feature and started.

We learned about the feature, the language, and the testing environment on the fly, and pretty soon had some BDD tests automated. Pretty soon we'd gotten the first test to pass, committed it, and were on to the next. We did several scenarios in the first day, refactoring and integrating as we went, learning how to write tests and code, relying on "doing one thing at a time" and constantly practicing "pickyism" on code and tests.

On the second day people were saying that this was pretty good, but it wasn't "real" code. Of course, I and the PO intended that it was very much the real code, in embryonic form. We listed the reasons it wasn't "real" and on the second day this list drove our prioritization. We did the most important part of making it real, then when something else was more important we switched.  There was some good discussion, and by the end of the day it was many check-ins further along and working as a proper server.

On the third day, besides doing demos, we completed the pipeline so that we were about 90% of the way to Continual Deployment. This involved a lot more waiting, so we used "downtime" to learn how to do things that we needed to do next. We were joined by people in the org who had heard good things about the real progress we were making.

Fourth day we picked up some "legacy" code (by the Michael Feathers definition) and spent the day cleaning, renaming, and refactoring so that we could easily add the next feature. This was another language that I was lightly familiar with, but had used once before for a couple of day several years ago.

We followed the Kent Beck rule:

When faced with making a change, first make the change easy (warning: this may be hard) and then make the easy change.

By the end of the day, the new change was relatively easy, and the code where the change must be implemented was all nicely "under test." Several new techniques were all pretty well-known by the team, and we pushed new code.

Also, on day 4 we found out that the work we did on the first three days had an internal customer already. We were close enough that only a couple of small changes would be needed to satisfy this internal customer -- even though we'd only completed less than half of the "why it's not real" list and did not complete the product backlog. It just turns out, as it so often does, that a very minimal slice of a product can provide value early in the development cycle. You almost never have to have all of the "minimal" features in order to make the code useful.

Friday? An hour to the airport, an hour in the waiting area, an hour plus on the tarmac, a couple hours in the air, an hour back home, and then logistics for my next trips and answering emails.

So, basically, I had travel and project work and then more travel. It's pretty simple. The hardest parts are mostly learning, but in software learning and thinking are 11/12ths of the work anyway.