Contents
Guide
Page List
Untapped Agility
Untapped Agility
Copyright 2020 by Jesse Fewell
All rights reserved. No part of this publication may be reproduced, distributed, or transmitted in any form or by any means, including photocopying, recording, or other electronic or mechanical methods, without the prior written permission of the publisher, except in the case of brief quotations embodied in critical reviews and certain other noncommercial uses permitted by copyright law. For permission requests, write to the publisher, addressed Attention: Permissions Coordinator, at the address below.
| Berrett-Koehler Publishers, Inc. 1333 Broadway, Suite 1000 Oakland, CA 94612-1921 Tel: (510) 817-2277, Fax: (510) 817-2278 www.bkconnection.com |
Ordering information for print editions
Quantity sales. Special discounts are available on quantity purchases by corporations, associations, and others. For details, contact the Special Sales Department at the Berrett-Koehler address above.
Individual sales. Berrett-Koehler publications are available through most bookstores. They can also be ordered directly from Berrett-Koehler: Tel: (800) 929-2929; Fax: (802) 864-7626; www.bkconnection.com
Orders for college textbook/course adoption use. Please contact Berrett-Koehler: Tel: (800) 929-2929; Fax: (802) 864-7626.
Distributed to the U.S. trade and internationally by Penguin Random House Publisher Services.
Berrett-Koehler and the BK logo are registered trademarks of Berrett-Koehler Publishers, Inc.
First Edition
Paperback print edition ISBN 978-1-5230-8830-0
PDF e-book ISBN 978-1-5230-8831-7
IDPF e-book ISBN 978-1-5230-8832-4
Digital audio ISBN 978-1-5230-8833-1
2020-1
Book producer: Westchester Publishing Services; Text designer: Westchester Publishing Services; Cover designer: Adam Johnson
To all the change makers out there, and to Seema, whos changed me the most
Contents
Foreword
Luke Hohmann, author of Innovation Games
I t turns out that computers can teach us something about transformational leadership.
When you run a software program, usually something happens. Thats kind of the point of a program, right? You click a button or you type in a command, and instantly you see some sort of feedback. You run the program, it executes, and then its done. In other words, it comes to a halt.
But this isnt always the case. Sometimes a program runs for a really long time. Sometimes even for an infinitely long amount of time. This creates a problem: theres no way to actually tell whether a program will ever be done. In fact, its one of the most fundamental problems in computer science, so fundamental that solving it changed both mathematics and computer science forever.
Lets imagine a program like this:
while(true) {
print(I am running.)
}
Since true will always be true, we can see that this program will be printing for a very long time. It will never halt. This is a pretty simple example, but what about more complex programs like gene sequencing, data mining, or stock predictions? The question is known as the halting problem.
An obvious solution is to run the program and see what happens. If it runs and then stops, the problem is solved. But wait, some programs take a very long time to finish. What if our program didnt halt now but will halt after, say, one hour, or one day, or one thousand years? How do we know if we should terminate the run or keep going? Thats the challenge: unless you run the program, you dont know if it halts. And even if you run it, you wont know if it halts unless you wait potentially forever.
The brilliant mathematician Alan Turing, considered by many to be the father of computer science, proved that it is impossible to tell if an arbitrary program will halt once it starts running. And when I say impossible, I dont just mean hard. I mean literally, mathematically impossible. So the only response is to work around the problem: watch and adapt. We can monitor and limit the expected resources the program will consume (time, memory, or CPU processing) and stop the program if any of these resources are exceeded. Once stopped, we can examine, adjust, and try again.
Agile transformations often experience the organizational equivalent of the halting problem. We dont know how long it will take. We dont know if the transformation will make things better. We dont exactly know what the organization will look like when were finished. Most leaders will argue they have a fiduciary responsibility to have answers to these questions before going any further.
Unfortunately, Turing showed us we do not get to have the luxury of those answers; we cannot know whether or where the transformation will end. Instead, the only way to know if a transformation will be successful is to start it, monitor its resource consumption, and then adjust as needed to keep things on track.
In this marvelous contribution to the agile canon, my friend and colleague Jesse Fewell shares powerful advice on how to start, monitor, and yes, if necessary, pivot your agile transformation to success.
Untapped Agility
CHAPTER 1
Transformation Frustration
Expectations were like fine pottery. The harder you held them, the more likely they were to crack.
Brandon Sanderson, The Way of Kings
T his book is about leading change, and we need to start with a story. I once worked for a startup entrepreneur named Jeff who told me a business story so compelling, I will never forget it.
Jeff was a colorful character, whose first career was that of a restaurateur. Jeff was a force of nature and over the years worked his way up from busboy to server to sommelier to general manager to restaurant builder. One year, he was sent off to a hot new location to build the latest Planet Hollywood, the franchise eateries famous for their dcor patterned after the movies. Their playbook was solid, with key criteria for geography, layout, furniture, dcor. These guys knew how to build a repeatable premier experience. The boss told him, Your new location build-out is a slam dunk. The space is in a great location, and we got the old building at a steal. Just renovate and launch, and this place will make money.
With his orders in hand, Jeff traveled to the property to meet the contractors who would construct the new location. When he arrived, he saw firsthand the easy access from the main roads and the busy retail foot traffic. Everything looked promising. Until he went inside.
There, standing in the middle of his promising new restaurant space, was a giant, ugly column. It was a massive monstrosity; it took several people holding hands to surround it.
Jeff summoned his new team and said, Hi there. Nice to meet you all. Im hoping someone can tell me, what is that? Well, boss, that is a load-bearing column. We cant demolish it, so well have to build around it. Frustration welling up inside him, Jeff said, That thing consumes dining space and is a giant eyesore. What do we do? Immediately the team started brainstorming: