A case for Agile and DevOps — Nathaniel Laroche

I worked for a midsized financial institution that for all the wonderful value it provided its clients and employees we struggled in a number of areas, not that different from any organization frankly. One area we struggled was to transition IT from the methods and culture of the late 1990s and 2000s to the methods and culture of the 2010s. So what is a few years to a decade? At today's pace what was 10-20 years of change is 3-5 years of change today. Being a generation behind in how this firm's technology team approached its work had three large consequences and there are two key things that could have been done to start addressing these challenge.

The Consquences of an Outdated Approach to Technology

Furstrated Business. The first consequence of this firm's tired approach to the software lifecycle was a very frustrated Business. These are teams of people tasked with keeping a close eye on the marketplace and the client. While by no means perfect and not the saints of this story there were asked to implement new features and products in an effort to compete within a fast moving marketplace. However the length of time to get something to market via internal technology resulted in office jokes and a desire to look to vendors to fill gaps or outsource, sometimes at the cost of the client experience and/or at a significant impact to the P&L statement.

Frustrated Technologist. The Technologist in this story were frustrated not just from the pressure they were getting from the Business but because of what they were asked to do outside of what they love to do. These Technologist love development, they love coding, they love networking, they are Windows geeks and Linux geeks. They are security professionals who would get a charge out of well architected firewalls and security standards and a kick out of the cat-and-mouse games they played with would-be intruders. But instead of doing what they loved they felt harnessed by paperwork, endless meeting explaining what they wanted to implement and the infrastructure they would need for their code. They were frustrated perhaps most when all those meetings, all that time spent filling out paper work, still resulted in quality issues.

Quality was dismal. Code would be created and tested after what felt like an eternity by both Business and Technologist alike only to fail on deployment and be rolled back. Or if the feature did make it to market it seemed it would fail a number of weeks later when client use crushed an undersourced infrastructure solution. Of course this only worked to further frustrated the Business and Technologist noted above.

What was so Outdated to cause such Issues?

What caused the Business and Technologist so much frustration? What contributed to the quality issues? An outdated approach to technology that consisted of a front-loaded, tired Waterfall project metholodgy supported by silos of Project Management, Developers, Quality Analyst, and Infrastructure Managers followed by a reactionary problem management process that insisted on more "gates" into the requirements, development, quality and deployment process which threatened to furthur elongate the time to market of new features. The Technologist were frustrated, pointing fingers at their different silos and the Business was fed up with it all as the marketplace quickly moved past the feature they so desperately wanted to complete. It got to be a cynical cycle that took its toll on an otherwise excellent culture.

Two Mindsets that Could have Helped

Agile. The Business was desperate to participate in the technology process. Many Technologist were also open to the support of the Business, especially as the Business and Technologist got more sophisticated with incoming Millenials and Digital Natives who lived and breathed technology since the first days of their lives. An Agile methodology to software development provided an avenue to break down silos between the business, project management, development and quality assurance. The mythology started to take root and the benefits started to show themselves within just quarters of implmentation but technology leadership was slow with the pace of change.

DevOps. An Agile methodology started to make inroads, albeit painfully slow for many of the frontline stakeholders. However the backend of the software development lifecycle still consited of processes that were disjointed and infrastructure teams that were very siloed. So the feature that was developed might be what the Business needed, coded with development and quality assurance and business teams generally in lockstep using an Agile mythology but the handoff to deployment to market ran flat into server admins, network administrators and security analyst who were not incented to talk and coordinate with each other much less with the development teams. The results were botched deployments or new products that were under capacity resulting in a poor client experience.

In the end it wasn't so much about methodology as much as about culture. The resistance of a few, especially at the top of the technology leadership chain resulted in not seeing the silos for what they were. What some saw as areas of expertise and "centers of excellence", others yet saw a fifedoms often guarded with a level of arrogance that would translate into a "it isn't me, it you" mentality to problem management. To transform the IT culture from this siloed approach to an intergrated approach that rallies around a share caused, whether it be a specific large implementation, a series of small implmenetnations in support of a particular business, to create a degree of frantic fandom and a shared caused among all Technologist and Business alike was never instituted across the technology organization.

As you can guess in reading, this midsize financial services firm just started to transition to Agile and DevOps at the same time the business's ambitions continued to grow. Things were looking up although the pace of change was painfully slow for some -- then again it was painfully too fast for others, but that is a whole other conversation. Unfortunately the firm never got the opportunity to transition it's approach to technology to these methods and in doing so the opportunity to transform its culture and possibly its position in the marketplace. It was too late. Lesson learned.

Let me help evolve your financial institution! Whether in technology leadership, product leadership, operations leadership or more. Lean how my years of leadership and experience sitting at the intersection of business and technology can help your financial services company compete. Click here to learn more about my background.