After spending the morning at the hospital, we headed out to my sister's apartment to help get things ready for their coming home. Ben and Marvi just moved from uptown Manhattan into a much bigger place in Brooklyn. They got a really sweet deal on an apartment with three bedrooms and a huge living/dining area. They have the baby's room all ready, complete with day bed and a mobile, bassinet, diaper disposal system, baby books, stuffed toys, a dresser full of baby clothes, pictures, posters, alphabet stickers on the wall, a baby floor mat, ...you name it, it's ready. Everything looks good to go.
Just One Thing to Screw It All Up
Of course, anyone who has had a baby will tell you that no matter how ready you think you are, one thing can mess it all up: the baby.
Marvi and Ben, you guys are in for the ride of your lives and it ain't all going to be smooth sailing, no matter how much you try to prepare. Don't get me wrong, there's absolutely nothing wrong with a little preparation. But there comes a point when you just have to go and do it. For Ben and Marvi, that point in time was when Marvi's water broke in the middle of a routine checkup with her Ob/Gyn.
This, of course, got me thinking about Agile, Aikido, and football again.
Just as the baby's arrival does with parenthood, in football, one thing can really screw up all your careful planning and preparation: the game. And what, you might ask, is it that screws up our carefully-laid plans in software development, including Agile? Why, it's the problem you're trying to solve, of course. No matter how well you try to prepare and lay out plans for creating a solution to the problem at hand, the certainty of those plans never really extends far beyond the first line of code written to solve it. From the moment you start actually tackling the problem and trying to create a solution, your plans become subject to change for a myriad of different reasons.
According to this entry in Wikipedia , it was Helmuth von Moltke the Elder who wrote, "No plan of operations extends with certainty beyond the first encounter with the enemy's main strength," which is sometimes mistakenly simplified to "No plan survives contact with the enemy."
So Much To Do, So Little Time...
You've probably heard football players talk about the "speed" of the game when they go to the next level of play. Whether it's from high school to college or college to pro, players often talk about how much faster the next level is from the last. It's as though they felt like Lucille Ball in the classic assembly line bit: overwhelmed, helpless, and hopeless.
I'm sure many people trying to go Agile feel much the same way. Because just when you think you've got Agile-Scrum down, you realize there's a bunch of engineering practices from Agile-XP (Extreme Programming) that complement it. And then you hear that there's a bunch of things from Agile-Lean that you can do to scale Agile to the enterprise level. And so on. Have you ever seen that poster of a gorilla sitting down, looking really tired and dejected? The caption says "Just when I thought I knew all the answers, they go and change all the questions." Yeah, like that.
So what do you do when, just as you thought you had all your ducks in a row and were ready to take your organization to the promised land of Agile, a bunch of people start asking a hundred different things about what exactly is in store for them in the land of flow and quality and how are you all going to get there? What do you do when, as my colleague Michael so succinctly put it, "The horse is already out of the barn," and you realize that there are still a million different things to do that you didn't put down in your plan?
Too Much On Your Mind
When I started learning Aikido, my partners would often tell me that I was too tense. They could feel me tense up my arms and body whenever they grabbed me or attacked me or whenever they tried to perform a technique on me. In Aikido, tension keeps you from executing techniques properly and it changes the way your partner applies a technique on you. It also makes for a less than enjoyable learning experience for both you and your partner.
What makes you tense up? In Aikido, you tend to tense up when you think too much about what you need to do. When you first learn a technique, you naturally want to do it exactly right. You tend to break it down into all the little things you have to do: watch your footwork, your body position, how you break balance, how you control your partner, etc. Then there's the technique itself.
In football, the players have to deal with lots of things all at once too: the game clock, the play clock, where the line of scrimmage is, where the first down marker is, where the sideline is, where the goal line is, the count, how the other team is lining up, how your team is lining up, etc. And then there's the play itself.
In Agile, well, you already know how much there is to think about in Agile. How can you not tense up with all these things to watch for? What can you do to keep from freezing in your tracks like a deer in headlights in the face of the barrage of concerns people bring up when you tell them you're going to go Agile with them?
First of all, relax. Empty your mind.
My Aikido partners would always tell me one thing whenever they felt me start to tense up in practice: "Relax. I won't hurt you." After a while, I learned to trust my partner and myself. I learned that relaxing made it easier for me to receive the technique when it was performed on me. Relaxing also made it much easier for me to perform the technique. I found that when I didn't think too much about every single thing I needed to do, I could actually do everything better. In Aikido and many other martial arts, it's called "the empty mind." In football, it's that seemingly magical transformation in players that happens when they "settle in" and learn to "slow down" the speed of the game.
In Agile, it seems it's not that simple to just relax. Or is it? Let's see, we have the prioritized backlog. We have the timeboxed iterations. We have the principles of "Doing The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need It." We have the feedback loop from retrospectives, and sustained incremental delivery of working software, and frequent customer demos of working software. We have the daily standup meeting. We have "Eliminate Waste" and "The Last Responsible Moment." We have the "40-hour work week," and so on.
If we just pause long enough to catch our breath and look hard and understand the intent of the Agile techniques and practices, you'll see that they all add up to humbly accepting one simple truth: "You ain't always gonna get it right the very first time."
Second of all, don't stop.
The other thing I heard a lot during Aikido practice is "Don't stop. Keep going." When you're learning a technique, there's a natural tendency to stop and start over when you realize you did something wrong like turning the wrong way, pointing your foot in the wrong direction, or not breaking your partner's balance correctly. After a while, you realize that making mistakes is a big part of the learning process. That's why you just have to keep going and finish the technique.
Sometimes, it's not what you do that changes the dynamics of execution. In Aikido, we practice with different partners of different ranks. Each one receives the technique differently. What may work for one does not necessarily work for another. But still, you keep going and finish the technique so you can learn to feel the difference.
In football, this is the same as getting YACs, yards after contact. If you're not dragged to the turf on first contact, you keep moving, keep your legs pumping, keep the pile moving, try to break tackles, and fight for every extra yard you can get.
Software development and Agile are no different. No two projects are the same. Why do you think there are so many different accounting systems out there? And the business problem is always changing under you. There's always something that puts us back on our heels, tips us off balance, making us adjust to the new state of things.
The opponent doesn't stop the attack when you mess up a technique. The play doesn't end when that first tackle is made. The game doesn't stop when you turn the ball over. The need for a solution doesn't go away even when your understanding of the problem changes. The business doesn't cease operations just because you're not doing "pure Agile."
If, as apparently the Buckeyes did at Purdue today, you lose a game, you shake off your disappointment, go over the film and learn from your mistakes, and get ready for the next game. If the software isn't doing quite what it's supposed to yet, you write another test, write more code, refactor, and schedule another demo. If your development process isn't delivering all that Agile promises, you have a retrospective, put a process improvement story in your backlog, and get it done in another iteration.
It's all about improvement
There are no promises of a black belt, no promises of a championship title, no promises of development bliss and total customer satisfaction. If, in the end, you do get all that, then that's just a lot of icing on the cake. The whole point really is just doing something and trying to get better at doing it. That's all we can really shoot for, right?
"The reality is that nobody is going to give you a little gold star for being agile. They might, however, reward you for becoming more effective at system delivery." -- Scott Ambler, Chief Methodologist / Agile & SOA, IBM Rational
As for Ben and Marvi, well, only time and Mateo Natan will tell you what you guys need to do next. Good luck and remember: relax and just keep doing what you gotta do. You'll be fine. Mazel Tov!
