In addition to being your intrepid editor, Im 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?

Ugh. This diagram makes me physically ill.

This week, Im 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 lets take a minute to talk about process.

First, though, lets talk about my last day at my old job. I worked the traditional 9-to5 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 dont 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 dont 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 cant get rid of you, we just arent going to bother with you, and our developers get to suffer, so thanks.

Its probably not my proudest moment, but it was damn satisfying.

I relate this story, because its 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 theyve 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. Were just hackers, bro. The attitude is best typified by an organization thats small in spirit, in this bizarre slide deck from a FaceBook developer, which argues that their terrible practices arise from their scale, and thats 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 lets just say the actual truth: Process is important, and it doesnt have to suck. And lets add onto that: process is never a cure for a problem, but it might be a treatment.

Lets 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 youre making? What is its purpose? The software product they create is supposed to accomplish something for their end users. In enterprises, youll often hear the phrase business value, which is a fancy way of saying, why does this matter? Understand why youre developing the software youre 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. Ive been doing an incredible amount of ATDD consulting. We have to do ATDD, organizations say. ATDD- Acceptance Test Driven Development- is not a process. Its a collection of practices that you can employ to build your own process. This goes for anything thats trendy. We need to do Agile. No, you dont do Agile. You examine the various Agile processes and methodologies and adapt them to your organization and build your own process. Dont 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 dont 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. Its 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 couldnt 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 didnt give guidelines, he gave mandates. If you directed a Corman flick, you directed it according to the Corman process. But heres 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 organizations 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 doesnt directly support the organizations purpose, or involve erecting obstacles to keep people on the correct path- these are bad processes.

http://thedailywtf.com/articles/processing-a-rant