When you plan for features instead of planning for change, you are planning to fail.

Successful projects require constant collaboration that includes every stakeholder, throughout every stage of the project:

That's why we at Ninjitsu Web take the Planning Stage and mash it up into little pieces that can be sprinkled through out the project. We build projects incrementally, architecting our work-flow and our software to allow us to add and adapt features based on the latest information received from the engineers who are actually building the software, and the users who are actually using the software.

During development, every two weeks at most, we have a mini planning meeting with our clients, called a "Scrum" after the rugby term, to review:

• What tasks have been done since the last review?
• What have we learned since the last review?
• What tasks are expected to be completed before the next review?
• What roadblocks are we facing, if any?

Both the client and the engineers must answer these questions. This allows us to be flexible in our process, and accurate in our decision making.

Documenting Specifications

Every project requires change mid-stream. In over ten years of web development, I have never once seen a project that was both satisfying to the client AND fully matched the original specifications document. If the software matches the specs, it will be unsatisfactory because requirements have changed (or were never defined clearly enough in the beginning).

To make satisfactory software, developers will always deviate from the written specs, if it is a large, unchangeable record of imaginary software that hasn't been created yet. Deviation is necessary as both developer and client become more aware of the needs of the project during the development cycle. So why waste time on a monolithic specifications document before work begins? It just doesn't work, most often because clients and developers both have expectations and assumptions that can't be communicated until they are truly sitting together and looking at a real, usable piece of software.

Of course, specifications do need to be in writing, if only to help everyone remember what was agreed. But the best way to document specifications over the life of a project is one step at a time, starting with the barest minimums, and building on top of that base. A project manager takes careful notes during the regular Scrum, and these notes become job tickets which document the requirements in written form. Some developers use a stack of post-its or 3x5 cards, with a single requirement on each card. This helps ensure that requirements are sufficiently focused, and not bloated with assumptions that may change over time.

Change is most expensive when you fail to plan for it. When you plan for features instead of planning for change, you are planning to fail, because the features that you can imagine now are a dim shadow of what will become crystal clear once the real work has begun.

Horizontal and Vertical

I'd like to point out that what we're talking about here is not necessarily the difference between "Vertical" and "Horizontal" development methodologies. In vertical development, the team tries to determine all of the requirements in advance, and builds each component with the assumption that the other components work a certain way. As we've discussed, this is almost never truly possible, but to the degree to which the team succeeds, it may provide a more integrated system, which can be good for stability and performance, but often makes extensibility more challenging.

In horizontal development, the team focuses on one set of related requirements, and does not consider other requirements until a system has been delivered which fully meets those defined requirements. This provides much greater flexibility during development of subsequent components, and results in working software delivered to the client more frequently. However, the components of the system are relatively disconnected, which can sometimes result in a less consistent user experience.

By way of examples, imagine a website that might have a Blog and a Forum where users can post to a personal blog and participate in forum discussions. Further, the site might desire an integration feature whereby a blog post by an administrator automatically causes a Forum discussion thread to be created, and to notify the blog author by email when the discussion thread is updated, or some other more complex integration between blogs and forums. This can be accomplished with our platform of choice in various ways.

In a vertical development strategy, we may decide from the beginning that it is desirable to have a custom blog component, as opposed to using a simpler pre-existing componenet, because of the additional integration needed with the Forums. However, adding a user contact directory for blog authors in the future may be more difficult, because it was not accounted for in the original architecture of the custom blog component. (This is a trivial example, but serves effectively for demonstrating the point.)

A horizontally developed site might start with basic user management and then add the Forums, quickly implementing features using readily available components of the development framework. After this, the blog is considered, again starting with pre-existing tools and adding the needed integration with Forums. In horizontal development, the Forum/Blog integration is added as a separate piece of integration code between the two separate components.

In the future, when the request for the user contact directory is received, it is provided as another individual component, which is fundamentally unaware of the blogs and forums, but can leverage any data they provide with integration code.

Hopefully the charts make it clear how vertical development can result in a 'simpler' system, and it is a law of nature that simpler systems tend to be more stable. Likewise, horizontal development results in a system that is more flexible, and can be infinitely expanded, at a cost of increased complexity.

At Ninjitsu Web, we often use a somewhat hybrid approach. We will work with you to broadly define as many of the critical requirements as possible at the beginning, but work will commence on the assumption that requirements which are scheduled later in development may change significantly, although the 'big picture' is always in mind. So rather than delivering a complete and final sub-system, written in stone, with every iteration, we will deliver a series of working prototypes, which can be polished and tuned for final release once the entire system has been prototyped and proven to be capable of fully satisfying the client.

Resources

Here are a few resources that expand on these ideas:

• This short essay provide an excellent explanation of exactly why over-planning is a waste of time: There's Nothing Functional About a Functional Spec

• In the long run, Prototype-then-Analyze-and-Adapt ("Agile") projects are also more cost effective that Plan-then-Build ("Waterfall") projects. Here's a brief video explaining why:

  Why Does Agile Software Development Pay?

  Ninjitsu Web further maximizes these benefits by providing multiple estimates as each new phase of work is planned. Whenever possible, we will present for you multiple strategies for accomplishing a particular task. Clients who consistently choose the simpler of two approaches consistently enjoy savings. Cost control is entirely in the client's hands.

• Here is a dramatized take on the big idea: Agile vs. Waterfall: A Tale of Two Teams
  

  We're on "Kate's" team, and we look forward to having you join us there.

If you have specific questions about how best to approach your own web project, please feel free to Contact Us.

Matt Chapman - Owner, Ninjitsu Web Development

This work by The Matt Chapman Company, LLC is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.