This post was fairly popular when it was originally posted but somehow got lost.  We are reposting it mainly because it’s still very relevant.

As we grow and mature as an organization, our processes evolve. While we stay true to our core belief that a process should be simple, flexible, repeatable, and effective, we are always looking to improve. A clearly defined process won’t solve all of the issues associated with software development, but it will definitely reduce the chaos.

A development methodology is the core of a good software process.  However, there are no one-size-fits-all methodologies. While each “system” (waterfall, agile, etc) has its own merits, there is no silver-bullet solution that will fix your development process (or lack thereof). A methodology is just one link in the chain of a solid process. It’s important to look at the different methodologies available and adopt (and adapt) the one closest to you end-goal.

So what else do you need to make a process really work, here is a short list:

METHODOLOGY

Every good process needs to starts with a solid foundation. Even if you adopt you own form of a methodology, which is what most of do in reality, it is good to start by picking an existing one with a good track record. When picking a methodology, remember to consider where you want to be as development team vs. where you are today. I know that might seem simple, but I have seem many groups pick a method that closely resembles who they are vs. who they want to be. Again, it’s human nature to take the path of least resistance. Another recommendation: don’t pick an overly complicated or document-heavy methodology. You’ll notice I didn’t say document-free. You want to be productive, not mired in documentation.

Bottom line: Pick a methodology that is proven and includes the ideals of where you want to go as a team.

MANAGEMENT BUY-IN

I know, you are probably saying, “if I had a dime for each time I heard that one”, but this is one is critical. Without real support (i.e.: accountability for those who don’t align with the new process), the process will never take hold. People will not change if there is no consequence linked to NOT changing. It’s just basic human nature.

Bottom line: Wishy-washy leadership = no change.

TEAM BUY-IN

This does not mean everyone. You will almost always have the naysayers who like things as-is or want waterfall over agile or vice-versa. I recommend including your most trusted developers, the good ones, in the decision making process as you move to make changes. Defining “good” is outside the scope of this post but lets just say good doesn’t always mean the person who gets things done the fastest. This will help them to see you are committed to them and value their input.

Bottom line: Be inclusive but stay committed to the end result. Understand that some folks may leave because of the change. Be ready for that reality.

DOCUMENT AND EDUCATE

Hey, I’m a developer, what’s with all the documentation? Documenting the process is important to ensure it is repeatable. Keep it simple. A wiki write-up or a simple, yet clear bulleted manifesto will suffice. Do not write a 200 page process document…unless you want it just collect dust. Make the process document available on your intranet to everyone can see it and be prepared to change it when necessary. Meet with your team and explain the points of the new process. Go over why you believe it is better than what you are doing today.

Bottom line: Keep the document simple and clear. Educate the team and make sure they know why the change is being made. People like to know why something is happening, not just that it’s happening.

REVIEW

After each project, conduct a “post-mortem” to determine what went wrong and what went right. This will help to determine if changes are in order. Is your team more effective with this new process in place? Without these reviews, your process will never take advantage of lessons learned.

Bottom line: Be flexible. Always look to refine and improve.

A good process will yield good results consistently. But implementing a process or changing an existing one can be a painful experience for some organizations. My experience has shown that organizations that ignore the failings of their current processes, create an ever-growing amount of “tech debt.” That debt can become so heavy they collapse under the weight.  If you keep your processes simple and flexible, it can change with your organization and evolving technologies, enabling your team to be more responsive and efficient.

Take some time this week to review your software processes. Create a short list of items you know can be improved upon. You will be happy you did it.