Agile
I promised on Facebook that I’d say some things about the Agile software-development idea. I’m by no means an Agile expert, but it made a lot of sense to me. There were a few components that I really liked when we used it at my last job. They’re pretty dyed-in-the-wool Agilists; I probably would be if I really dove into it, but as it is I’m picking and choosing the bits I liked. Here goes:
Daily stand-up meetings. You and your team literally stay standing long enough for each of you to explain a) what you did yesterday, b) what you’re going to do today, and c) what’s holding you back, if anything. If you spend too many days in a row saying, “I meant to finish x, but I didn’t, and I swear it’ll be done today,” eventually those on your team are going to ask if they can help you get past whatever roadblock you’re encountering. Which is a polite way of saying, “Come on, now; hurry it up.”
Staying standing is vital here. Meetings get over a lot more quickly if you’re on your feet rather than kicking them up and sipping a cup of coffee.
Feelings of human shame. I feel like the last bullet calls out one important part of Agile: it’s built on the very deep-seated need not to fail in front of others. It’s certainly possible in a lot of organizations to hide in a corner and fail for a long time before anyone notices. Agile makes that much less likely: if you fail, you’ll fail within a few days in front of your whole team. Better to ask for help than flounder pridefully.
Monthly kick-off: You tell everyone what you’re going to do. They get a chance to ask you why you chose to prioritize one thing over another.
Monthly show-and-tell: You and your team stand up in front of everyone in your organization (sensing a pattern?) and show what you did; they get to evaluate, among other things, whether you did what you said you would do during the kickoff. Preferably everyone on the team does this for his or her own part of the project. Again, you do not want to be the person who failed to get your thing done.
Small teams with a few defined roles. In our case the roles were developers (the people actually writing the code), QA engineers (testing), and “product owner.” The product owner is the voice of the customer. She (and I’m happy to say that this isn’t just political correctness overcompensating: we really did have a delightful, brilliant, energetic product owner who happened to be a woman, along with plenty of kick-ass male product owners) tells the developers what we need to build and lets us figure out how to build it. Then she talks to customers and figures out what to have us do. And she tries as hard as she can to clear shit out of our way so that we can get work done. I was a part of at least one meeting filled with three or four engineers, that our product owner interrupted halfway through to say, “Do the engineers really have to be here for this?” whereupon, the answer having been in the negative, we got up and left. See “Few meetings, fast, standing up,” below.
Short iterations: The interval between planning and show-and-tell is pretty critical. You don’t want it to be too long: saying, “This project will take a year to complete” is as good as saying that it’ll never be done. But you don’t want a show-and-tell every week; that’s too much bureaucratic overhead — or maybe not, if that’s what your team decides is right. But it certainly feels to me like there’s a tradeoff: keep going until the marginal benefit of shortening deadlines is just offset by the marginal cost of larding the process up with meetings.
There are several important reasons to have these short cycles. One is, as I mentioned, that planning for a small task is (duh) easier than planning for a long one; you’re much more likely to end up accomplishing what you said you would. Second is that you’re outrunning your customers, namely those inside and outside your company who want you to do things for them. The faster you can get something rough and ready in front of them, the less likely they are to say, “You know what would be really nice? …” or “Oh, sorry, turns out that we fired the CEO and now we’re looking for something different.” You’ve also given them something to anchor their expectations: now instead of comparing what’s in their head to a blank canvas, they’re comparing it to something real. That’s likely to focus people and ground them.
Certainly the most exhilarating work experience I’ve had since leaving college was building a rough prototype at my last job. We got something out the door in, if memory serves, 3-4 weeks (might’ve even been more like 2) and in front of customers. We asked them right away: is this something you want? Yes, the UI is crappy, but ignore that; we’ll make it look nice later. (Those of you objecting here that design — of software, of posters, of books, of whatever — is fundamentally bound up with the functioning of the product and isn’t just about “making it pretty”: yes, you’re right, but I’m pretty damn convinced that rough-and-ready is a tradeoff worth making.) Does it do, functionally, something you’d want? What else would you want it to do? Does this replace something you use in your everyday work? After you get done using this tool, what’s the very next thing you’d go do?
Once we had those answers, and we were convinced that real people would really use this thing, we sat head down at our computers for a couple weeks (I think we were on two-week cycles here) and got another block of interesting work done. People came by during the show-and-tells, looked at it, critiqued it, and told our product owner what else it needed to have. Heads back down. After a few months of this, I looked up and — hot damn! — we had a really nice piece of work in front of us. I can’t say I was responsible for big chunks of the code, but I did what I could, and I felt proud of what we’d accomplished.
Few meetings, fast, standing up: This isn’t part of according-to-Hoyle Agile, and you could have it as part of any organizational structure, but I suspect that organizations which take Agile to heart will want to use this too. At my last job we took Paul Graham’s notion of maker time versus manager time to heart. The idea there is that, for a manager, the hourlong meeting is the quantum of work; the manager’s day is scheduled in one-hour blocks. Whereas writing software — and maybe this is true of other focused endeavours — takes a few hours to get into. Me, I needed the music to be set up right, I needed maybe a cup of coffee, I needed to knock off some smaller programming challenges to get the muscles limbered up … it could take me an hour or two just to get going. An hourlong meeting thrown into the middle of that bungs everything up: by the time you get out of the meeting, you forget where you left off and need to do the coffee, the programming exercise and so forth all over again.
Meetings are good for some things. If you’re hashing out a strategy, or the structure for a few weeks of work, you probably need meetings. But to the extent that you can shunt them onto email, or onto quick in-person chats in the hallway, you’re creating space for your makers to make stuff. (By the way, I was extremely cautious — maybe too cautious — about approaching people, for exactly this reason. First I emailed them, which seemed like the least-intrusive way to get in touch. Then I IMed them. Then I walked over to them and chatted. Yes, the last method is likely to be fastest for me, but it’s also likely to break their concentration.)
Test-driven development. This is even less a part of classic Agile, and if you’re a certain sort of person maybe you feel you don’t need it. Me, I needed it. The idea here is that you write the tests for your code first, then write the code, then confirm that your code passes the tests, then write some more tests, then write some more code. At every iteration, write a failing test just as fast as possible. For me, this was a way to combat my own inertia, so this is sort of like Feelings of human shame: Agile fundamentally seems like a way of adapting an organizational structure to fit human behavior. When I forced myself to write a failing test as fast as I could, I was fighting my own habit of overthinking a problem before I started solving it. Yes, thinking is important, particularly when it comes to design, but there’s a certain kind of thinking that is either a) telling you why a certain thing won’t work, or b) pre-emptively making a solution elegant before you’ve made it at all. Test-driven development (TDD) says that elegance can wait just a bit. Write your test, then write your solution, then confirm it works (test passes), then make it elegant (i.e., more general, i.e., refactored). You’ll get the elegance soon enough, but in the meantime you’ll have working code. And who knows: by skipping the elegance for a bit, maybe you’ll find that a whole different approach works better.
Like I said, this isn’t really by-the-book Agile. But these are all things that make a lot of sense to me, and worked great for us.