Formalizing a Software Development Process

Few topics stimulate the troops and drive such rousing conversation around the office watercooler as software development process discussions. I decided to address this topic in my first blog post, not for the cheap emotional thrills, but more as a foundation to lead into future posts on product design methodology.

After having spent about a year-and-a-half with the web team at DIRECTV Latin America, I started to notice that different projects were being managed and developed in different ways, with no standardized process used across teams. In some organizations this might not be a problem, but in our case, many of our resources were shared between teams, and the different processes were causing confusion and frustration. To make matters worse, there were a few examples in which important steps were being skipped accidentally and products were being released with issues. For example, business owners would ask how a recently launched site was performing, but since a web analyst had not been involved in the project, the correct tracking tags had not been included and important goals were not being tracked. That type of thing.

After a couple such incidents, I decided to try and standardize a development process that could be agreed-upon and used by all teams. I created the above diagram to help formalize and communicate the new process.

I created an initial version of the diagram based on my own observations and ideas, then reviewed and adjusted it with the team in iterative sessions until everyone was happy.  In a way, it is an adaptation of a standard SDLC diagram, but optimized for speed and agility. We determined, for example, that after UX work was completed, we could initiate a variety of tracks (visual design, copywriting, analytics) simultaneously instead of sequentially, thereby leveraging Agile methods and saving time. In some cases, after having determined a high-level structure, we would even run the UX work concurrently with other steps. For example, for a homepage redesign in 2011, we determined the overall modular page structure, then designed and developed the page one module at a time.

Here are a few additional notes/explanations:

• The process depicted is aimed more at new developments rather than simple updates to existing products (which we generally classified as maintenance activities – see the first branching point in the diagram).
• The diagram is meant for high-level use, since it does not capture the details often necessary within each task. For example, within the Information Architecture/UX step, the designers might begin with research and assessment activities before moving to prototyping, iterative testing, etc…
• Individuals responsible for each activity are shown with the blue person icon.
• Possible deliverables are shown with the gray document icon, but these are only examples and the actual deliverables should be determined based on the specific project needs.
• We used the task management tool Jira, which you’ll see mentioned a few times in the diagram.

We used this diagram pretty successfully for years, tweaking it only occasionally as we came across new problems. I think it’s a good start for any small-medium organization looking to add a little formality to the development process.