One of the most interesting points was somethings James wrote in the "Years Later..." section of "Week sixteen".
"I have not yet seen technology-first achieve significant organizational impact. If I didn't have management support for structure-first or switchover, I would focus on getting management support. At best, technology-first could provide some ammunition for those discussions, but be careful: some technical practices, such as test-driven development, take a while to show dividends. They slow you down in the meantime. Depending on your situation, they could hurt your cause rather than help."
Since my employer is rather far from being agile, I have planned to start using TDD alone first, not pressuring anyone else to do it before I have something to back up my opinion that it will help us. However, if I understood Mr. Shore correctly, this is probably not an efficient way to achieve things. I should try to change the management's mindset instead.
Felicitously, while I was reading the diary, my closest superior came to settle a time for my annual development discussion session. It's now booked, and I'll be sharing some of my views with her on Friday (in a couple of days, that is).
Now I should get some well-prepared points on paper. I'm thinking of talking about automation issues. As a first step, we could put all of our documents in a version control system, so that they're not scattered on our file server directories. I believe this could keep them better updated. I'm also going to ask our customer support team how they make their builds when preparing installation packages. It could probably be done on a daily (or nightly, to be exact) basis. And most important of all, I'll talk about automated (unit) testing, which I already mentioned a year ago.
Let's see if I can get things rolling, or if I should spend even more of my time browsing job ads (I do that already, but not very aggressively).