In addition to being your intrepid editor, I’m an independent consultant. People hire consultants because they want someone to “inform their process”. “How do we do Agile better? Do we do Scrum or Kanban? Can we do scrumfall instead?” “Should we do BDD, TDD, or ATDD? Or combine them? Are there any other acronyms we should be doing?”

The ITIL 2011 Processes Model
Ugh. This diagram makes me physically ill.

This week, I’m guiding a company on “ATDD”- “Acceptance Test Driven Development”, and while I was at it, I went off on a rant. I went off on a forty-five minute rant about processes and the role of having “process” in an organization, and how small organizations and large organizations use processes to shoot themselves in the foot in vastly different ways. It was quite a rant, and I discovered that I had a lot of strong feelings about how organizations adopt, employ, and adapt processes, and how the processes they use define their culture and also define what they can successfully accomplish as an organization.

So let’s take a minute to talk about process.

First, though, let’s talk about my last day at my old job. I worked the traditional 9-to–5 at a gigantic manufacturing company. It was the kind of company that had a “Project Management Office.” The PMO had two main jobs: it made a list of the “required project documents” that had to be uploaded to SharePoint during the lifecycle of your project, and it administered the Project Server instance you had to use to track your project.

I, on the other hand, was a developer who also inherited the responsibility of administering our TFS instance. On the latter part, my job was mostly supporting push-button deployments and reminding people that VM images don’t go in source control.

One day, our users asked us to “turn on” the functionality that TFS sync data about its work items with tasks in Project Server. To do that requires a handful of steps. Project Server needs a plugin installed, and a switch flipped. The TFS team project has to be configured to talk to Project Server. Then, anyone using MS Project can set up their project to sync data between the two environments. This was a trivial, low-risk change, so I brought it to the PMO to make it happen. The PMO was happy to install the plugin, but when we asked them to “flip the switch”, the effort died.

The effort died because the PMO wanted to fit the act of flipping the switch into their process. And it quickly became clear, as they asked their questions. No matter what question they asked, we had a simple reply that addressed their concern, which only meant that they had to re-ask the same question in a different way until we ran out of ways to say the same thing. Simply flipping the switch and letting the TFS administration team worry about administering TFS was not an option them, and they needed to control access to this feature. The idea that any Project Owner could just “turn this on” just by asking was an absolutely terrifying concept. The fact that it was on a per-project basis and not a global change was honestly worse, in their opinion, than a global change, because that meant decisions had to be made for each project, based on the needs of that project. Everything the PMO did was built around removing flexibility for decision-making.

This culminated in a meeting between the PMO and the TFS team on my last day of work. I had already quit my job- amicably- and was trying to help wrap up some final projects before I walked out the door. The meeting took the form of the TFS team saying, “You just need to flip a switch and everything after that is our problem and you don’t need to be involved,” and the PMO trying to toss their process over our own and suffocate us with it. Every solution we proposed was countered with a new obstacle, a new checkbox that had to be checked, a new document which needed to be generated. They weren't interested in posing challenges and getting solutions, they just wanted to make sure they were in control of the process.

Voices got raised, tempers flared, and in a fit of dontgiveashititis, I turned to the head of the PMO and said something like, “I give up. We are going to cancel this effort, because you have officially made it not worth doing. You are the obstacle, and since we can’t get rid of you, we just aren’t going to bother with you, and our developers get to suffer, so thanks.”

It’s probably not my proudest moment, but it was damn satisfying.

I relate this story, because it’s a perfect example of two different approaches to process. Every process we had regarding TFS was built with one goal: to help developers get things done. It was formal, and documented, but it was also nearly invisible. The PMO, on the other hand, wanted to use process as a tool for control. They wanted it to be governance and a series of checkpoints, and the philosophy was, “if we build good checkpoints, and force people to go through our good checkpoints, we will have good end results.” (They were consistently wrong, and more projects failed than ever succeeded under their watch).

A lot of developers, especially the ones who work in large or “enterprise” organizations, take a very dim view of “processes”, because they’ve dealt with too many groups like the PMO I dealt with. They hear things like Agile, or Test Driven Development, or Business Driven Development, and all they hear is a new set of policies and practices that are going to be foisted upon them without any sense of the underlying reality.

On the other side, you have those tiny shops, who see process as nothing but an obstacle. “We’re just hackers, bro.” The attitude is best typified by an organization that’s “small in spirit”, in this bizarre slide deck from a FaceBook developer, which argues that their terrible practices arise from their “scale”, and that’s why the FaceBook iOS app has to be a 187MB behemoth to show you your newsfeed.

Like most Internet debates, both sides are beating the snot out of a straw man, so let’s just say the actual truth: Process is important, and it doesn’t have to suck. And let’s add onto that: process is never a cure for a problem, but it might be a treatment.

Let’s be honest, managing developers is like herding cats, and you need to point them all in the same direction by giving them some sort of guidance and organizing principle. Processes are a way to scale up an organization, a way to build towards consistent results, and a way to simplify the daily job of your developers. With that in mind, I want to talk about development processes and how organizations can make process work for them, with the following guidelines.

Have a purpose. Why are you making the software that you’re making? What is its purpose? The software product they create is supposed to accomplish something for their end users. In enterprises, you’ll often hear the phrase “business value”, which is a fancy way of saying, “why does this matter?” Understand why you’re developing the software you’re making.

How does having a purpose help you with defining your processes? Simple: every process that makes it easier to achieve that purpose is good. Any process that erects an obstacle between you and your goal is bad. Stop doing that.

Buzzwords are not processes. I’ve been doing an incredible amount of “ATDD” consulting. “We have to do ATDD,” organizations say. ATDD- Acceptance Test Driven Development- is not a process. It’s a collection of practices that you can employ to build your own process. This goes for anything that’s trendy. “We need to do Agile.” No, you don’t “do” Agile. You examine the various Agile processes and methodologies and adapt them to your organization and build your own process. Don’t do things just because somebody else told you to.

How do you know which practices are the right ones to adapt? Try them out, and then ask yourself: are we doing a better or worse job of achieving our goals.

Guidelines are better than checkpoints. A lot of organizations use process to control their employees. “You must do this, and you must do it this way.” Compliance is enforced, sometimes with a carrot, usually with a stick. This grows from bureaucracy, which itself grows from a fairly natural need to ensure consistent performance regardless of which “human resources” are involved in an effort. Bureaucracies don’t care if they turn into a Harrison Bergeron dystopia where performance is consistently poor- just as long as its consistent.

The purpose of a process is not to ensure compliance. It’s to provide a well-paved path that guides your developers to success. Which brings us to our penultimate point.

Processes should grow from institutional best practices. While you can certainly learn from other organizations, and trade magazines, and articles like this one, the only people who know how to do what you specifically do are the people who do it- you.

Roger Corman, the master of the B-movie, was infamous for shooting movies on tight schedules with budgets that couldn’t afford rent in San Francisco right now. Many of those movies were bad, most of them are, well, B-movies, and a few of them are actually pretty great. He consistently delivered product on time and on budget, and the results were usually acceptable. As a producer, he would take new directors aside and lay down “The Process”. He would lay out the workflow for these directors, in almost a draconian way: “You block like this, you light like this, you shoot like this, you run your team and departments like this, and you never try and take shortcuts.”

In fact, the Corman process contradicts much of what I said above- he didn’t give “guidelines”, he gave mandates. If you directed a Corman flick, you directed it according to the Corman process. But here’s the kicker: the Corman process was a best practice that Corman himself developed and refined over his career, and it was built to serve his institutional purpose (to make an acceptable film, quickly and cheaply).

Processes have to be built by people who use the process. They have to support the organization’s purpose. A well designed process encourages compliance because it is an effective process. A good process should not require management to get engaged in its adoption, because a good process has clear benefits.

Finally, processes that result in additional meetings, documents nobody reads, work that doesn’t directly support the organization’s purpose, or involve erecting obstacles to keep people on the “correct” path- these are bad processes.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!