Yesterday a couple of readers gave me grief for all the “knowns”, “unknown knowns”, “unknown unknowns”, etc.. On top of that , the definitions got a little loose in the essay.
So instead of fixing the essay (Gad no! This is the internet! 2-hours work constitutes long-term commitment) I thought I would enumerate the scale of what you can know and what you can’t. I’m probably reinventing something from somewhere, but I think these distinctions are important enough to restate. One of the authors from the articles I quote came to the conclusion that you can deal with any amount of unknowns simply by knowing the questions. Hell no. That’s totally whacked.
Ten years ago I sat in the office of a high-ranking procurement officer in the military. He was a fast-riser, had a masters in mathematics and was a very sharp guy. I was explaining to him that the way the software development was going on a certain project was troublesome. The people, technology, process, environment, and bureaucracy were not working together. Instead various misunderstandings, agendas, confusion, and ignorance was causing chaos and poor performance.
It was a complicated discussion, made more so because each of the varying factors – people, technology, process, bureaucracy, environment – were pretty dang complicated in their own right. The way they all worked together — or were supposed to work together — was even more complex. Remember, this guy was probably a genius. Literally responsible for tens of billions of dollars. But he had no concept of what he didn’t know. It was like trying to explain String Theory to Julius Caesar. We just had no place to meet. Sure, given a few weeks of gaining some common understanding, this guy would be teaching me something. There was no stupidity at work — he was a brilliant man. He wasn’t even classically ignorant — it wasn’t like I could give him a class and a couple of tests and somehow that would fix things. We simply couldn’t communicate.
I’ll never forget what he said.
“I’m not sure I’m following you completely, but you see, I’m on top of the whole thing. I can ask any questions I like and get an answer”
My thoughts were: yes! But you neither know the correct questions, what the answers might imply, or how the answers to one question might lead to other questions!
Simply asking and answering questions is not enough. This guy had the magic power — whatever he asked, you can be sure that somebody was going to work as hard as they could to come up with an answer. And the project was still hosed up.
So in the interest of simplifying the discussion of how ignorant we all are in various ways, I propose the following scale:
In the modern world the stupid are cocksure while the intelligent are full of doubt. – Bertrand Russell
I haven’t been blogging much lately, and it all has to do with flying. Fifteen years ago a 22-year-old kid at the airport told me something that’s been resonating with me ever since.
In my mid 30s, I had decided to learn to fly. So I went to the airport, where I met a young flight instructor. He seemed like a nice enough fellow. He asked me about my desire to fly. Immediately I went through a list of things I’d like to do — first I’d like to learn how to navigate, and then I’d like to try out landing on grass strip, and then….
“Hold on a second there, hoss,” he said, “Right now you don’t even know what you don’t know.”
As I learned to fly, first as a private pilot, then getting my instrument, commercial, tailwheel, high-performance, and complex ratings (including trying out twins, seaplanes, and stunt planes, among other things) I thought a lot about what he said: I didn’t even know what I didn’t know.
He was right.
His point was that while I was very aware of what I’d like to do in terms an outsider would understand, I had no domain experience at all in aviation, aside from watching a few movies and being a passenger. It’s not just that I didn’t know the questions, I wouldn’t understand the questions, wouldn’t understand what they meant, what the answers might mean, or how the questions fit together. There was no basis for us to have an intelligent conversation.
So we spent a lot of time doing things not on my list: flying slow, approaching a stall, reading METARs, talking about maps, talking about priorities in an emergency (aviate, navigate, communicate), talking about all sorts of domain concepts, talking and learning. We created a common model understood overtly, tacitly, and functionally from which we could start to have a conversation.
You see, I thought I knew what I wanted, and I was right in a way, but in a more important way I was worse than ignorant — an ignorant person can be taught, he simply needs to be exposed to information — I was a stranger in a strange land. I was just some guy with a boatload of terms and stories that all kind of fit together in my world-view but had little credence in his — even though the terms were the same. First I had to learn and be able to physically and symbolically manipulate concepts about what I didn’t know, aviation, and then we could start talking about what I’d like to know.
The reason I haven’t blogged much lately because I am beginning to feel that the vast majority of what we say and do in the world is horribly incomplete. We’re all like kindergarteners to somebody else. We don’t know what we don’t know. This has very mportant consequences
This may have been meant as a political sidestep, but is there something very profound here as well?
This post is about true Agile/Lean thinking. If parts of it disagree with your particular opinion of doing things, no criticism is intended.
Agile is Applied Science. As opposed to most all other systems of developing technology, Agile makes no assumptions about what will work or won’t work in a particular team or situation. Yes, there are tons of best practices out there, but at the end of the day it’s just a team looking at data, forming hypotheses, creating business value, then validating or disproving the hypotheses. New teams “get this” and will immediately ask me “How about we just skip stand-ups? We’re all in the same building anyway.” To which I usually tell them something about trying the best practice for a while until they understand and know it, then change it up however they like in order to optimize.
As an outsider, you note some interesting things about teams while watching them optimize that’s not immediately apparent to the people inside the team. There is a huge aspect of psychology and sociology at work in technology teams that the teams themselves do not see. Kind of like how a fish is unaware it is swimming in water. Many times they will try something they don’t like, say pair programming, and see an immediate improvement in productivity. In addition, the developers are more happy. But — and this is really strange — if you ask these same guys if they like pair programming some of them will tell you no. Their preconceived notions get in the way of observing reality. When I first saw this I thought it was just individuals acting irrationally, but after watching dozens of teams (and seeing it in myself) I’ve concluded this is just part of the human condition.
This has some interesting implications in how teams make decisions. The ultimate arbiter, of course, is whether or not you consistently meet your sprint goals. But “meeting goals” and “continuing to improve” are two different things, and if you’re not improving, in my book, you’re not agile. Some folks will want to only use data-based decision-making processes. Some folks are much more loosey-goosey. Whatever you do, have an objective baseline, try something for long enough to really grok it, then take a hard look at whether it works or not. Remember the beauty of small teams is that you cognitively cover for each other, so you might think something sucked or had no impact while somebody else has the complete opposite opinion. Learn to be open-minded.
At the end of the day, however, it’s all Popper and Peirce. Look at data, form possible hypotheses, test, adapt. Good agile has a lot of the same attributes as good paradigm-breaking science and bad agile has a lot of the same attributes as bad science. If you’ve got the easy-going MythBusters attitude about seeing where things lead you, you’ll go far. If you’re rigid and inflexible — even if you are a huge agile fan — you won’t.
In Agile the People go to the Work, not the Work to the People. In traditional management, work is broken down from really big pieces into smaller and smaller pieces until each person has a tiny bit of work to work on each hour. People who are not working are failures in this breakdown system, and “management” is the process of keeping everybody busy.
In agile, I get to the User Story or Backlog Item level and I have reached the quantum of business value. As a management outsider, I should only be concerned with how fast the stories move across the task wall — it is the ultimate indicator of team productivity. I have to have the faith — or at least the common sense — to know that how it all happens inside the team is not something that I’m really qualified to act on. Could be they have trained monkeys doing the work. Could be they all take Fridays off. However it’s happening, if my team is delivering business value in a manner that’s tremendously effective, leave them the heck alone. If they’re not, give them some time to make sure they are not improving, then fire them. But whatever you do, don’t micromanage. It’s a funny thing: people usually know how to do their job, but if you start telling them, they are more than happy to let you tell them exactly what to do. You’ve just removed all accountability from the system.
Agile has no Standards Organization. I can buy a book on Agile Pizza-Making, and that’s a good thing. Readers of agile literature are expected to compare notes and reconcile it with the things they already know. There is no magic person or group of experts deciding what’s agile or what’s not agile (although many of them would like to!)
Ten years from now I would expect agile best practices for many items to look much different than they do today. In my opinion, the word “agile” is a marketing term for best practices around iterative and incremental development, and I’m okay with that. The other guys can keep the certifications and the One True Way. I just want a buzzword to identify ideas I might find useful.
Agile is all About the Team and the Iteration. I’ve got a chunk of work and a chunk of time. Somebody thought this work was useful to somebody, and the team thought we could make it all happen in the time provided. Let’s go make that happen. it’s such a simple concept, yet it has profound implications on how things in a team work.
In big organizations we might have a PM or a PO who helps us decide what has business value, but the idea is, really, to use the person who actually has money: the customer. Here’s a guy who needs something, here’s some people that can make it happen. Everybody wins.
Note that there are not a lot of levels or processes between the guys who can make something happen and the guys wanting something done. In fact, the simpler the better. This tracks very, very closely with the golden rule of startups “stay close to the customer” In agile, the closer you are the better it works.
As I understand it, there is a whole effort to create a fusion between startup methodologies and agile/lean ones. But I’m not sure “fusion” is the right word. In my mind, startup systems are really all about a superset of agile — finding iterative incremental projects that have value in the marketplace and how to construct them. I think if anything all of this work is simply underlining to people who either don’t know agile or don’t know startups that the two have always been in sync.
Agile teams will always win in the marketplace because agile teams always focus on the marketplace and delivering value to it. Other systems focus on other things — including the system itself. Agile is fuzzy enough to not lead to doctrine wars yet specific enough to give teams useful help in making things happen faster.