An analogy that might help

We just got hired as a jazz band, which is great. But there’s this one guy who insists on playing drums and only plays marching music. It’s the way he’s always played music and it’s all he knows. He is absolutely willing to play in the jazz band but will only play a marching beat. That’s okay, right?

I had a long talk with a new team last week. They’re doing a hybrid agile/waterfall approach on a project that needs tons of changes to reach viable status. My old pal Paul got in touch to ask me about some “intricate” issues.

Continue reading “An analogy that might help”

iTextSharp frustrations

I’ve been working a lot with iTextSharp lately. It’s incredibly useful but also sparsely documented, and the design concept is far from obvious. Here’s what I mean.

You don’t instantiate a PdfDocument. even though its constructor is public. You instantiate a Document. It creates a PdfDocument behind your back.

“New Page” behavior is extra bewildering!

If you haven’t put anything onto a page, but call PdfWriter.NewPage(), you will not get a new page.

You can override this behavior by setting PdfWriter.PageEmpty to false. (You can’t set it to true!)

Guess what? Pulling the drawing context so you can position text by the pixel, and then doing so, doesn’t count as putting anything on the page.

Sigh.

Help right now for tech-dependent startups!

Your startup depends on a web project or custom software application. Doing it alone isn’t working out. I can help.

(tl;dr: Answer a few easy questions to see if I can help your startup!)

Do you have a startup company that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Are you still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?

I’m hearing you.

So you have this small business. You probably just started it. You’ve got a pretty good business plan, you’ve stashed some money to keep it going until it breaks even and can pay you, you’ve worked out health insurance and stuff… or maybe you’re keeping your day job and working a lot of nights and weekends to get it together. And it’s a cool idea: some product or service that people are definitely going to want to pay money for. It’s exciting and terrifying, because you don’t know what could go wrong, but you’re also a little apprehensive about how it will go right in the end.

Continue reading “Help right now for tech-dependent startups!”

Solving the right problem

The key to making your project not suck is making sure you’re solving the right problem. Start by doing the things that cost little, can’t hurt, and might help!

For several years now, I’ve been describing my business as “Making Your Software Project Not Suck.” Here’s where that catchphrase came from, and how I actually go about doing that.

Where it came from

Maybe twelve years ago… yeah, okay, that would have been in the lull after the post-Y2K slowdown and just before 9/11… I was pretty much in between major projects. As was almost everyone else.

It was time to Work on Marketing! Which if you’re smart, is something you do all the time, but in some ways I’m just not that smart. Or more to the point, I do know what I have to do but there are always competing priorities that appear to be more urgent. You know how it goes. Fire-fighting often trumps planning.

Continue reading “Solving the right problem”

How did we get into this mess?

Software projects go badly when everyone is unrealistic about how real humans do creative work.

I’m in the midst of an email conversation with a pretty well-known turnaround CEO adviser, the kind of person who can Make Your Company Not Suck. He’s way beyond me in terms of influence and reach, and he consults enterprise-wide for way bigger outfits, but for some reason he ended up asking me why so many projects still get in trouble even though all kinds of training and certification are available these days.

This is about what I wrote back.

Continue reading “How did we get into this mess?”

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?

So…

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.

What to ask first

Sometimes you can’t make the project not suck right away. You need to do a pre-unsucking project to figure out the actual unsucking.

Oh my. Here’s a Project That Sucks. It sucks so much I seriously don’t (yet) know how to make it not suck. How crazy is that?

Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.

Continue reading “What to ask first”

When they won't let you do Agile

If management won’t let you do Agile, don’t fight it. Find the best ways to apply the Principles regardless.

If you’re a fan here, or if you’ve had more concrete experiences of working on Agile software teams, you probably have a good sense of how well the Agile values and practices can really work.

Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.

Continue reading “When they won't let you do Agile”

When KanBan crumples

The KanBan is made for the project. The project is not made for the KanBan. Adventures in refactoring!

So this week I’m seeing on the KanBan:

  • #101: “I want to be able to comment on a comment.”
  • #102: “I want to be able to post a question in response to a comment.”
  • #103: “I want to be able to post a comment or a question.”
  • #104: “I want to be able to post an answer to a question.”
  • #105: “I want to be able to comment on the conversation as a whole.”

This is oversimplified and (only very slightly) dramatized, but you see the overlap and the potential for confusion. These story cards are blocking a ton of other work that needs to be done in the next couple of weeks. And they’ve been claimed by different developers!

Continue reading “When KanBan crumples”