2020 Best CIO Acceptance Speech


Published on

Published in: Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

2020 Best CIO Acceptance Speech

  1. 1. Context: Agile Journal editor Russell Pannone asked us to write an article on the agile and lean software developmentmovement 10 years from now. Tiffany and I took a novel approach of what we believe agile and lean development will look likein 2020.We started thinking as a future CIO and why it will make sense for me to adopt and grow agile. Result of that effort isan article which is in the form of an acceptance speech - best CIO of 2020 award acceptance speech. It’s in first person sohopefully reading will be enjoyable. The article was published on Agile Journal, May 2010 edition(http://bit.ly/AcceptanceSpeec).2020 Best CIO Acceptance Speechby Anupam Kundu & Tiffany LentzFor people who do not know me, it must be difficult to comprehend how I became the CIO ofthis mega multinational conglomerate. It has been an uphill task to move from the serverrooms to this boardroom; believe me that technology skills alone were not good enough tomake this gradual but sure leap. Looking back, I give credit to a heady concoction of PortfolioManagement experience, stead fast communication, and adoption of Agile principles andpractices across all the IT divisions that made this happen. And also a lot of good old luck.When I joined this organization as the VP of Engineering, 20 years back, Agile was still in itsteens. Many of my fellow managers had heard of rapid release capabilities, but had never seena company really do it. I knew from my experience in media start-ups that Agile would bemainstream in a few short years; it was just a matter of time. And there are obvious benefits indoing iterative development to incrementally build software products. Besides, Agile with its‘inspect and adapt’ philosophy chimed well with the PDCA (plan-do-check-act) paradigm of leanoperations. However it was hard for me to sell this apparently obvious concept of evolutionarysoftware product development to the bosses.The idea of “iterating” over a concept was something that only startups were doing. Thoseideas somehow did not seem ‘stable’ for an organization as large as ours. In addition, we weretied to licensing large technology stacks and rigorous deployment checklist gates, making itdifficult to accommodate frequent releases; we were limited to only two enterprise widereleases in a year keeping in mind the cost of integrating with the legacy systems for each suchrelease. While my bosses understood the proposed benefits of evolutionary software productdevelopment, they were not ready or prepared to revolutionize our IT divisions. So I was upagainst massive organizational dissent when I started advocating change: adoption of Agile’sevolutionary concepts and using open source platforms and tools for product development.Change is always an alien, still you see it happen! Since I believed so strongly in this vision ofevolutionary software product development, I wanted to prove it to those who could fund myvision and allow me to effect change. I started small, with one project in my department. I wasable to illustrate moderate success with the pilot; the business sponsor for the project wasimpressed with the cost control and the discipline involved in building the product iteratively. Igot the go-ahead to introduce the change virus in my department, one project at a time. Thistook me a couple of years, but at the end of the second year I was asked to run another divisionand made the same changes. These divisions were releasing so frequently and their business
  2. 2. counterparts were so involved that other divisions started referring to us as the “BusinessTechnology” group within the next few years. Finally, I tackled the data warehousing andmainframe divisions. A Value Stream Mapping exercise pointed out the areas needing the mostattention and we started the multi-year effort of reworking our mainframe.Back in 2010, the Gartner group wrote an article that strongly impacted the way I thoughtabout team dynamics. I was not the CIO, but thinking like one helped me further transform myteams. This article, “Leading in Times of Transition: The 2010 CIO Agenda”, called out a few keydifferentiators that CIOs (and managers like myself) should consider as we were moving from atime of recession to recovery. By focusing on the business, not on the needs of IT as a separateentity and by iterating through business solutions, we were positioning our teams and ourcompany to move forward faster than our peers. Over the years, our mindset changed. Webegan to not just SAY that the needs of our business was the heartbeat of our company, but webegan to align our technology solutions around the needs of our business so our actionsmatched our words. We, IT, began to really value the aspects that businesses value: output,productivity over efficiency, priority driven schedules, demand driving supply, ROI, etc.Gradually, one success at a time, I found strong support from the upper echelons of businessthat didn’t well-understand agile but were seeing the output and hearing the excitement fromtheir own peers. These business leaders comprehended the obvious cost benefits of thefollowing concepts that became foundational for our company: • using open source software to develop and deploy iteratively • doing more frequent discovery-delivery-discovery cycles to keep in touch with the market • waiting till the last responsible moment to commit to key decisions • adopt metrics to foster collaborative team dynamics rather than focusing on individual brillianceNow, 20 years later, Agile is truly mainstream. No development organization, internal orexternal, speaks of also-doing-Agile or Agile-in-stealth-mode. Agile is the default softwaredevelopment practice across most organizations. In the same way that no one specificallyspeaks about “Object Oriented Development” or Cloud Computing as separate practices, Agiletoday is not considered alien but an integral part of the software development teams. Over thepast 20 years, I’ve seen larger organizations who could not envision a roadmap of changestagnate and often close their doors to their smaller, more “Agile” competitors, so I believe thatthere are invaluable lessons to be learned here.
  3. 3. About the AuthorsTiffany Lentz is proudly employed as a Principal Consultant and Program Manager with ThoughtWorks, a global IT services firmfocused on end-to-end software delivery. She has worked extensively for large clients in the US, Canada, and China, deliveringsolutions for both disparate system delivery projects and agile enablement and transformation efforts to incorporate andenhance efficiency and delivery processes. She is an author, mentor, coach and trainer of agile methodologies, processes, andpractices. Tiffany is the author of Iteration Management Chapter in the ThoughtWorks anthology book and believes that theIteration Manager’s job is to build a well-oil delivery machine.Anupam Kundu is currently employed as a Lead Consultant with ThoughtWorks North America. Anupam has more than 12years of experience in various stages of software development life-cycle and post-implementation activities as a programmer,business analyst, project/program manager and change management consultant. Anupam comes from a broad consultingbackground and offers specific experience for managing large scale software projects/programs and change managementinitiatives across multiple business domains. In his current role, Anupam is primarily focused on enabling multiple globallydistributed software delivery teams through active adoption of agile/lean principles and practices.Anupam has recently contributed to books and articles on agile and is a speaker on agile/lean principles and practices especiallythat affect the product owners.