mike.mainguy

I recently noticed a position within my organization that looked like a dream job to me. "The primary role of this individual will be transformation. They will provide a fresh view into IT technology strategy and will transform the role of the team and the capabilities of the individuals. They will establish, implement, and maintain a unified technology strategy for the organization. They will lead a team of approximately 10 senior IT specialists and will actively participate in the highest profile, most strategic IT initiatives in the enterprise. The Enterprise Architecture team is not only accountable for setting our technology strategy, but is also required to assist project teams in implementing the strategy." As a person who has spent 5+ years trying to transform our organization from the bottom up, I thought I would be a perfect fit for this position. Who better to help make this transformation than someone who has "been there, done that" and already made...

Running myself through a our software development and delivery process, I was struck with an interesting and always present problem. It's all fine and dandy to be able to deliver working, high quality code at a rapid tempo, but somebody's got the RUN it! This problem of the dichotomy between operational stability and innovation sits at the core of every decision I make lately. On one hand, the servers must be able to run in a cost effective manner. We can't just gut the data center every year because some new cool thing has been introduced just because it's cool. On the other hand, we can't just keep using the same old technology we've been using for 20 years because we can torture it into solving any problem. For folks who have been programmed to "keep the data center running", any new or disruptive technology is bad. End of story, no question, no doubt. This is further strengthened by the "fact" that almost any problem that ca...

After an eye opening weekend, my coworkers and I went about trying to figure out which things we could easily do to make our software better. In addition, we took on the responsibility to "sell" it to our management team. I was completely floored when we started talking to the managers and they started getting really excited about this stuff. I totally expected people to start saying things like "yeah but, we can't do that here" and instead we where met with "wow, that's great, let's do it!". Shows how well I know people, so, now we're getting somewhere....

I attended No Fluff Just Stuff in Chicago this weekend. There is only really one word to describe it, "wow". The speakers where stellar, the format was very personal, and the camaraderie was extraordinary. Coming from an organization that is still very waterfall where testing is a manual process that people slog through, it was eye opening that some very BIG companies where doing this agile sort of stuff on very critical products in super mission critical situations. I spoke with people who wrote embedded devices (pacemakers), avionics software, pharmaceutical software, and many other products who's criticality make my current system (a retail item management system) look like a rather big "hello world" project. The biggest gain I've taken away from this was that getting the management team's buy in isn't enough. I need to go gather metrics about the risks and waste in our current process and simply implement fixes to eliminate them. The agile c...