Monthly Archives: May 2011

The Test

I read somewhere that the greek playwright Sophocles was upset that during competitions for plays, the women were flashing their breasts, thereby influencing the judges.

I don’t know if that’s true or not, but as much as things change, most things remain the same.

Reading graffiti from ancient Pompeii online, I was reminded of this. “I defected here” was a popular thing to write, along with advice about securing sexual congress from various ladies about town.

We know for a fact that the Greeks and Romans both felt like previous generations were slack. Seems like no matter how far back you go you’ll find somebody saying “Dang kids today! Get off my lawn!”

Several times in this blog I’ve hit the thesis that today is different than those other times. I feel like the nature of the changes today begin to change in a fundamental way what it means to be human.

Looking at the IP laws the United States is prepared to pass, the re-enactment of the Patriot Act, Google indexing the universe, and the way companies are closely watching everything we do, I can’t help but feel like our relationship to government and our relationship to our fellow man is vastly different now than it was even 20 years ago.

Perhaps I’m just another in a long line of “Dang kids!” guys. Dunno. I haven’t even gotten into Ray Kurzweil and his belief that the idea of being human is changing. Or the anecdotal observations that youth are more and more afraid of making vocal phone calls or having in-person meetings with strangers.

When the philosophers talked about Freedom, Virtue, or the Social Contract, they were talking in a period where, in order for things to happen, you physically had to do stuff. Want to foment a rebellion? You had to go to the rebellion meeting. Want to change the government? You had to go vote. Want to change society? You had to physically go and be persuasive. Want to make money as an artist? You had to go and physically perform somewhere. Want to investigate a citizen to see if they might be committing a crime? You had to physically go out and watch them, dig through their trash, or talk to a judge.

Those days of physicality are drawing to a close. Those old things that required physical action and presence don’t work that way any more. It remains to be seen if we are able to take the old principles and apply them to the new world, or if we’re so wrapped up in governmental architectural cruft that we’re in for a dark, soulless future of being a mechanical drone in an overpowering state and commercial tyranny. You might think I exaggerate. I certainly hope so.

It’s like the previous 2500 years has been a period of reflection and study for mankind. What is the best society to have to advance the species? We’ve somehow muddled through with various solutions, but now we’re being presented with entirely new facts on the ground. Can we pivot?

We’ve been studying. Now comes the test. Good luck to us.

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.

Kanban Vs. Defect Hell

Do you have a huge pool of defects, bugs, and fixes waiting to work on? So much that you find it impossible to balance it with other project work?

I’ve heard three versions of the same story about how teams fixed this problem over the last year. I’m always cautious of over-generalization, but once our sample size gets to three it’s time to share.

The first part of the story goes like this: after releasing super-cool whiz-bang 4.0, the team is given a lot of fixes to make. For a while, everybody works on them, but management has other ideas: it’s time to work on super-cool whiz-bang 5.0, guys! Surely you can do this other stuff in the background.

So the “other stuff” is taken up by one or two guys, or it’s farmed off to India, or a couple of guys come in on the weekends for a bit to try to tidy it all up. There are a lot of plans for how it’s all taken care of.

Only it doesn’t work the was it was planned.

Instead, the load becomes bigger than the guys can handle. Not only stuff from 4.0 is in the list, there is still stuff from 3.0, 2.0, and 1.0 that hasn’t been fixed. The list gets huge.

Acting logically, you set up a triage. Things come into the list. You take a bit of time to estimate how big it is. Is it 1 day? 2 weeks? 3 months? Once you know roughly how big items are, then the business guys can make decisions about priorities. So the next thing to set up some kind of field for priorities, maybe low, medium, and high. Maybe forced ranking. Of course you use some kind of online system. After all, this is the 21st century! All important things must happen online somewhere. If it’s not online, it’s not important.

But wait a dang minute, here. Some things are mission-critical fixes, like when production tanks. You can’t keep working on fixing a report when the whole thing is broken. So you make a rule that when production tanks, everybody stops work and fixes it. Then they go back to whatever they were working on.

After a bit of time, you notice that not only is the list huge, it just keeps growing bigger and bigger — much faster than you could ever hope to catch. You’ve just entered Defect Hell, where a big dump-truck comes by once a day and piles an endless stream of crap on top of your head.

This is bad for everybody. For customers, things are broken and never get fixed. For other people in the company, they start losing faith in the ability of the team to fix problems quickly. For the team itself, they’re on a demoralizing death-march without end.

Bad. Bad. Bad. And if you’ve worked in a big organization at all, you’ve seen it.

In most places, the response to this problem is to simply keep over-complicating the plumbing. Perhaps you add another field to your list, like “severity”, or “impact”, or “will cause loss of customers” Maybe you create little automated email systems, flashing lights, or loud sirens. The hidden message is obvious: you dumb defect fixers need us to help kick you in the butt so that you’ll work faster.

That never works, so then, sadly, organizations will invent completely new ways of fixing the problem. Instead of complicating the existing system, another system will grow up alongside the first in order to “really once and for all fix the defect problem” Perhaps it has red flags, or little stuffed animals that explode. The safe money says it’s something that looks very serious and has a lot of complexity underneath. Maybe there’s a class or a little gold star you get to wear.

The problem here is outhouse process engineering, or the idea that a few smart guys can sit around with a team of super-users and pinpoint the exact nature of the defect-tracking system to a degree necessary in order to design a one-size-fits-all solution.

Yes, Six-Sigma Guys, I’m looking at you.

But you are by no means alone. Not at all. All of us in technology believe we can over-generalize and then over-apply those generalizations.

And we are most always wrong when we do it. Technology development, no matter how much we’d like it to be, just ain’t manufacturing. It’s R&D.

Here’s how the second part of the story is turning out for some folks:

Take a look at your data. How long does it take to fix a defect on average? For our story let’s say the answer is 25 days.

Throw out all the other complexity. We know on average it takes 25 days to fix any defect. Yes, it will vary by the individual case, but the variance is not important right now. Addressing it causes more problems than it solves.

Second, eliminate any sort of up-front sizing, prioritizing, or tool-based data nightmares. Simply make a list. Once again, the overhead creates more problems than it solves.

Third, create a kanban board with some steps you think might be common for all defects. On one side might be “start” on the other side “test” Don’t worry if it’s perfect, just throw it out there. If it doesn’t work for you, change it. Immediately. It’s your board, not anybody else’s. It doesn’t exist as a rule anywhere.

Fourth, pick a number that represents your maximum capacity, i.e., the amount of stuff you can work on at any one time. let’s say you’ve got a couple of people working on things and everybody decides that number is 3. But it could be 7. Just like the layout of your board, don’t spend a second over-engineering it. Pick something and then adapt. it’s important to get buy-in from your customers on this, but the critical thing is that you have to pick some number that everybody agrees on. This number represents work saturation — when you have 3 defects on the board, you’re loaded. You’re not allowed to add more on the left until one comes off the other end.

At this point, you have a simple question for people submitting things to the list: what would you like to have done in 25 days? They can flip for it, arm-wrestle, conduct decision-facilitation meetings — it doesn’t matter. From the team’s standpoint, just let them know. The business must self-organize to work through this.

There are a lot of objections to this setup, mostly because it ditches a lot of complexity that we just “know” is important. What about things that have to happen immediately? Well, make sure they get pulled next. What about things that finish early? The way kanban works is that once something is finished, the next item at the top is pulled. What about people trying to submit new feature requests disguised as bugs? That’s a common worry, but as it turns out it only happens a very small percentage of the time, maybe 2 or 3 percent of the total submissions. When the team finds one, let them escalate if you like. It’s not a big enough deal to add complexity to the system. Why are we giving up the step of sizing the effort before it goes in the list? Because teams that look at the data are finding they spend between 25-40 percent of their time simply sizing defects that may never get fixed. What about things that stay on the list and nobody ever puts it in the top three? Things on the list over six months get booted. If they’re important, somebody will put them back on the list. If not, they won’t.

Once all the objections are satisfied, what I’m hearing is that this is good for everybody. For the teams, it gives them some amount of sanity: they know what they are working on and have freedom to adapt and improve how they solve problems.

For the business partners, they start having to have real conversations about how much they can do and what needs to be done next, instead of just tagging everything “urgent” and throwing it in an electronic bucket somewhere. It also cuts a lot of the cruft out. The question of “what do we want done in 25 days” is a solid question with real impact. Checking little boxes on a form somewhere is just an exercise in frustration and futility.

Also the business starts to note that things are arriving as scheduled. Many things are done in much less than 25 days, but somehow even the outliers get pulled in under the limit. The business starts trusting the team more.

And, after a few months, as the team relaxes into a flow and starts self-optimizing, the 25-day lead time starts decreasing. It’s 22 days, then 18 days. As the lead time decreases, velocity through the system increases.

In all three stories I’ve heard, on huge messes it took perhaps a year or two to completely fix. You don’t clean up a problem that took years to accumulate in a week. But even within a few months, it was clear to everybody that things were on the right track. Every one of these guys were extremely happy — to the point of recommending kanban for just about everything in the world.

Which, of course, is the problem. The same “disease” that caused folks to create cumbersome tracking and allocation systems in an effort to help defect teams can also cause successful defect teams to create systems that may or may not work for other folks. Beware over-generalization and premature optimization.

So no, there’s no magic potion, but as they say in the news business, a pattern of three makes a trend, which makes it newsworthy. I am putting this in my arsenal of suggestions for any type of team that has a situation that looks like this, including program-level defect teams, where this defect hell thing can drive everybody crazy.

Whatever it’s actual value for your particular situation, it’s an nice tool to have sitting in the tool-chest.

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.

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.

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.

Applied Agile: Theory and Practice

“In theory, there is no difference between theory and practice. But, in practice, there is.” – Yogi Berra

Last week I got to hear Dean Leffingwell talk about “Scaled Agile,” the way that some Agile teams-of-teams are self-organizing into larger work efforts.

Dean was playing the role of “flamethrower consultant.” where you come in, announce that this what folks should be doing, that you will adapt and change or die, then logically take on all comers with a spirited defense of your vision of the future.

I love this role, as I have seen it executed several times to perfection. I’ve even attempted it myself from time to time, especially with skeptical audiences. Sometimes you persuade by hand-holding, sometimes you persuade by being a passionate informed advocate for a vision of the future that you’ve personally seen and want for your audience.

The problem here — and Dean doesn’t do this — is that it is easy to step over the line between “passionate informed advocate” and just “passionate advocate” — that we confuse passion for value. it’s a common thing to see in the process world. The passionate person blind to the realities of implementing theory has even given rise to the term “Agilista.” I’ve seen it among Scrum folks, Agile folks, RUP folks, CMMI folks, Six Sigma folks, and many others. When you have a hammer and you are passionate, everything in the world is a nail.

Of course, each of these things brings value to the table, and each can cause great harm. So how to sort it all out? Is it a yes-no question? Must we either do one thing or another? It’s very common to hear people say you have to choose, and that once you choose, you must do this new thing to the ultimate degree possible — that if it’s not done perfectly, all will collapse.

Continue reading

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.