I was out car shopping over the weekend. The conversation with the pleasant car salesman went something like this:
Me: I need something that seats 5 comfortably, does 0-60 in under 5 seconds, gets at least 30 miles per gallon and all for less than $50,000.
Salesman: Great! We’ve never sold anything with all those specs. Start paying us now, and we’ll have something for you to drive in 2-3 months but it’s only going to be a few parts of the car. Probably brakes, tires and maybe an engine. You may get 4 of those seats since we never actually needed the 5th. Rest assured though, since we’ll be in constant communication with you, in 2 years the car you end up getting will do exactly what you really need – you’ll love it!
Me: Sold! I can’t wait!
. . .
Okay okay – yes, this is an entirely fictitious story, but I’m trying to prove a point here. Can you imagine if we developed and sold other products the way software products are built today? Don’t get me wrong, I think Agile software development methodology is the bee’s knees. But to the folks that don’t believe in it with the same religious conviction, it can be a pretty tough sell. And they’re smart people. As software development professionals, we need to understand those hurdles so we can win over nay-sayers and ultimately be better business partners.
My first job out of college was developing line of business apps for Boeing’s IT department. I remember asking one of our EVP’s during an all hands if agile software development methodologies were going to be adopted at the company. Remember, this woman over saw hundreds of software developers and other information technology types. Her response was something like “Yeah! I love agile. BUT I think we really need to focus on getting *complete* and accurate spec first, BEFORE we start coding.” My fellow new hires looked at each other with raised eyebrows. We asked her to elaborate a little more. Clearly, she didn’t get what agile software development was all about. She thought it was just about taking the big chunk of work and breaking it up into check points to ensure it’s on schedule. And ya know, I don’t blame her. She came from an aerospace engineering background where ‘bugs’ or ‘missed features’ crashed airplanes.
In the last 50 years of software development, we’ve learned that we humans are really bad at writing good, large scale specification for any engineering project. Furthermore, by the time we finally build the darn thing – the problem space probably changed enough to render a good chunk of the original spec useless anyways. The latter is especially true in the fast moving world of software.
Traditional projects start with a grandiose vision (sometimes disguised as a ‘road map’) that’ll take a while, say 2 years to build. Everything is going along hunky dory until about half way through when the team realizes what they’ve built is mostly wrong. Not because the planners and architects were bad at their jobs – but because the problem space changed. Or some mixture of the two. Either way, the team valiantly attempts a massive course correction. By the time everyone’s convinced the new and improved destination is the right one, no amount of death marching will deliver a product on time, in budget, or up to quality standards. That tricky three legged stool.
Agile operates under the assumption that nailing perfect, full blown spec for an entire product is a fool’s errand. Instead, it constantly takes off small, incremental bites that ensure each feature is well thought out, properly executed and works well in the context of other features. You might make some miss steps, but they’re much easier to fix because they’re much smaller miss steps.
What’s key is that at the beginning of each sprint, the team takes the next item at the top of the priority list. This churn ensures the development team is constantly delivering value to the end user what ever that happens to be.
Despite what you’ve heard, capitol-A Agile isn’t actually about sprints, or scrums, or throwing paper work out the window. It’s about an iterative, incremental process that constantly validates you’re building the right thing. Us software types know this yields an inherently better product.
In product development, prototypes are the best way to validate spec. To prove that the idea can reasonably solve a problem. However, in the physical world, the jump to of take that prototype to production and getting it to your customers (users) at scale is very non-trivial. Supply chains, manufacturing processes, shipping, retail, etc. If you’ve made any mistakes in the product development phase and shipped a lack luster product… well, you just made a very expensive mistake. But in software, the time to put freshly written code in the hands of your customers can* happen in a matter of hours. Physical product developers would kill for that kind of speed to market.
*It doesn’t always. Well, it usually doesn’t. And actually, just because you can doesn’t mean you should. Marketing and legal departments have to keep up. Users don’t like things changing on them too quickly either. But I digress.
The biggest hurdle for Agile is that you intentionally won’t guarantee exactly what the product will look like down the road. Maybe that’s sexy to the enlightened smarty pants software developers. But it sure isn’t to folks who wear suits and allocate budgets to those developers.
You know what is sexy to those folks? When an entire project fits into a single power point deck with exact costs, schedules and known outcomes. Agile, for good reasons, refuses to answer those questions. Then it asks the business to ‘trust the process’ to organically build a product that will solve some problems for the user, not knowing exactly what that is. So next time you’re in a meeting and don’t understand why the person across the table hasn’t drunk the Agile kool-aid, remember that the process is actually pretty un-intuitive.
“We’re not sure exactly how or what, but we’re gunna figure it out. And you’re gunna love it.”