Developers, programmers, architects, engineers, coders… front-end, back-end, full-stack… whatever ya call ’em.  I’ve managed technology builds for the better part of three decades.

I’ve hired brand-new coders still in high school. I’ve hired self-taught intermediary developers.  I’ve hired senior engineers with advanced computer science degrees.

While they range in capabilities, from fast-starters to strong-finishers, almost all have been super smart.

But I can tell you – – most software builders hone their craft as ‘makers’ and, in spite of all the emphasis on planning, they mostly all struggle as planners. It’s simply because they love to CODE, can’t wait to code… they get the thrill from coding day and by night.

Most software shops have someone else handle the planning (business analysts, project managers, etc) but these companies are built on the backs of their programmers. No doubt, although planners are the ones responsible for delivering the outcome, the builders fight hard against letting the “tail wag the dog.”

The argument goes like this:

• “You aren’t being AGILE” unless you start banging out release #1 and iterate from there.
• Without programmers involved right away, “you’ll plan for functionality that isn’t practical.”

Indeed, P-L-A-N, is a four-letter word most commonly saved for team retrospectives.  In other words, time-after-time like a broken record — once the project is over, the teams agrees “we shoulda planned a few things better.”

Here are the facts:

• Agile requires understanding your minimum goals.
• It’s critical to know all the functionality you want- even if we later figure out a better way to achieve it.
• Coding too soon means EARLY “technical debt.” Technical debt requires the support of specialized knowledge.

It’s just common sense…. NO software language is EASIER to change than words/ drawings on a page. Ya see, once coding starts– the only people who can make changes are your programmers and if you failed to put in solid planning: you’ll need a TON of changes.  Think about it like this — every hour they spend changing something you coulda deleted from a schematic in 5 minutes, drives your project costs sky-high.  Hey, that’s great job security for the programmer but it’s bad for your budget.

BOTTOM LINE: If you wanna build a house, you hire the carpenter to frame the structure AFTER you’ve made decisions about what that structure should be. Good planning vastly reduces project costs.

Importantly, your planning efforts need to be handled by someone who’s:

• Expert in technology and the software development process. This means low risk for planning functionality that isn’t practical and an understanding of how to meet your goals. In addition, experts in software development have an astute awareness of how best to employ Agile methodologies.
• Unbiased with regard to your project size.
• Affordable because the point of planning is for efficiencies that reduce your costs. Planning is critical but avoid paralysis by analysis.
• Focused on your needs and goals when creating and overseeing the project.

Recommendation:

Hire your initial planning team separate from development.

That’s right.  Think about it… the last thing you need is smart people behind a complicated technical veil who’re paid based on how big your project can be.  Instead, hire a team to analyze and help you plan your project separately from the team who’ll BUILD. This team should be far more efficient and will objectively hear what you want without a tendency to inflate the project’s size. In fact, if that team is experienced, they’ll be good at honing in on your minimum needs so you can use LEAN principles to iterate based on actual usage and user feedback. And this team will not only be adept at communicating what needs to be done to the developers you hire — but they’ll be your advocate if developers start heading the wrong direction or pushing to needlessly expand scope.

That’s what StackRelease does. We make it very clear WHAT to build… and then we get qualified software builders who can do the job.

Importantly, this approach allows:

• Development to be very Agile because minimum needs are identified and iteration can be prioritized.
• Programmers ARE involved early (coding hasn’t started yet!) — so their feedback, with full scope in mind, is even more helpful. Better yet, astute shops provide this feedback along with their quote — which you’ll find valuable in selecting your software building team.

The adage still applies…

Measure twice. Cut once.