In my last post, I spent a long time describing some recent successes at work. At the end, I had the nerve to close the post on a very unsatisfying allusion to a ‘discussion for another post about “the process”‘. Let this post be the first installment in a recurring series discussing “the process”, by which I mean “Engineering process”.
I want to start by addressing something that wasn’t acknowledged in my previous post, and is really only obvious in retrospect: While the successes were pretty spectacular, they were made possible by a situation of extremely pent-up need. That string of rapid, extreme successes was the dam breaking more than anything. We were just there to ride the wave. We made it look easy and sound amazing, but the truth is the situation made that easy for us. Since that initial burst of productivity, things have settled down to a steady plod as we continue to iterate on improving things.
My employer has been in the process of reorganizing for several months, now. A couple of weeks ago, as part of this reorganization, I was moved to a “new” team. In actuality, this team is simply a small subset of the people I already worked with. It was an All-Star team of three. Our mission was … whatever we saw fit, related to everything in our domain of skill, interest, and concern. Mostly we would direct our efforts at release engineering, build engineering, systems architecture, and deep-investigation type troubleshooting. Stuff we already did anyway, albeit much less formally.
When I first learned of the new team (and the team reorg plan in general), I was in a bad state of burnout. So bad, in fact, I just couldn’t even get excited about the new team. I just didn’t care. However, when the three of us got into a room with our PO for the first time, the energy was palpable. We are like-minded engineering types, and I have the utmost admiration for my teammates’ skill, professionalism, and opinions. I felt much more positive after that first meeting.
Even though my organization has been practicing “agile” for several years, I have witnessed a seismic shift in what that means over the last 15 months. We have shifted from Sprint Teams running two-week Sprints and releasing every other Sprint cycle to an interrupt-driven Kanban “pull” model with no strictly time-boxed development cycle where we release twice a week, whatever is ready. This is just a step along the road to fully automated Continuous Delivery for us, though. We’re learning as we go. Our focus right now is ruthlessly stripping our manual release process to its essence, then automating what’s left.
Even though we’re focused on optimization of a semi-manual release process, we’re thinking about what else we need to do to improve our game. We’re not just thinking about release process. We’re still defining our development philosophy is, how we can create an infrastructure in which we can experiment, and what techniques we can employ now that improve our flexibility and give us more options for future experimentation.