Look. This SOPA/PIPA thing.

I used to do programming work for an industrial/grunge record label. They actually had lawyers dedicated to suing bootleg T-shirt vendors at concert venues… it was worth it.

Copyright infringement is already illegal (criminally) and actionable (civilly). SOPA/PIPA is just an attempt by the big media companies to offload their enforcement costs on you and me. Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.

SOPA/PIPA is kind of like making it illegal to buy blank T-shirts because you might put someone else’s trademarked or copyrighted image on them. Which is awesome if you’re the one with a “famous” image or brand, but sucks if you just want to publicize your mom-and-pop business or your kid’s band.

So since when is it your job and my job to make sure Disney and Comcast’s copyrights can’t possibly be infringed upon? Why the hell isn’t it their job?

The inevitable war story, because I do that:

I used to do programming work for an industrial/grunge record label. (Brush with fame: I knew Marilyn Manson’s accountant.) They actually had lawyers dedicated to suing bootleg T-shirt vendors at concert venues. It was an expensive pain in the ass, but they figured it was a cost of doing business and protecting the brand.

It wasn’t perfect, because you can’t catch and sue everyone, but it worked well enough and the label was quite profitable.

It’s not good enough for Disney though. They think their right to guaranteed profit trumps your right to run a web server. That’s the issue.

That's what my game is

My idol Naomi Dunford suggested that my fans and readers might not be clear on what I do and why it might matter to them. This makes me sad, because I want to be known for more than throwing rhetorical bombs on Twitter.

Don’t get me wrong, that guy deserved the slam on Twitter, seriously, but slamming isn’t my game. It’s not my whole game anyway.

So let me go answer some of Naomi’s questions here. Go ahead and fire back in the comments.

Q. What’s your game? What do you do?

A. Short answer: I take software projects that suck and make them not suck.

Real answer: Look, life is really hard. I’ve been working on one thing and the next, in about fifty organizations over the last fifteen years, and the same freakin’ things come up over and over again:

  • Everyone’s tired.
  • Everyone’s afraid for their job.
  • Everyone’s wasting time spinning wheels on stuff that doesn’t work.
  • Every software project is running late and pissing off the boss.
  • Every boss feels betrayed.
  • Every developer feels oppressed.
  • Software projects suck.

And I’m going huh. That shouldn’t be happening. I mean, this is ostensibly a “first world” country with tons of resources and lots of educated people who can do stuff. Software itself is complicated, but it shouldn’t be as hard as everyone is making it. Very often, we really do know how to make it better but for any of a thousand reasons doing the right thing seems to be beyond us.

And that’s my calling. It’s really quite simple. I take the things that are already actually known about making software projects go well and apply them to real life, so regular people can solve problems, live better, and maintain a certain level of sanity at work.

Q. Why do you do it? Do you love it, or do you just have one of those creepy knacks?

A. That’s a weird question, Naomi.

I happen to love having knacks for certain things. Is that creepy?

Also, I am in it for the love and the hugs. It’s so cool when I can help decrease the project suck factor so much they’re sad to see me go.

Q. Who are your customers? What kind of people would need or want what you offer?

A. If you manage, pay for, specify, benefit from, or try to oversee a software development project, and it sucks, we should totally talk.

Things that make you much more likely to benefit from working with me:

  • sense of adventure
  • willingness to be surprised
  • reasonable level of vulnerability

Things that make it very unlikely that you will benefit from working with me:

  • rather be comfortable than successful
  • like to be in control
  • quick to make up your mind about things
  • quite certain it’s not you

Not to go all New-Agey on you here, but Making Software Projects Not Suck is rarely just a matter of plugging away at code. I’ve had a few of those, but most of the time the problems are way deeper than that. Sometimes the things that Make Your Project Suck are the exact same things you love about the project: drama! action! involvement! Then you have to choose: would you rather have the drama or the success? Because having both is not an option.

I’ve even dealt with projects that, when you cut through the crap, are supposed to suck. Like one in which the lead developer was under the impression his job would end when the project did. Or one in which the project manager seriously couldn’t figure out how to live without the angst and panic. And there was the time–I’m not real sure about this one–but there was this kind of indentured-programmer setup and the boss kind of liked it that way. It was power.

So number one, the thing that totally stands out as the most important distinction, is that you have to want your project to not suck and you have to be willing to change. Okay, that’s actually two things.

Does that sound like therapy?

I guess it does. I’ve got people you can work with if what you want is real head-shrinking. That’s not my bag.

What is my bag is showing you the truth. Things like:

  • control isn’t progress
  • action isn’t accomplishment
  • progress isn’t a deliverable

If you’re up for that kind of challenge, let’s do it. If that scares you, then we should definitely do it. Buck up.

Q. What’s your marketing USP? Why should I buy from you instead of the other losers?

A. Losers? There are no losers in this.

But here are a few things that make my services unique:

  1. I help you get started using Agile practices (and feeling the Agile principles) at the tactical level. You can try one thing at a time–such as starting with pair programming–without having to commit to some big revolutionary cultural shift. It’s fine to experiment first.
  2. I’m attracted to, and effective with, the high-stress projects that make people crazy. I tone down the hype and make it easy to keep working  instead of panicking. I’m anti-drama.
  3. Unlike a lot of shops that offer “Agile coaching,” you can see my terms and fees up front, like here and here. I just think it would be weird to hide things like that in the sales cycle when so much of what I do is make your practices transparent. I’m asking you to open your shop and your mind. The least I can do is be upfront about my side of the exchange.
  4. I still write software myself most days. It’s not theory.
  5. There is homemade Indian food on Fridays, even though some purists object to the hot reddish-orange cast of my special aloogobi recipe. (It’s traditionally a yellow curry, and mild.)

Q. What’s next for you? What’s the big plan?

A. So glad you asked! I’m doing two things to make Project Desuckification more accessible even when I’m not.

The first thing

The first thing is that I’m documenting my processes a lot more diligently than I used to.

For example: before, I’d ask a few dozen questions before doing anything else with a new client. Now I write down a few dozen questions before asking. In a very recent meeting, I planned the whole interview, then diverged from the plan to follow some tangents, then got back to the plan so I could finish (almost) all of the questions.

That accomplished two things:

  1. I remembered to ask about some less-immediately obvious things that would have flown out of my head in the give and take of the conversation.
  2. I have a handy list as a jumping-off point for the next such initial meeting.

I’ll refine and augment the list in using it a few more times on successive projects. Before long it will be easy to turn that set of questions into a checklist, an article, a NOTACON presentation, or maybe even a Prfessor course.

So it goes with the other artifacts of Desucking: the emails that explain pair programming, my notes from debriefings, a particularly amusing burndown chart, bits of open source code. They’re resources for the next gig, but they’re also inputs for the next consolidated offering. Their specificity is what makes them so valuable; their universality is what makes them so useful.

At this point you’re probably wondering how I get away with ripping off all this stuff from clients who pay me to keep things private. I don’t do that! In fact, depending on the assignment, I ask them to join in my famous “Disclosure Agreement.” It protects their proprietary and confidential information, but makes clear that I can talk, blog, and publish everything else about the project. It’s like compost for desucking: useless where it came from, but invaluable for the next cycle.

The other thing

The other thing is simple timeline planning. Sure, I’m thrilled to death to help when your project already sucks. That’s my Thing. But unfortunately, projects reach the ultimate sucking point at unpredictable times, and there’s only one of me. They tend to pile up, and I have to turn someone down, and then their project still sucks.

So now I’m developing ways to make your project not suck before it even starts to suck. They’re principles and techniques that work at any time, are easy to implement, don’t require a lot of overhead, and make everyone more productive with less hassle.

That way I can plan ahead a little, and the potential clients can relax if I’m not right on the spot when things start to sink.

Most importantly and immediately, I’m developing some resources to help your team learn pair programming relatively quickly and get the most benefit from it. So far I’ve found that pairing is a very low-cost and simple way to get started with the Agile concept.

My research question: The managers who resist pair programming the most are the ones who just can’t wrap their heads around Agility. True or false?


There it is. That’s my game. Wanna play? It’s easy (and free) to start. Just dive into the comments, and if my way intrigues you, take a nice swim in the “Contrarian Guide to Making Software Projects Not Suck,” even though it’s an opt-in link. Because the weekly emails are even more fun than what’s on the blog.

From today's memo pile

We’re not a Scrum shop. We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do. Here’s how to make the Scrum meetings Not Suck.

To: Everyone
From: Mark

A note on process…

…as well as a reminder of today’s Weekly Scrum meeting. I’m notifying everyone (including executives and non-technical managers) because you’re all invited to join today’s meeting as chickens, and because you might be interested in the process summary. If this stuff bores you, sorry about that. [And something about how to turn off the notifications.]

First off, the Scrum will start at 5pm. If other “pigs” will be in the office I will join you, so let me know. But we will also be on Skype (where I’m MarkWSchumann). Other pigs are: [names elided]

If you care to join the Scrum as a chicken (i.e., involved but not committed), that’s fine–let me know and we’ll include you.

End of announcement. Beginning of process talk.

For those newly tuning in or just standing by, the Scrum meeting is really really simple. Everyone in turn answers Three Questions:

  1. What did you get done since the last Scrum meeting?
  2. What do you plan to do before the next Scrum meeting?
  3. What obstacles do you have?

I’m gonna say something here.

The answers to these questions are often a variation on “I screwed up, and this is how I screwed up, and this is how it’s affecting my team.” Let me be clear about one thing: The process doesn’t work if you can’t be totally honest. Okay, two things: People aren’t gonna be totally honest next week if you make them regret this week’s honesty.

So if Alice admits she caused a blockage because she bit off more than she could chew, no fair scolding her about the same exact thing on Monday. She already spilled her guts. Don’t make her do it again. (She’ll wonder why she bothered to suffer that experience the first time if it didn’t count.) And if Bob tells you he botched some code and has to do it all over again, appreciate the fact that he said so. Don’t make it all dramatic. Just help him fix it and move on.

Got it?

And the Scrum should go really quickly–maybe about three minutes per pig I guess. And zero minutes per chicken, because chickens don’t get to talk in Scrum meetings. If an obstacle can’t be resolved instantly, we take it out of the meeting to talk about later.

This is not really a Scrum shop.

That’s been implicit all along, but now I’m actually saying it.

Scrum has burndown charts and a different kind of backlog system and an explicit kind of connection to management, among other things. We don’t need those. I think.

We’re more of a Kanban shop that has Scrum-like meetings. Which a lot of teams do.

I’m gonna draw everyone’s attention to the online Kanban system we have at AgileZen: [url elided] If you don’t have access to this, you should. I don’t care if you’re technically on the dev team or not–there is really one team here, and in a face-to-face workplace the Kanban would be an actual physical board placed where everyone can see it.

If you want to know why the heck stuff isn’t getting done, this would be the first place to look. That’s the transparency thing.

Very briefly, each “card” is supposed to move from the (sometimes hidden) Backlog column at way left, through the various columns, and into the (sometimes hidden) Archive column at way right. Cards edged in green are Ready to be pulled to the right. Cards edged in red are Blocked and need help.

I encourage everyone on the dev team to watch for Blocked cards throughout the board. You can often help with one that’s not currently in your own primary area of work.

Why Your Project Is Late

Why is your project behind schedule? Have you considered that maybe it’s because you want it to be?

I talked to this guy about six months ago whose independent software company had five or six really well conceptualized vertical market applications.

None of them were actually done yet. Some were at that classic 80% completion mark. And he’d been at this thing for five whole years!

Continue reading “Why Your Project Is Late”

When the project DOESN'T suck!

Over on LinkedIn, I recently asked for experiences and war stories about the personal impact of “projects that suck.”

There’s this one response, which was sent to me privately so I won’t quote it, but the gist of it was to say projects that succeed can be even worse than those that fail. Because when the project fails, you might get fired (or quit) and then at least start over somewhere else. But if a difficult project succeeds, your reward is that you get another difficult project.

And it’s not like there are many significant projects that are not difficult. So doing really good work and persevering in the face of one crazy hassle after another just means you get hassled more. No wonder people quit this field! The guy who wrote this to me did exactly that. He’s not in software development anymore.

Funny, I never thought of it that way, but he’s right. Who’s really happy in software development? I’ve been talking about the projects that fail (or are on their way to failure), but the ones that actually succeed aren’t always so great to work on either.

All I’m saying is… we have to do better than that. You spend too darned much time at work to have it be miserable in any way that can be avoided. Sure, there are jobs that might inherently be more fun or less fun (depending on your taste) than hacking code, but it shouldn’t be the kind of job a properly skilled person dreads showing up for every day. And yet.

I believe it’s important to arrange work environments so skilled and motivated people can get stuff done without hurting themselves and without burning out. How crazy is that?

Why I preach it

The other day, I gave a presentation on “Three Ways to Get Your Web Development Project Back on Track.” It’s the same overall concept as what you typically read on this blog, in a little different packaging. For one thing, they asked me to avoid using the word “sucks” too much. 🙂

I got carried away a little, maybe, with the motivation part. Why does it matter, really, if a project “sucks” or not? Why do we bother making projects successful and work life better?

It’s not profit

…because money is actually fake, just a proxy for value. The important things are whatever solves problems, alleviates pain, promotes health, and makes people happy. We push money around ostensibly to keep track of everyone’s contributions, but sometimes that connection is tenuous. The key thing is to Make Stuff Go Better. I really believe this.

What suckage costs

Software and Web projects can suck for any number of reasons (although I speak of eight main ones), but the suckage takes this kind of human toll:

  • Illness and exhaustion
  • Broken relationships
  • Diminished skills and enthusiasm

I talked about this part with some intensity. One evaluation read in part: “Good speaker… but sounds like the pastor at a really liberal church.” All right, so I got enthusiastic about the motivation part. I still think it’s a big deal.

So my point…

…and I do have one, is to consider the bigger picture. Optimize your numbers, sure, but try to work sustainably, work on the right things, and do it in a way that respects people’s needs.

Because that’s all you really have anyway.

Rules for Radicals and Agilists

I was quite interested in Peter DeYoe’s recent blog post comparing Agile development to the P90X fitness program he just started. Riffing off the slogan “Decide, Commit, and Succeed,” DeYoe winds up with

Decide if Agile is right for your organization. Commit to the principles of Agile and deny your urge to fall back on old habits. And if you make it to the third or fourth sprint, a new, healthier paradigm for software development fitness will emerge and lead you to Success.

I like it! But I have a different model for Agile adoption, which is highly influenced by the life example of my darling Drsweetie.

Continue reading “Rules for Radicals and Agilists”

The biggest mistakes in small business

Two big mistakes in small business: 1) lack of clarity on who you serve and why; 2) undertaking big current projects for questionable future needs.

Melinda Emerson asked a good–albeit fairly obvious–question on Twitter just now.

I am working on an article about the 100 Biggest mistakes in smallbiz and how to avoid them. Does anyone have advice to share?

Continue reading “The biggest mistakes in small business”

On Releasing Early

Jason Cohen guest-posted in December 2009 on the great blog On Startups, disputing the startup cliche that it’s always good to release your product early. He makes a good case to the contrary, although like some commenters I don’t think the iPod is a fantastic counterexample. (I mean come on. It’s Apple. They can get away with wild new design ideas, it’s what they do.)

My attention was grabbed by one of the comments in particular, from Trevor Lohrbeer. He says, in part:

Selling the product before release can also have the advantage of financing the development while at the same time focusing on the customers who are willing to put their money where their mouth is. It gets rid of the biggest problem of eliciting feedback, getting feedback from people who will never buy your product anyway (or may never buy at a price you can make money at).

Which, it should not surprise you to know, reminds me of a story.

Continue reading “On Releasing Early”

80% of what?

Yeah, you got that whole 80/20 rule thing. 80% of what?

I’m a big believer in the 80-20 Rule. If you haven’t heard of this, it’s the idea that almost everything you do yields 80% of the benefit with the first 20% of effort. Similarly, you’ll find that 80% of your sales come from a 20% subset of your offerings. Stuff like that.

Sure, it’s a back-of-envelope rule of thumb sort of deal, but still a useful planning concept. (I love heuristics.)

On Monday, I blogged to the effect that non-software startup companies be satisfied with commercial off-the-shelf software that satisfies 80% of the functionality they require… because that’s so much cheaper than embarking on a new project when you are already hard up for cash.

Continue reading “80% of what?”