Solutions for Agile Governance in the Enterprise

Kevin Thompson, PhD, is a physicist-turned-software engineer. He holds his doctoral degree from Princeton University, spent several years doing astrophysics research at NASA Ames Research Center, then moved into the world of commercial software. He became interested in agile processes in 2007, while managing Web application and data-warehouse projects. He holds CSM, CSP, PMP, and PMI-ACP certifications. He’s been an Agile Practice Lead at Cprime for the last 10 years and is a leading expert in software and hardware project management and planning.

His new book, Solutions for Agile Governance in the Enterprise (Sage), is the essential guide to understanding, implementing, and perfecting Agile product development throughout your organization. We sat with Dr. Thompson to learn more about the book.


So, Dr. Thompson, why did you write this book? Mike Cohn commented on your book that “it is an essential tool in filling the knowledge gaps we have in being Agile on complicated projects.” What are some of the knowledge gaps you saw out there that compelled you to write the book?

Dr. Thompson: There is a lot of good insight written for how to make Agile teams effective, but when you go up to the larger organizational levels, the information I have found is scattered and incomplete. I wanted to provide a holistic view of how to expand Agile concepts to all levels of an “Agile Enterprise.” How should an organization make strategic investment decisions? How can they manage development organizations that contain many teams, using different processes? Answering questions like these required writing a book on the subject.

The other big knowledge gap is around hardware-product development. A great deal of software sits in or around hardware devices, like cell phones and aircraft. We talk endlessly about applying Scrum, for example, to develop the software, but not so much about how to bring Agile benefits to the rest of the product space. Companies that develop these physical products have to maintain tight integration between the hardware and software elements. Maintaining this integration, and providing effective visibility and planning across the entire product-development space, is a lot easier if everyone is leveraging the same Agile concepts. My experience with Agile transformations for companies that make telecommunications, aerospace, and other very-physical products has given me insights on how to do this, and I wanted to share those insights with the world.


Who is this book written for? Who would most benefit from reading it? What are you hoping they will get out of it?

Dr. Thompson: Let me start by saying who it is not for. I did not write it to talk to current Agile practitioners, though I would be happy if any of them found it useful. I wrote it to speak to executives and managers who have hard problems to solve, for which Agile approaches can provide solutions.

At the higher levels of organizations, executives and upper management are interested in Agile concepts mostly as a means to solve their business problems. They are generally agnostic about what is “good” or “bad,” and more concerned with what is “useful.” I think it is important to speak in language that makes sense to them, and I have tried to do that.


We talk a lot about the differences that exist between hardware and software development – at a high level, how would you best describe those and why this matters?

Dr. Thompson: There are a lot of differences! And these differences can be hard for top-tier Agilists to grasp, because some of the differences violate norms that are graven in stone in the software world. The challenge isn’t in learning new things about hardware, but in realizing that what you believe about Agile fundamentals can be wrong outside the software world.

The biggest driver for differences is that the cost of change is higher for hardware products than software products. That is easy to say, but it generates other differences that can be hard for Agile experts to grasp. The impacts of this point go everywhere.

You can’t postpone major decisions and “rewrite code” later. You have to define major system constraints up front, and live within the limits from then on. This means more up-front planning than software people would consider appropriate.

Also, there are no “vertical slices of technology.” You cannot make changes to multiple technology layers to add a feature. If your “feature” needs more power than the power supply can provide, you need to put in a bigger power supply, which means more heat is produced, which means the cooling system may need to be redesigned, and so forth. This is not an affordable way to work.


The acronym SAGE (Solutions for Agile Governance in the Enterprise). Sage is also a word meaning wisdom. What would you say are the top 3 nuggets of wisdom that this book conveys to the audience and why are they so important?

Dr. Thompson: First, “governance” is not a dirty word. Governance is the set of decision-making practices that we use to guide our own work.

Second, all useful processes have common defining characteristics, such as role definitions, ceremonies (recurring meetings with standard agendas), artifacts, and so forth. So, there is a common language we can use to discuss processes in general, and to find gaps in existing processes.

Third, “Agile governance” is about making decisions quickly, using lightweight artifacts made with minimal effort. After a certain point, taking more time does not generate better decisions. It is better to move quickly, and risk being wrong occasionally, than to take a long time in an effort to avoid mistakes.


Someone commented on your book that you “understand the differences and similarities between software and hardware, and is moving Agile/Scrum methods beyond their software origins”. What do you see happening in the industry next?

Dr. Thompson: I am seeing more interest in “going Agile” from companies that make integrated hardware-software products. The story is consistent: Software people at the company are using Agile approaches successfully, and the hardware people are using classic project-management techniques that they find inadequate in comparison. As the awareness spreads that we can employ Agile methods to plan and manage hardware development work, I expect to see interest in doing that increase steadily.


What are the next steps for you personally? Another book?

Dr. Thompson: I hope not! This one took up much of the last three years of my life, and I’m not ready to make that kind of commitment any time soon. I think my next steps are to build on the Agile hardware foundation I’ve been developing and help more hardware-oriented clients.


In addition to your book, what are some resources or references you would recommend to your audiences who want to learn more?

Dr. Thompson: Below are some resources you can refer to.

Thank you, Dr. Thompson, and thank you for the insights. Good luck on your next endeavors!

Get the Book on Amazon

Go Now!
Cassidy Knight
Cassidy Knight
Agile Coach, Cprime