I Have Written Bug-Free Code Without TDD

There's an excellent blog post by Felix Geisendörfer which gives his experience report on using TDD. Kent Beck tweeted about it, so it's hopefully "going viral" right now. Read it here.

Reading his post, and some of the comments afterwards (when will I learn?!), got me to thinking about my own experiences with TDD, and I decided to share two of my own stories.

Once Upon a Time

I used to write bug-free software without TDD! (Look at me: I am so smart...)

My boss and I would play this game called "Who Wrote the Bug?" in which he would claim that a bug was in my code, and I would come back (after painstakingly debugging the whole product) and point out where it was in his code. (Hmmm...who was smarter?)

Humility Sets In

The software I was writing was a protocol stack that needed to convert between 8-bit and 9-bit bytes, or 16-bit and 36-bit words. I used the command-line/printf approach (System.out.println for the Java readers; Console.WriteLine for C# readers) to test stuff. The debugger, COFF, was okay, but testing through a debugger is such a pain.

If you haven't figured it out from the clues I've dropped, this was over 20 years ago. In retrospect, this was pretty tame stuff. I could keep track of what was going on in my head.

One can assume that software projects these days are more complex. Perhaps too complex for one person to keep track of all the little moving parts. It's enough for the team to have a grasp of the overall concepts, goals, and metaphors.

I would argue that even on a team with only three or four developers, eventually they're going to bump into each other's changes. They need a suite of microtests in order to maintain quality code.

The test frameworks like JUnit, NUnit, and RSpec essentially give you a way to let the computer check the "printf" output (figuratively speaking) for you. You record your assumptions, rather than manually checking them each time, and you can let those assumptions grow upon each other. You record them separately, rather than interspersing the following infamous abomination:

#ifdef DEBUG
printf("foo=%s", foo);
#endif

Two Years of Investment

In 2002 I worked on a team of four J2EE developers on a life-critical (i.e., "You break it, someone may die") application. After two years, we had built some pretty sophisticated reports and heuristics that helped hospitals determine who was most likely to survive an organ transplant.

We had over 10,000 tests. They all ran in about 12 minutes.

Imagine: All aspects of a complex, life-critical, team-built application could be thoroughly checked in 12 minutes. We could (we did) bring in someone new, and essentially say "today we will make whatever changes we need, even mere hours before the next release, as long as we run all the tests and see a 100% pass-rate!"

Twelve minutes, and we knew we hadn't broken any of our careful, 8-(plus-)person-year investment.

Rise to the Occasion

If you're sitting alone in your basement writing a game to sell to a VC, you may not care if it's maintainable. By all means, please continue using only manual testing techniques to verify your app. I'm not being snarky: This may be the optimal win-win approach for you and the VC. (The team that eventually maintains your app will curse your name and throw darts at your picture, but do you care?)

On the other hand, if you're part of a team, writing mission-critical software for a large or complex domain, and it needs to get beyond version 1.0; then please: Make sure you can always test everything, and quickly. TDD is the best--the only--way the industry has invented so far for doing this.

Anything else would be unprofessional.

The Secret Sauce Recipe to Agile Coaching

Someone recently asked me how to build a successful career as an Agile Coach. I have to admit that if we're measuring by levels of income, I may not be the best person to ask. I've had a ton of experience, but I'm not good at marketing, or business administration, and thus just recently have been able to bring my rates up to what I believe my skills and experience are worth.

That's the "fail fast" clause: Those who are still reading are looking for more than just financial success.

Things that haven't worked, business-wise, include the website, and Google Ads. I don't think most clients will buy something as expensive as a three-day course without first exploring the word-of-mouth network. The website provides details, but I doubt it attracted clients. And Google Ads are great, if you have a commodity to sell. I was selling my skills, experience, and unique perspective; not my ability to mimic my mentors.

Things that have helped most: Colleagues (the network), perhaps blogging (the free taste of the ice cream), and certainly delivering presentations and workshops at conferences. Come to think of it, almost all the work I had after Agile 2009 came from my talk at Agile 2009, directly or indirectly. 2009 was a very rough year for a lot of us, but I'm very glad I didn't cancel that trip to Chicago.

I really do feel that I've established a strong reputation, and a fulfilling practice, so, yeah--by my standards--I'm successful. And perhaps there's something in my "secret sauce" recipe that you can adapt.

Cultivate Real Experience

Knowledge and experience are very important, but there's no way to rush experience. I've tried to strike a balance between "immersive" coaching (where I'm with the team most of the time) and brief training engagements. That immersive coaching has given me deeper experiences than I would otherwise have.

This implies that you have to be patient with your career. Having lived in San Francisco during the peak dot-COM years, I remember the results of foolish desire for instant wealth. You could take a few marketing courses and get a few certifications, and if you have a pleasant personality you may make bags of cash for a while. Eventually that will catch up with you, though, unless you...

Continue to Learn

Take training (traditional and otherwise) in a variety of areas. Follow what truly interests you, even beyond the edges of Agile and Lean (yes, the world is, not surprisingly, much MUCH bigger than what could possibly fit into a two-day certification course).

For example, I recently took a beginning sign-language class (at Elisabeth Hendrickson's Agilistry!). What does that have to do with Agile, you ask? Nothing, directly. I didn't expect to be able to say more than "Hello, world" after the course, but I was able to hold a simple conversation (about how much I enjoyed my dinner) in a noisy restaurant. The "Where Are Your Keys?" learning techniques used were "Fascinating!" (inside joke). Hmmm...could those be applied to Agile techniques?

I've also been looking into "Non-violent Communication" to help me be a better coach(, husband, son, citizen...). If I see a team having serious trouble with communication issues, or even cultural issues, I would feel comfortable recommending some external NVC coaching (though the puppets may have to stay in their box).

Look for the common, foundational lessons, then find your own voice when you teach these. I'm not quite in the "Do what you love, and the money will follow" camp, because I'd be on a beach in Maui co-authoring Larry Niven's next Known Space novel. But you do need to find an arrangement where you can "love what you do, at least for now."

Build Your Network

I've always tried to work with people who are smarter than me. A sincere, humble approach attracts knowledge. Get to know the people in the community, be friendly--and low-maintenance--around those who return the friendship, and give some extra space to those who respond with arrogance or fear.

Also, I try to work only with those whom I truly trust. Perhaps my luckiest attribute is a well-honed BS-O-Meter. I've worked with people who had only their own best interest in mind, but only when I was rather desperate, or only if I would have the chance to work with someone else who was brilliant.

If the gig seems a bit odd (e.g., they're hiring only "well-known, trusted Agile coaches" then they ask you to take a drug test), then weigh your options carefully. I once got asked to travel to an exotic far-away country; and I was very excited about it, until I Googled the place and discovered that it was horribly dangerous for "Westerners" to travel the same route to the office twice in the same car. No regrets about saying "No thanks!" to that one. I had nothing else lined up, but it only took a few weeks to find something else (in Hollywood, no less!)

If you're lucky--one of your brilliant new Agile friends will be a good marketer. That's how I found most of my independent work in the "Agile" world: I know people who are much better marketers than I am, and I sub out to them.

There will be those who want you to succeed (like me), and those who will see you as a threat. There's plenty of work to be done in this industry, so I've never understood the folks who see me as a threat! The successful folks are often too busy to handle all their clients, and they're happy to send you out and take a percentage. It's a triple win! I'd have to be stupid to do anything to break that trust.

You can take work with someone who doesn't trust you, but be cautious: They've either been burned (and they may impose all manner of weird restrictions on you), or they believe people aren't inherently trustworthy (usually because they, themselves, aren't). I have a hard time trusting people who don't trust me. I work that into the contract.

Ah, that's a gem: Find a lawyer who speaks your language, and who believes in writing win-win contracts. If the client sends you a boilerplate contract full of "client has these rights, contractor waives these rights" language, ask your lawyer to review it, and to rewrite portions. A contract is meant to be mutually beneficial. Yes, you may end up paying the lawyer to improve the client's boilerplate contract. It's happened to me on three separate occasions. In all three occasions, the client thanked me and accepted the edits at face value. My lawyer also thanked me. Hey, at least it was a tax deduction. (And, if you ever sub to those clients, you can thank me, too.)

Be Fearless

I quip that I've made a career out of career-limiting moves (CLM's). Be willing to speak your mind (er...politely, if possible). If something seems wrong-headed, look to Martin Fowler's advice: "You can change your organisation [Fowler's British spelling], or you can change your organisation!" Be willing to look for greener pastures; but also be aware that the grass always looks greener over there. Instead of running at the first sign of trouble, you may have to roll up your sleeves and dig in to a problem to find a solution. Since I'm throwing all my worst cliches at you, you have to "know when to walk away, and know when to run." Face it now: If you're going to show folks a better way to do something, you're going to be working in some dysfunctional environments (with people who will sometimes hate you).

Follow Your Compass

Decide to do business ethically, then stick to that even when it hurts. You get to decide, to some degree, what collection of ethical business practices you choose to follow. The important points here are that you think about how to conduct yourself, and that you consciously notice when those ethical dilemmas are happening.

Don't expect that touting your ethics will bring you more business. Look at Google. When they did leave China, people reacted with the full spectrum of opinions: To some it was heroic; to others it was self-serving; and to yet others it was too little, too late. You cannot control how people external to the situation will perceive your actions. Don't make the choice based on a prediction of the impact on your reputation, and you will thereby develop a reputation as an honest businessperson. Paradoxical, eh?

Agile Is as Agile Does

I'm re-reading this after it's been stewing for months in the drafts "folder." I notice that I don't recommend one Agile practice, methodology, or principle over another. Yet this still seems like the right recipe for a professional Agile consultant.

What do I mean by that? I would suggest that if you neglect one of these, you do so at your own peril. There are sure to be ingredients I'm missing, but these seem like the key ingredients to a satisfying career. What will you add to spice it up? Write to me and let me know.

Institutionalized Flexibility: An Impossible Dream?

My latest StickyMinds article on large-scale Agile transitions, and the impact of organizational culture, can be found here.

Half-point planning cards?! "Khan!!!!!!!!!!!!!!"

I was looking at a burn-up chart spreadsheet recently, and (for some weird reason) started trying to add up the numbers by hand (iPhone calculator, actually). My suspicions were correct: Excel was adding incorrectly.

"InconCEIVable!" I shouted. Microsoft, make a mistake of this magnitude in an app? If Excel couldn't add, the entire US economy would probably collapse. (First sentence is sarcastic; but the 2nd is said with a straight face and a nervous twitch.)

Turns out, I wasn't viewing digits to the right of the decimal place. No matter what Alan Cooper might say about that, this was clearly my own "user error." (More sarcasm, by the way.)

The team had 1/2 point estimates on stories here and there, and that was throwing off my interpretation of Excel's display of the data.

I decided to ask the team why they were using 1/2 points. After all, story points are unit-less, so we could just multiply all estimates by two, and my brain would not have had to grok Excel's annoying user interface.

I wasn't asking them to change their estimation methods, or their existing estimates. It was instead a rhetorical question. Thankfully, they had grown used to my peculiar goal-less, blameless way of asking questions (which I stole from James Shore, the Walking Root-Cause Analysis Machine, by the way), and someone easily replied...

"Because the deck of Planning Poker(c) cards contains 1/2 point playing cards, so we used them."

My face twisted, turning bright red, and then it happened... "COHN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"

:-) It's not really Mike Cohn's fault. Well, okay, maybe it is, but big deal. I'm not really upset with Mike; it just makes for good blog post fodder. In other words, I do think there's something odd about 1/2-point estimates, and maybe something we can learn here.

Disclaimer: Also, Mike is a friend of a good friend (Hi, Bob!), and I think I've even friended Mr. Cohn on facebook (Uh, when did "friend" become a verb, anyway?) He's also a very smart guy, and has loads of very good Agile books published, and has those slick Mountain Goat Software Planning Poker(c) cards. Please, Mike, don't take it personally.

One does not want to get on Cohn's naughty list: He'll chase you "round the Moons of Nibia, and round the Antares Maelstrom, and round perdition's flames..."

But please, let's throw out the 1/2-point cards.

I like to suggest this method as one way to start estimation: By thinking of the smallest, simplest--but whole--bit of deliverable software that you could imagine building, and giving that 1 story point. So a 1/2 pointer is a strangely broken story, using that algebra.

Another way of looking at it, a 1-pointer is something you could get done in a couple hours.

Now, yes, I just mentioned time (bad, bad, bad...), which has little to do with Story Points, but a 1 equaling approximately 2 hours does not imply that a 2 is approximately 4 hours. After all, the margin of error in the conversion increases as the scale increases, and ya gotta go to lunch sometime! A 2 is simply twice as complex as a 1.

Why do I care so? Because removing the 1/2 pointer simplifies the math. Sure, adding 1/2 points is easy. But not adding them up is easier, and the team could keep a running total in their heads while they plan, for example. Save your brain's electrical current for things that matter, like Star Trek trivia. Not Excel's ridiculous user interface...

Kanban is NOT King

I was chatting with a client the other day, and he asked about "replacing Scrum with Kanban."

I've heard even Lean or Agile evangelists say that Kanban is the next big Agile thing; that it replaces Scrum and XP. Unless I've thoroughly misinterpreted "kanban" I have to say this is a marketing ploy at best, and potentially a dangerous recommendation for your team. These folks are claiming they've found the Silver Bullet again?!

Kanban: A Powerful Technique

Kanban is a technique (or practice) taken from Lean manufacturing. Kanban can limit the queue size at each point in the process, and thus limits work-in-progress (WIP). For a software product or IT team, this is often done using a kanban-board, which looks similar to a Scrum or XP status board, but each column of the board is a state in a story's development lifecycle (e.g., ..., Elaboration, Needs Acceptance Criteria, Estimation, Automated Acceptance Tests, Development, Ready for Acceptance, Accepted, Ready for Deployment, ...). Each column is limited to a certain number of story cards (the WIP limit). This WIP limit reduces WIP and thus the wasteful "inventory" of incomplete functionality.

Kanban and Agile

At Agile 2009, I had the pleasure of attending Josh Kerievsky's talk on kanban, and he described how his team uses this technique to effectively supplant the XP "Planning Game" or Scrum planning meeting. Not the whole methodology, but just the planning. Oh, and iterations: Industrial Logic releases whenever a feature is ready, whether it's finished on Tuesday or Friday.

Using a Kanban board to allow the continuous flow of value is a technique that will work wonderfully for teams who are very good at prioritizing work, delivering fully completed and tested stories, and integrating and deploying on a very regular basis. If the product is constantly getting better and the users barely need to lift a finger or click a mouse button to receive those updates, what need for release plans or iterations?

But not all teams are ready to adopt such a technique, and there are products that do not call for such fluidity. So how could kanban be the one-size-fits-all, ultimate process?

It isn't.

If Not Kanban, then What?

Give up the hunt for the One True Agile Process. Stop looking for something that all your teams can follow to the letter, forever.

An actual Agile process needs to include mechanisms for process-improvement (from Lean) and constant vigilance towards finding constraints and improving throughput of value (from the Theory of Constraints). Continuous, incremental process improvement may lead your team to a kanban approach. Or, it may not.

So, you may not ever get to sit back, stop thinking, and simply enjoy the fruits of your efforts. Sorry. Fortunately, the benefits of a well-running Agile team are numerous, and apply to the organization and everyone on the team. What is required is frequent reflection on what is working and what is not, and careful consideration of what really needs changing. Learning about new--or newly tested--techniques is truly beneficial, but if you send your team after every Silver Bullet, they'll be expending energy needlessly.

Keep the high-bandwidth channels of communication open, and trust the team to know when something is wrong, and to give suggestions on how it can be fixed. Let one of them bring up kanban, and then discuss it.