First and foremost I’d like to take a moment to give a shout out to software development in the oil industry. Having kicked off my career there I can tell you from experience it gets a bad wrap. I did some awesome work there with awesome people. Plus, these folks know how to do process, methodologies, and chain of command. I cannot be thankful enough for learning enterprise development in that environment because loosening up on the process is easy but learning and appreciating it can be hard.
So I wanted to take a moment to do some appreciating. When I talk about “process” what I mean is just about anything project management related—really the software/project development methodologies: waterfall, agile, modified waterfall, scrum, RUP, and many more. But process has a place beyond project management and there are things that are not overarching methodologies that I want to give a little appreciation to as well– code management practices, issue tracking schemes, and even meeting requests.
Many people are afraid that formal processes for software development (or really anything) lead to inefficiencies and are too often more trouble then they’re worth. You spend a whole bunch of time writing documents, sitting in meetings, filling out forms, doing things that aren’t accomplishing your job, wasting time. I hear you, and sometimes that’s true, but you get things in return.
I mention earlier about meeting requests. This “process” seems small and silly, but I worked in places with meeting requests as the standard for scheduling and at a place where it was not the standard. There is something about letting someone “accept” a “request” and having to look at their calendar before dragging them into something that conveys a higher level of respect for their time than just shooting them an email or interrupting everyone with a “let’s all meet in the conference room.”
Just about any process can have this effect. When methodologies formalize interaction they can keep people from getting too focused on what they want out of a given situation and forgetting to respect the other people’s time, contribution, perspectives etc. This can be especially problematic if you have some dominant personalities. Having a formalized reminder of the importance and value of the other roles/teams/people is awesome.
Keep the train moving
When you work with really smart people, who have different goals: developers, project managers, sales folks, testing, etc… you’ll run into conflict. Not petty bickering, but really important discussions where smart people have differences of opinion. Good process can provide both a formalized way to “pick your battles” and a safety net for when you hit a good old fashion problem. Sometimes you just have to keep moving because there isn’t always a best solution, but as long as you can find a great solution, things will be okay. Back to respect, process can be the enemy instead of the enemy being each other and that can be priceless for coworker harmony.
A good set of methods can help everyone stay on the same page. Whether it’s a bug report, a business requirement, a feature, an incentive… it helps to formally define the language we use to speak, and break up things into manageable bite size pieces.
This means that you can minimize the different lingo that various teams use to discuss the same things – which will improve and increase communication among teams/people –always a good thing.
It’s easier to bring problems and concerns to each other when when everyone knows what you’re talking about. People have more meaningful, useful and satisfying discussions when you can get right down to it. You’re more likely to ask “a quick question,” of your business team, or run this feature by your usability guru, if you have don’t have to say… uhh so I’m uh working on this part of this thing, oh wait let me explain. Hrm.
But process is inefficient?!
I think the best response to that argument is that no process is inefficient too – no bug formal bug tracking system can lead to a bug slipping through the cracks and costing more later, possibly more than the entire cost of the tracking system. I use that particular example because I think most developers buy into the need for a bug tracking system – but the same holds true for a lot of other processes as well, including the heavier software methodologies. If you miss a business critical requirement, or overlook a development risk, these oversights can easily cost more than an entire development process worth of meetings, documents, etc.
It works if it works for you
These practices work because people commit to them, use them, and derive value from them. If any of that falls apart, then they aren’t working anymore.
If there are some people who aren’t participating or have a bad attitude, find out why. If the approach isn’t perceived as valuable by the team using it then something has to change. If it’s too heavy for a particular group – make it lighter. If there is something people are doing that isn’t useful to anyone, stop doing it. If you keep running into the same problems, arguments, pitfalls, then take a minute and try to design a process solution to prevent it. Get the group involved and make a change.
I think that the development and mutation of the process has to be a group democratic effort because it only works if everyone works with it—but when starting it’s a great idea to pick up a book or an article and work from a formal method. It’s easier to adjust it later, to make things more lightweight. Sometimes it can be hard to see what you need even but its often easy to see what you don’t.
The most important thing I’ve learned about working a bunch of different places with a bunch of different people is that there is no right process for everyone and the best processes are the ones everyone agrees to follow. The respect I was talking about earlier doesn’t just come magically from the process it comes from people respecting each other enough to use the process, whatever it may be.