BiographyMy personal website is TheTalesOfAgility.com
I’ve spent nearly my entire career focused on how to profit through the application of information technology. I started building basic-based models for the US Commerce Department to help enforce fair-trading laws in 1980, and I’ve made it all the way to rolling out a mobile system that does instant mortgage approvals based on data gathered from automatic deposit data in any major bank. In between I’ve been on teams that built customer information systems, early web-based home search, branch banking systems, and a passel of systems that helped Wells Fargo and its struggling home owners get through the financial crisis.
My college education was completed early in the computer age. At Carleton College as a young physics major there was only one half-quarter computer class, while in graduate school at Princeton for international economics our computational life was confined to a statistics program that generated 80-column cards for entry to the computer behind the glass wall. When I joined the Commerce Department in Washington in 1980 I was the first professional in the building with his own Wang terminal, which I adopted early to support my role writing policies, speeches, briefings, analyses, and a treaty with the European Community.
From DC my family and I moved to Minnesota where I have mostly bounced back and forth between the two big banks, after several mergers each now Wells Fargo and US Bank, with an interim as CTO of a real estate software company. I began as a commercial lending trainee and gradually drifted towards my true calling as a business-oriented software engineering leader, progressing from strategic planning to project management, system management to CTO and business line CIO roles.
Ever since my first program on a time-sharing terminal in Washington, I’ve been drawn to operational improvements through computing. Early on everyone did “agile,” so that is native for me. I then lived through the fascination with formal methods, computer-aided software engineering, Capability Maturity, counting lines of code, and more, all of which I learned from but none of which I could completely embrace. When the Agile Manifesto was published I was immediately attracted to it and built upon it since.
I’ve been fortunate to see software development from its early days in business evolve to the pervasive endeavor of today, mostly in two outstanding large financial institutions and in one software company. I’ve worked closely with dozens of software and technology services companies and have seen a lot of success and unfortunately a lot of failure. My most intense period was managing the technology and process engineering for Wells Fargo Home Mortgage through the financial crisis, while my biggest failure was the disaster that sparked me to write Tale of Two Systems. Relevant formative experiences include my stint managing a large mortgage operations group which led me to lean operations, the leadership training from Lucy Buckley at just the time I needed it, and many lessons I’ve learned from the great people with whom I’ve been lucky enough to have as team members.
I was recently asked why I wrote my books. My response:
"I was one of four leaders of an enormous failed development project at Wells Fargo around 2007. My team had already successfully adopted lean operational processes in a very large manufacturing-like process, as well as early agile ideas. Our part of the initiative was great: we had built out pioneering eClosing for mortgages, online document delivery and uploads, a sophisticated document generation system, efficient and accurate document imaging and indexing, but the rest of the project failed. So despite us being ready to release, the whole team was let go and Wells started over. We had tried to help the rest of the team adopt some lean and agile techniques that would have helped, but they were so committed to awful waterfall-type process that we entirely failed.
Almost as therapy, I undertook to write a book that would be accessible to business leaders dependent on large-scale technology to help them avoid such devastating failure. Wells Fargo had great business leaders, plenty of money; I believed that the core misunderstanding of how to do a large project like this was at the root of the problem and wanted to help.
Fast forward a few years. Similar desires led me to write the second book as I saw organizations struggle to implement agile, mostly around top-down mandates versus bottom up organic growth. Neither approach is “right” — it depends on context. Which brings us to this book. Like the others, it grew out of seeing problems in practice, this time the problems of mistakenly thinking that implementing scrum is the same as become agile. After seeing too many “product owners” mindlessly writing out “user stories” in the agile tool, essentially doing big requirements up front just like they used to in waterfall, I resolved to finish up the trilogy."
These experiences and my native curiosity and analytical bent provided me with the foundation to assemble the personal view on lean and agile I’d like to share with you. I hope you find it useful.
Areas of Research / Professional Expertise
Software development, information technology, leadership, lean product development, agile
Work, of course; family; exercise, golf, biking; reading; Great British Baking show and other cooking shows.
Published: Dec 03, 2019 by Strategy Driven
Authors: Michael K Levine
Subjects: Computer Science & Engineering
Explains the unique challenges of digital transformation and the People Over Process leadership model that best supports success. Three actionable tips are given: use of frameworks, leadership behavior, training/teaching leadership skills.
Published: Nov 11, 2019 by Enterprise Project Community
Authors: Stephanie Overby
Subjects: Computer Science & Engineering
“‘There are two basic approaches to making significant change: people-driven and driving people,’ says Levine. The former bottom-up approach emphasizes people and relationships and encourages leaders to make changes at the right pace for their organization. That works well in well-performing organizations with solid leadership, or in cases where drastic shifts are too risky.”
Published: Oct 16, 2019 by CEO World
Authors: Michael K Levine
Subjects: Engineering - General
Executive Insider column explaining need for leadership to sustain agility and introducing the key concepts of rigor, alignment, efficiency, and frameworks.