Tag Archives: XP

Goldilocks Agile and Your Grandma

Goldilocks was very tired by this time, so she went upstairs to the bedroom. She lay down in the first bed, but it was too hard. Then she lay in the second bed, but it was too soft. Then she lay down in the third bed and it was just right. Goldilocks fell asleep.

As she was sleeping, the three bears came home.

Let’s say you were writing a letter to your grandma. Would you get out the user manual to the word processor you use? Perhaps spend a few hours going over how to create a Table of Authorities? Those manuals can be huge! Modern desktop word processors deliver hundreds or thousands of features, but 99% of people use 1% of them. You’re not writing a doctoral thesis; you’re just writing a letter to your grandma.

Does that mean we should throw word processors out the door? Never use them? Of course not, it just means that we separate the tool from what we are trying to accomplish.

Being a good grandkid, you decide to write a letter to your grandma every day. After a couple of weeks of this, one day your word processor breaks — you can’t use it any more. Do you stop writing letters to your grandma?

Probably not. Not if you love your grandma and have decided this is an important thing to do for her. You’ll just pick up another tool — ye old pencil and paper has been known to work very well for this — and write a letter to grandma. The tool is replaceable.

Let’s say you are in an auto accident. For the entire day, you’ve been sedated and didn’t get to write your grandma. Would you then say that your plan to write your grandma was bad, broken, or somehow defective?

Probably not. Not if you love your grandma and have decided this is an important thing to do for her. You’ll just start up again tomorrow.

You change jobs and find yourself with a new spouse and life. One long day, after spending time writing your grandma instead of doing other things, you ask the key question here: why are you spending all this time worrying about your grandma? Don’t you have better things to do? Seems like you are focusing entirely much on something that is not important.

At this point, you may decide that yes, you love your grandma, but it’s not effective spending an hour everyday writing her to let her know that. You could accomplish the same thing with a phone call every other day.

So what the hell does all this talk about grandmas have to do with Agile?

Just this: that we consistently confuse the tool, the ritual, and the principles.

An underlying principle of agile is to aggressively attack communication risk in order to tighten the feedback loop. The tool (one of many) is the conversation. The rituals include the story conversation, backlog sizing, or the daily stand-up.

So what if you’re in a team that’s distributed? Does that mean that stand-ups are dead? I don’t know, because I’m not you. Nobody else knows either. What I know is that the principle of aggressively attacking communication risk doesn’t go away simply because people live in different parts of the world, no more than you stopped loving your grandma because your word processor broke.

What if you’re in a team that’s writing exploratory code for a startup? Should you still use TDD? I don’t know, because I’m not you. Nobody else knows either. What I know is that the principle is that the later we test the poorer job we do of it, and that by knowing exactly what the code is supposed to do, we can use tests to make sure we are only writing code to do what is necessary. I also know the principle from the startup world is that 1-in-20 startups succeed, and that coding is a very, very, very small part of making people happy — even in products that require massive amounts of coding. My guess is that in unfunded startups with no traction you’re better off focusing on finding users and a market than in writing tight code, ’cause most of the time it doesn’t matter anyway. But that’s just a guess, and it’s just for a particular type of programming in a very particular kind of situation. The principle of startups being a long-shot doesn’t go away because of the principle of verifying code to make sure you only write what is necessary. You just need to have a conversation about principles to get that sorted out, not tools or rituals. Would you still write your grandma a letter everyday if she lost the ability to read? Probably not — but perhaps so. You have to figure it out.

What about if you’re in a marketing team without hard deadlines or a fixed product? What can you do to work better? The principle of a tight feedback loop doesn’t require a product. What do you think you’ll do today? Did you do it? That’s not just a stand-up, that’s a feedback loop. Maybe that’s all you need. Maybe the other rituals and tools don’t help you very much. Then don’t use them. Never give up your principles, but always be willing to ditch rituals or tools that aren’t working for you.

“But that’s not real Agile!” I can hear you say. If by a pre-ordained set of rituals, nope, it isn’t. But guess what? I favor Individuals and interactions over processes and tools, even if the processes and tools are “the real agile.” I’m funny like that.

A very smart man named Nietzsche once said “God is dead.” By that he wasn’t declaring himself an atheist: what he was saying was that any structure — tools and rituals — we put around the necessarily fuzzy concept of “God” is inherently broken. it’s self-contradictory at best, and actually harmful at worse. [Insert long rant about the harms and evils of organized religions from Nietzsche here.] In his eyes, it’s our inclination to keep trying to create structures and rituals out of the things we don’t understand that is itself the cause of much pain and suffering, not what people actually believe by themselves. We create our own prisons.

Agree or not with the old philosopher, what he said resonates in a lot more areas than just religion. Building technology products is a fuzzy and unsolved problem. We are always seeking to locally optimize for performance. Because of this, over and over again people discover the same principles at work: focus on customers, tight feedback loops beat loose feedback loops, visible work tracking encourages problem solving, etc. These folks write up these principles into various rituals: pair-programming, sprint planning, release planning, etc.

Other folks come along and learn the rituals, never realizing that the rituals are just instantiations of the principles. Perhaps they feel like they’re not expected to know. Perhaps their bosses think they’re unable of working on their own. Perhaps they are afraid of being in charge of their own destiny. I don’t know — but I know it is very sad to watch.

This is what we call “Cargo Cult Agile” — going through the motions hoping that, somehow, by magic the rituals will make things improve.

They never do.

I wish this was the end of things, but it gets worse: other folks come along and take these rituals and turn them into tools. The tools have all sorts of shiny widgets and do all kinds of neat data processing. There are seminars, workbooks, how-to guides, contests, and all sorts of other things to do with the tools.

We have started reading the word processor manual in order to write grandma’s letter. We are so far removed from our goal; instantiating some kind of regular practice to show our love for our grandma; that we may never find our way back. The tool becomes an end to itself. We are lost in the weeds, and we become the enemy of the thing we’re trying to help. We’ve become the bears instead of Goldilocks.

The thing is, it’s not like you don’t need tools. If you have 100 teams, you can’t visit them all at the same time. It is useful for many reasons to have a tool. It’s also not like you don’t need rituals: having something to train and get people started with is critical. But it’s not an all-in or all-out question: to phrase it like that is to be dishonest. A little bit of tools and rituals is incredibly awesome: it lets you do a zillion times as much. But too much or doing something simply because it’s on a list? It’ll kill performance faster than anything I know.

Just like Goldilocks, it’s up to you to experiment and try things until it is just right.

Then hope the bears never show up.

Share
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.

Extreme Pair Programming

People often ask me if I eat my own cooking. I thought this picture should prove that once and for all.

First, from the size of me you can obviously tell I’ve been eating somebody’s cooking. Secondly, as you can see, pair programming is alive and well here. My partner and I work long hours making sure the code is exactly right.

Daniel and sock monkey working while at the couch


I don’t want to get into any kind of personality dispute, but my partner has a tendency to lose interest and fall on the floor quite a bit. He’s obviously the brains of the operation — the strong silent type. I figure after all these years of being both a high-level consultant and a code monkey, it was time to join forces with my logical ally, sock monkey.

And you can’t beat the swank evening work area we have — couch, TV, music, munchies, and pillows. Sock monkey doesn’t talk a lot, but I can tell from the way he looks that he is really liking our coding crib.

Share
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.

Coaching Coaching Teams

If you work IT long enough, you go meta. That is, at some point you’re not doing the thing, you’re doing the thing about the thing.

Here’s an example I shared with my audience today about what happens when you coach teams that coach.

Many times, the coaching team is brought in under a Statement of Work, or SOW. The whole purpose of a SOW is to describe exactly what the team will be doing. And most every time you will have a contact that will prioritize work and define “done”. So you have a backlog, a budget, a Product Owner, and a highly-skilled team (after all, this is a coaching team — these guys know what the heck they’re doing!) What could go wrong?

I think people think that having a great team means having really smart people work on a clear list of things with somebody telling them when they’re “done enough” is all they need — but that’s not true. For instance, lots of startups who are funded by VCs do a lot of activity and yet get nothing done. Activity does not equal progress! You can have structural problems with your list of things to do that can’t be overcome by any degree of technology or smarts.

Activity does not equal value.

Share
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.