Tag Archives: developer

Agile Humor – There Goes That Damn Lightbulb Again…

How many CTO’s does it take to change a lightbulb?

Two. One to screw in a new lightbulb and the other to retroactively declare it a planned outage.

How many help desk engineers does it take to change a lightbulb?

Three. One to tell you they can’t help you unless you can tell them the wattage and serial number of the lightbulb, one to bump it up to the supervisor, and one to inform you that they stopped supporting incandescent on the 30th.

How many web designers does it take to change a lightbulb?

One, I guess. But let me ask you, are we married to that lightbulb concept?

How many developers does it take to change a lightbulb?

None. They closed out the ticket, the lightbulb worked just fine in their fixture.

A Marketer’s Guide to Agile Development – Does Agile Have Time for Research?

Rapid development calls for rapid decision-making. Agile practitioners sometimes make the mistake of assuming that an Agile environment doesn’t have any spare time built in for research to inform those decisions. It’s not so. You’re actually more at risk for wasting time when you don’t research.

Research can take many forms, and a lot of insight can be gained very quickly.

Research is for grownups.

A big part of Agile culture is empowerment and self-determination. But developing software costs real money. The hard truth is that not every cool-sounding idea your brain spawns deserves to come to fruition. The ideas that should be developed are ones that research shows will advance your organization’s business goals – you know, the reason they pay you to come to work.

Research should be proactive.

It doesn’t matter what kind of software development environment you’re in. Which is smarter – a survey to find out if the Ultimate Extremely Cool Tool would solve a problem and/or delight users? Or a survey to find out why users won’t use the Ultimate Extremely Cool Tool your company spent four months developing? (If you’re unsure which one of these is smarter, you might want to take a personal day and read a couple of months worth of Dilbert comics to gain some clarity.)

Objectivity is a must.

Research should be done by people who don’t have as much skin in the game as the people writing the software. It needn’t – and indeed shouldn’t – be done by the development team itself, but by research professionals on staff or outsourced. Why? The same reason they don’t let judges preside over cases where their kid is a defendant.

Testing is a crucial form of research.

Don’t skip test-driven research – the lack of it could come back to bite you in the…area where you don’t want to be bitten. I wrote more about this recently. But don’t just take my word for it. Alberto Lumbreras has written some great blog posts about the subject, here. You know the old adage: “Act in haste, repent in Sprints 15 and 16.”

A Marketer’s Guide to Agile Development – I’ll Take Agile for $1,000, Alex…

A: 8-track tapes; sleeves on wedding gowns; heavy up-front requirements.
Q: What is nostalgia?

A: Data storage costs; mortgage industry headcount; development project documentation.
Q: What is downsizing?

A: Two face cards; Oliver and Hardy; driver/observer programming team.
Q: What is a pair?

A: Roy Rodgers; Dallas gridiron star; irresponsible coder.
Q: What is a cowboy?

A: Multi-trillion-dollar-national; post-ninety-day-unpaid bad; I’ll-go-back-and-clean-it-up-someday technical
Q: What is debt?

A Marketer’s Guide to Agile Development – Embracing the F Word

Marketers don’t use the F word very often. It makes them peevish and erodes their self-esteem.

No, no, no, I don’t mean that F word. Marketers use that one a lot. Like omigod, like verbal hot sauce they sprinkle over everything – more frequently than “and” or “the”. Oh wait, that’s me. But I digress.

I’m talking about F for failure. Failure is a dirty word in some organizations. You’ve all heard some of those old canards at some point in your careers:

“Failure is not an option.”

“I don’t want to hear about any problems, only the solutions.”

“The success of this project is critical to our ________ (financial goals, department’s ability to get budget dollars next year, new product launch, long-term strategy, next bonus payout, continued employment, yadda, yadda, yadda.)

“I can’t go into that conference room and tell my _______ (team, boss, department head, rival department head whose project was deep-sixed for this one, Exec VP, C-Level, board, shareholders, blah, blah, blah) that _________ (it’s too buggy to go to market by the launch date, we worked feverishly on a flawed assumption, the strategy was sound but we fell down on execution, the consultants recommended scrapping the project and starting anew, yak, yak, yak.)

“We’ve spent too much ___________ (money, time, resources, political capital, wah, wah, wah.) on this project to cut bait now.”

Failure is part of nature and part of life, but you’d never know it in some of these misguidedly rah-rah organizations that banish anything that doesn’t smell like success. People in these business environments learn quickly what’s required for self-preservation. They won’t say out loud that they tried something that didn’t work. Why is that?

Fear.  They’re afraid they’ll look stupid among their colleagues, and that will make them vulnerable. Ironically, they end up throwing stupid money at doomed efforts just to avoid looking stupid.

So they deliver an app that’s already obsolete by its release date instead of regrouping and redirecting the money and resources toward the app the company really needs.

Allowing people to admit failure is critical to success. It isn’t an excuse to be lazy, to embark on half-baked or vanity initiatives, to avoid accountability. The person in charge of a failed project is accountable to figure out what went wrong and how the business can use that learning to move on to better things. One never sets out to fail. In fact, if you have nothing but string after string of failures without a winner every so often, there’s a systemic problem. Maybe it’s a resource issue, maybe it’s politics, maybe overall company goals need some realignment. But if you’re never failing, you may be playing it too safe. There’s an old adage in auto racing “If you’re not crashing once in a while, you’re not racing hard enough.”

Some thoughts on avoiding this no-failure-allowed trap:

Be realistic about your odds of success – most businesses don’t have enough time or people to bring everything they want to do to fruition. Working smarter has its limits. When you can only push out a finite amount of product, every initiative becomes critically important – and it’s an easy mistake to mandate that each has to be a winner. That’s just not reality. Some will be black truffles, some will be turds. Making your people call the turds truffles… well, you don’t really want to go there, do you?

An Agile development environment will help you. Its iterative deliverables can help you discover that you laid an egg faster than other development methods – allowing you to rethink, retool, or move on.

Test. Test. Test. You engaged in initiatives on the hypothesis that completing them would improve some business results. Robust and disciplined A/B or multivariate testing will show quickly if your hypothesis is true or false. User testing (real users – not your lunch buddies) will tell you if you got the architecture and design right. Of course, you determined what the success metrics would be before the initiative began, right? Right? (tap, tap – hello, is this thing on?). And you would never be that guy who agrees on the success metrics, and when the test doesn’t support his hypothesis, attempts to discredit the test, right? (tap, tap, tap…)

If the testing shows that the initiative makes things worse and not better, then yes, you may have to throw out some completed work. Yes, it means your idea wasn’t a clear winner. Yes, it means that your development team may not get the validation of seeing their code come to life in production. We’re all grown-ups. If we didn’t have to make tough choices, it wouldn’t be called work and they wouldn’t have to pay us. Okay then. Let’s learn from this and try another idea.

So you didn’t find the black truffle this time. The truffles are out there. And you won’t find them until you pick another tree.

A Marketer’s Guide to Agile Development – I Pledge Non-Allegiance

Sign the Oath of Non-Allegiance!
Oath of Non-Allegiance

“I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.”

Love, love, love this oath – from our friend Alistair Cockburn. Why is it needed? To remind turf warriors and methodology zealots that Us Versus Them intolerance robs the business of progress. The Oath has lots of uses, because projects unfortunately tend to spawn multiple factions: Continue reading A Marketer’s Guide to Agile Development – I Pledge Non-Allegiance

A Marketer’s Guide to Agile Development – Backlog Bingo

My own requests to get on sprint backlogs are often analytical – that whole measuring success thing, for a variety of reasons: (1) enhanced analytics the business didn’t realize would be needed when a feature or function originally went live (2) basic tagging that should have been included when a feature or function went live but didn’t make it into the original sprint(3) tag modifications made necessary by site changes (4) repairs to tags that worked in test but for some reason broke in production.

Save your comments, I know Scenario (4) shouldn’t happen. Neither should petroleum-coated pelicans, decaf espresso or the Heidi & Spencer union, but hey, what can I tell ya?

Delivering working software is priority numero uno in an Agile development environment. Now analytical tagging is software, but it’s not the kind you can point to on a screen when your buddies are over and say “See that page? That was me.” So how will you get it prioritized over the other coding projects that result in something you can screenshot and put into a slide presentation? Or a developer’s resume? Or a fellow marketer’s resume?

Marketing has to lead the way in fostering a corporate culture that values the measurement of success as an integral and non-removable part of any website initiative. A healthy Agile environment begets continuous improvement – and continuous improvement requires baselines and monitoring to keep score.

If coding that enables measurement isn’t considered valuable software, then your analytical requests simply may not make it. Sexier coding tasks – the ones you can see, hear, click, monetize – will rise to the top of the sprint list – and your analytics request will go to shady, grassy section of the backlog to live with Jesus and Ronnie James Dio.

Tracking the success of what you build is not an enhancement or a feature or an add-on. It’s what marketers and developers need so they will know what to do next to dynamically enhance performance. And what could be sexier than enhanced performance?

A Marketer’s Guide to Agile Development – Hello Cleveland! If You Can’t See Them, Is It Still Agile?

The scrum or stand-up meeting is a major part of Agile methodology.  Ideally, everyone works in the same area (called co-location), and talking in person is considered the most effective way to work.  In fact, face-to-face communication is considered so important to the effectiveness of the methodology, it has its own line in the Agile Manifesto: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

But there’s a wrinkle – it’s estimated that over 25% of American workers now telecommute, and that’s increasing.  Others work in offices located states or even oceans away from their co-workers.   How does this new state of affairs affect the future of Agile methodology?

Well, the simple answer is that it makes it harder and potentially less effective.   The line actually refers to communication between the developers themselves, but business owners, SME’s, and other key players in a project are affected as well.  What are some ways around that?  

CONFERENCE CALLS –  If the scrum is truly 10-15 minutes long like it’s supposed to be, it isn’t so awful if it’s a conference call.   But the problem with conference calls is that they take sometimes take 10-15 minutes to start.   The conference bridge has a glitch that makes everyone sound like they’re speaking from the Field of Dreams cornfield (oddly, sometimes with the same dialogue).  The scrum master says “Who just joined?” eight times after eight beeps because we all know only rubes say their name when the Webex robo-facilitator asks you to.    You all wait a few minutes for the lead developer who it turns out is taking a personal day.  Her boss would have told you that, if he hadn’t overslept the 8am EST call because it’s 5am in Seattle and he got home from the Muse concert at 2:30.  Then you have to ask Monty the mouth-breather to put it on mute, IM Jerry to quit answering emails because his keyboard tapping is making the microphone cut out the first two words of everyone’s sentences, ask Sandy to mute as well because you just heard the last call for two US Airways flights as well as her Starbucks order….that’s the bad news.  The good news is that on a conference call, you can’t see the developers’ eye-rolling when the business people speak.


Ha!   Teleconferencing is a cruel hoax.   Remember how disappointed you felt when you were 15 and found out Bill Gates wouldn’t really send you $149 for forwarding that Microsoft email?   I feel that way every time someone suggests a teleconference.  People say it’s real, but no one you know has ever had it pay off.    Some still try.  This usually requires plugging, unplugging, replugging, stabbing the f8 key repeatedly, giving up and locating one of the two people in the whole company who know how to set up teleconference, the guy comes in and performs the A/V equivalent of alchemy and then tells them they just had to hit f8.  By that time, the office you’re trying to remote with has dispersed and the next meeting group is knocking on the window because they need the conference room.

Here are links to a couple of decent articles about the effect on Agile process when teams can’t be in the same place at the same time.  The consensus is that Agile can be done when co-workers aren’t together, but it’s just not quite as good as when they can smell each other’s coffee.  Or Red Bull.



A Marketer’s Guide to Agile Development – The Balance of Power Part 1

An old boss of mine used to have a small wooden plaque on his desk.   It said “JDI” – “Just Do It”.   Not in the Nike “you go, girl”, self-empowerment sense.    More in the “just because I’ve finished talking doesn’t mean you get a turn now” sense.   Anything short of “right away!” and he would silently nudge the plaque in your direction.   Good times, good times.   Marrying up that imperious client attitude up with Agile development would probably be a big mistake.   But here goes: Agile –  The Motion Picture”

Hotshot Marketer  (played by Alec Baldwin):   What up dawg?  Ding dong ding dong, yo!

Harried Business Analyst (played by Ben Stiller):  Dude, nobody talks like that anymore.   And you’re from, like, Duluth, aren’t you?   Anyway, what are we building today?

Hotshot Marketer:   “So here’s the logo – it’s going to go here, and you’re gonna make it blink and jump out of the frame and turn into rocket fire and then Yoda from Star Wars.  Or maybe smoke then Harry Potter.  Or those Top Gear guys – anyway, we’re still hammering out the talent rights, I’ll get back to you on that.    And be sure to code it in Flash, just to stick it to Steve Jobs on that iPad thing – you gotta get it done, too, ‘cause I already bought the media – and…

Harried Business Analyst:    Well, that’s a risk, we sort of have to nail down who’s jumping out of the frame if we’re going to finish…

Helpful Developer (played by Paul Rudd):   Hey, I have a suggestion – if we change just a few things, move this over here, let us handle the coding, we could gain the flexibility of…

Hotshot Marketer:   “Yeah, thanks bro, I’m totally not hearing that.  I want what I want.   Whose page?   My page.  Who’s the customer?  I’m the customer, right?   Whoa – I’m late for the links.   I got your requirements right here on this napkin – ignore the Hooters logo, of course.  Just do it, babe.”