I remember when I first learned and really grokeed Object-Oriented Analysis and Design. I had read a bunch of books. I had even designed and coded some systems. Some had went well, but some, well, were a bit more complex than they needed to be. See “Architecture Astronaut”
Then one day I picked up use cases. Not the god-awful templated 30-page nightmare that most companies make out of use-cases; the real deal. trigger-actor-goal-context process analysis. The kind you can do on a napkin. Maybe sketch something on the back of it if you’re having problems. Specifically, how process analysis fits into Object-Oriented Analysis. Process analysis tells you what needs to happen. OOA tells you what are the logical pieces to make it happen. Semi-structured, all from plain English.
I realized at that point that both OOA and process analysis helped me do one very important thing: I no longer had to keep the entire problem in my head at one time. I had a system that I could use to pick up any problem and drive it towards some kind of resolution. It might be an ugly resolution, but I could get there. I didn’t have to be a genius to solve tough business problems. I just had to follow the system.
I had a similar experience with Agile. As a young PM, I had a desire to plan out everything my team was doing. After all, the more I planned, the less risk there was, right? How could you do anything truly complex and important without having a detailed plan of how you were going to attack it?
At the time, I hated making developers suffer, so I held back. I would secretly plan a bit out ahead in order to make myself feel better, but unless we needed it, I let the team do their work. This wasn’t out of any feelings of comfort. Heck, I spent most of my time as a PM worried about the 17 thousand ways things could go wrong. It was the mid 90s, and we were charging tons of money to solve complex problems. Lots could go wrong.
But what I found out over time, as I adopted more and more “Agile” practices without even knowing it (“Agile” didn’t exist at the time), was that all of my planning was really just a Stupid Human Trick. I felt that by treating people like computers, by programming out everything that was going to happen, that somehow I was reducing risk. But what really happened was that people would always find the problems I missed, and if I left them alone, would go fix them. Turns out people were pretty good at identifying and structuring their own work as they went along. Much better than I was by myself, doing it for them.
Eventually I learned there was a system. There was a minimum amount of structure that I could (had) to provide for teams to succeed. As long as I did that, they would always rock and roll. My job as a PM (and later SM) was to get obstacles out of the way, provided the most minimum amount of structure necessary, and watch the magic happen.
I didn’t have to be a genius to solve tough technology development problems. I just had to follow the system.
As a coach, when I explain these and other concepts like them to folks, many times I get the “crazy uncle” smile. Yes, Daniel, they say, of course it’s all that. (Meanwhile wondering how much I am billing and how did we get stuck with this nice, but misguided guy who thinks the world works on magic)
I think it’s one of those things you have to see to believe. Once you tackle a super-complex business problem using simple tools, you realize you can do this over and over again. Just trust the system. Once you see a team solve a ton of development problems while delivering a product the customer wants, you realize you can do this over and over again. Just trust the system.
Yes, we take this too far. Sometimes people don’t really understand that there is a balance between structure and chaos. Sometimes they want to say silly things like “It’s emergent” to describe conversations and processes they don’t understand. When you see the magician do a few tricks, you might start thinking he can do anything. He cannot.
But most people have the opposite problem. They come from school, where you had to understand the complete problem and solution to get a grade. They want to do well where they are, so they want to be able to describe just how each piece of the process works to create a solution. It is completely counter-intuitive to think that by doing simple things in a system, you can achieve enormously complex goals. But for many of the really cool things in life, that’s how it works.
Trust the system.If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.