The root of all (software) evil

Poorly articulated requirements are the devil. Poorly-understood products that are being implemented are his doomed children.

Requirements are the root cause of an inordinate number of issues in software development. The best team on earth will still create a terrible piece of software if nobody can explain to them what the good one should look like. Gathering requirements, documenting them and communicating them is extremely difficult and time-consuming, and with many teams is an extremely poor use of time.

Understanding the customers and the product, mind, is critical. Documenting requirements, depending on the team, project, pace and scope, may not be.

No matter what approach to requirements you take, though, product owners need to know inside out and backwards what the opportunity, market, users, problems, competitors and solution are. They need to be attached at the hip to your development team so that they can preach their needs, see the tools being built, learn from touching, ask questions, answer questions, pounce on the subtle difference as soon as their fingertips brush it and say “the customer is actually trying to solve this problem, and the implementation doesn’t cover it because of that“. They need to be passionate about their needs, while clearly understanding what the minimum viable product really looks like.

If your company is three people, you’re all product owners. If it’s thirty, three hundred, three thousand or even 6, you’d better know very clearly who owns the product. And they’d better know very clearly what the product is. MVP sounds like a simple idea, but if the work hasn’t been done to flesh out a thousand things that aren’t MVP, it won’t be minimal, it won’t be viable, and it might not even be a product when you’re done.

Risk and reward

What if rocking the boat just so cancels out the action of the waves and makes it the first-ever non-seasick ship?*

If you’re going to play it safe, you may never be surprised by a huge disaster. Chances are you will anyway, though, so why limit your business?

Control the potential size of your failure by trying small things (or small / incremental parts of big thing), but try them. Even just on for size. Even just to see if they stick to the wall. Even just with the one customer who will be completely delighted that you asked them to try something with you. Even if it doesn’t work, you learned something, and the next one might.

Status quo will not result in hockey-stick growth, rabidly loyal customers, an enthusiastic user-base, or an amazing learning experience.

* Apologies for the terrible metaphorical example.

Changing people

When you change something about your business, division, department, product, technology, team or process, people are affected by it. By and large, people like to feel in control of change in their lives. Since they cannot be in control of the change, at least empower them to drive it, inform it, implement it or improve it. Involve them in the process. Involve them in the solution. Treat them with respect.

This is one of the subtle ways you can turn “headcount” back into people. “Headcount” doesn’t get any work done. It doesn’t make customers smile, it doesn’t ship products, it doesn’t innovate, it doesn’t surprise or dazzle. That’s what people do.

I like teams filled with smart, energized, independent people – they often make unexpected, incredible things. I’ve never seen headcount do that.

When is the time for half-measures, anyway?

“Now isn’t the time for half-measures!” is the kind of thing I imagine being shouted with spittle flying from lips, crazed eyes, and a Nixie-tubed countdown timer attached to some sort of explosive device that is going to level half of Manhattan. I think of it as being the rallying cry to sanity, to heroism, to buckling down, to saving the day. I wonder though, if there ever really is a time for half-measures.

I can’t think of one.

If you’re considering doing something you won’t be proud of to meet a deadline – implementing something that will need to be thrown away, extending something that needs to be replaced, addressing a symptom rather than a root cause – consider that you probably won’t meet the deadline anyway. So what’s more important: the date, or the value of the solution? Will the half-measure cost more in the long run? Almost certainly it will. If that’s valid from a business perspective – and sometimes it is – then swallow that pride and do it halfway.

If you’re considering doing something you won’t be proud of for a valid business reason, though, maybe that business isn’t worth it. Or maybe there’s a better business reason to do something you will be proud of. Almost certainly there is.

VanDev talk: How to Fail (and look good doing it)

Matt gave a talk at VanDev on November 18th titled “How to Fail (and look good doing it)”.  We recorded it – the audio isn’t perfect, but it turned out pretty well, and the slides are legible in the video.  Not bad for a first try with a brand-new video camera!  The subject of the talk is how to lead a team or company through failure in a constructive way – a valuable reminder of some leadership practices that can really help us get through the bad days and come out feeling like we did it right.  All of these ideas map 1:1 to the Lean Startup “Fail quickly, fail often” concept, but they’re not discussed that way in the talk.  Next time!

VanDev: How to Fail (and look good doing it) from Matt Walters on Vimeo.

Follow

Get every new post delivered to your Inbox.