They call them comfort zones for a reason, it’s because they’re comfortable.

I don’t like being in my comfort zone because when I get comfortable I fail to recognize when a change is necessary. I start framing uncomfortable change as impractical, then concoct seemingly logical arguments to avoid it. Trouble is, some of these arguments aren’t logical at all. They’re just my way of avoiding the pain that comes with taking the chance.

Some may think that becoming an agile development team is impractical; that the approach won’t work for them, that it’s too big a risk or it’ll be all pain and no gain. Where agile becomes impractical, it’ll be watered down or avoided.

As an example, suppose someone suggests XP as a model for an agile transition. Amoung other things, XP brings with it a series of primary practices. If XP doesn’t fit into your comfort zone, there’s any number of practical reasons for why you might avoid any – or all – of these practices (listed in bold).

Sit Together… “We’ll have to check with corporate on that. I’m not sure they’ll see taking down cubicles and moving people around as practical. But we’ll definitely look into it.”

Whole Team… “This is a good idea but it might not be practical for us. It’s hard for us to synchronize our hardware and software organizations because of different resourcing issues, but it’s certainly something to consider if we can.”

Informative Workspace… “Sure. I’m not sure it’s practical for us to decorate the halls with all the project scheduling, burndown charts and collateral, but we can see if we can get a few more whiteboards for people to have in their cubicles. Or maybe we can add a sharepoint.”

Energized Work… “For sure. It’s very practical for us to encourage a work/life balance here. That’s why we ignore overtime by limiting the number of hours people can enter in their timesheet.”

Pair Programming… “I don’t think pairing is practical for us because the drop in productivity is something we can’t absorb right now.”

User Stories… “I like the idea of user stories in theory. But SoCs are very complicated so I don’t think that type of documentation is practical. Maybe for simpler designs, but probably not for ours.”

Weekly Cycle… “It would definitely be great for us to come to weekly milestones where our RTL is functional and verified, but a lot of the features we build take far longer than a week so I’m not sure a weekly cycle is practical for us.”

Quarterly Cycle… “A quarterly cycle would be really nice for our customers because we could potentially ship product earlier. But our back-end takes a long time to run so this isn’t practical because of the tools.”

Slack… “It’s not practical for us to build slack into our schedule because there’s a lot of pressure on us to get this SoC out the door.”

Ten-Minute Build… “Wouldn’t it be great to have 10 minute regressions! Too bad our tests take much longer than that. I can see this being practical for the software folks but not for us.”

Test-First Programming… “we need to maintain a proper checks-and-balances division between design and verification because if we tape out an ASIC with a bug, we’re in big trouble. People testing their own code is not practical for us.”

Incremental Design… “This is another I can see working for the software people because it’s so easy for them to split up their design and redeploy it whenever they want. It’s not practical for us though because we can’t ship half an ASIC.”

Continuous Integration… “This would really help us keep bugs out of our repository but building a continuous integration server isn’t practical for us because we don’t have the resources to dedicate to it.”

None of these “practical” arguments hold water, yet for some they’ll be practical enough to decide the risk isn’t worth it, that it’s easier to avoid the pain of change (and any potential success of course) and settle back into their comfort zone.

I’d like to suggest that before we accept “practical” (or encourage it for that matter) we remember that when it comes to agile hardware it’s early. Very early! We’re talking infancy. We are tiny little babies with everything to learn and no idea of what’s practical. If there ever was a time to shoot for the ideal, this is it. Experiment with every tool in the toolbox and see what happens without compromise or concern for what’s practical.

And sure… years of experience from now, once we know more and we’ve given agile development a serious shot, then maybe we can start making decisions about what’s practical. But not until then.

Considering where we are today though, now is definitely not the time to be practical.

-neil