Does “Process” Work in Software Development? – Part 2

In my post yesterday, I questioned the value of “process” in web and software development and discussed my successes and failures both with and without it. The biggest problem with process is that it deludes people into thinking they have the fundamentals in place to guarantee a successful project. Process is too often a crutch in this way.

Over the course of decade and a long list of projects, I’ve worked with variations of waterfall, agile, RUP and other methodologies, and I’ve also done my share of winging it with no formal process at all. Process or not, I’ve learned that the successful projects I’ve worked on all had certain ingredients in common. Namely…

Smart people.
This is a no-brainer, but a team of smart people is key because smarter people work faster, make fewer mistakes and are able to adapt to unforeseen changes. All it takes is a one weak link, however, to cause things to break. You can’t rely on smart people alone.

A film has both a producer and a director. A restaurant has a chef, a manager and a maĆ®tre d’. People need freedom to lead their respective domains, but smart people inevitably disagree with each other, and smart people without a recognized leader is a recipe for scope creep in the worst possible way. Everyone wants to put their best work into the mix, and a committee approach encourages quantity of ideas. Ultimate power needs to roll up to a single, clear authority with the tools to make good decisions and resolve conflicts within the team.

Frank Lloyd Wright once said, “Man built most nobly when limitations were at their greatest.” Jason Fried of 37 Signals says, “Embrace constraints.” Artists recognize that constraints help focus one’s creativity. In web and software development, constraints usually come in the form of hard deadlines or agreements around scope (often a bit of both). But constraints must be balanced with “a healthy disregard for the impossible,” as Marissa Ann Mayer – VP of search products and user experience at Google – put it. Innovative ideas by nature will often push at the very edges of constraints, so there should be some flexibility. The key to balancing constraints with a “disregard for the impossible” are good filters for managing new ideas. Which brings me to…

You don’t want to discourage innovative, unconventional ideas, but you need some way to filter them. The same goes for the more typical dynamics that lead to scope creep. Stakeholders second guess their decisions. Important customers complain about something or make specific requests. Some jackass in a meeting spouts off about some edge case, and boom… more stuff to cram into the project. Leadership (see above) is important here, and so are constraints like deadlines and scope. New ideas mean an increase in scope, which means moving the deadline. Either that, or something already in scope drops out. Each incoming idea needs to be considered, scoped and prioritized against everything else. Edge-case thinking just needs to be stopped. This is what I mean by filters – a change-management process that the team leader needs to enforce. Too often, outside ideas are subject to this process, but ideas originating within the team get a free pass. Filters need to apply to everyone equally.

This is its own kind of filter. The team and the stakeholders need to understand the essence of the thing they are building. They need to look at it holistically and know what it needs to do in order to be considered complete. It’s important not to look at features in isolation, because this encourages people to explore every possible expression of every nook and cranny of every feature (edge cases again). Instead, the team needs to determine only what is essential to each feature as it relates to the whole. Finally, the team needs to understand that the product can grow and evolve after it’s launched, so “complete” doesn’t mean perfect.

An understanding of “X” factors.
I mean “X” as in multiply. There is a list of things that add risk to a project and multiply its challenges and complexity. I’ll discuss these in detail in a follow-up post, but among them are:

  • nature of client
  • size and “spread” of team
  • complexity and novelty of the thing being built
  • time between designing and building
  • depth of QA
  • distance – with regard to both time and personnel – between deployment and maintenance

Good Tools.
Smart people can survive with just email and whiteboards. That might be the bare minimum, but I’ve had good experience using wikis and simple PM-ware like Basecamp.

Because shit happens. A good project manager knows it’s necessary to add 50% to every individual person’s estimate of time and effort, and then add another 20% or so across the board for good measure.

A good contract.
Too many contracts are essentially crafted by BD people who don’t understand what a project will really take, and who don’t have a vested interest in whether it actually succeeds. Too many contracts fail to consider the “X” factors, or encourage constraints, simplicity or leadership.

Otherwise known as communication. But “communication” is a cliche, and every team thinks it’s doing a good job communicating to stakeholders. The bottom line is, stakeholders need a strong consensus around the essence of the thing being built. They need to understand the change-management process (filters), and they need to see steady progress.

Even knowing all this, I’ve still worked on projects that have gone awry. But it has always been because we failed to follow something on this list. The good news is, when a new project starts to take a southward turn, I just take an inventory of the ingredients above, and when I identify what’s missing, it’s usually not too late to put the project back on track.

One Reply to “Does “Process” Work in Software Development? – Part 2”

Comments are closed.