When I first started working in the software industry 9 years ago, process was all the rage. All the books were about requirements, specifications, defect tracking, metrics, and project estimation. A few years ago, I went to a PNSQC conference where several software QA gurus (imo) were present and a huge backlash against process was evident. Of course, all of those guys were consultants and had been for quite some time. It is a lot easier to be a guru when you work for yourself, swoop in and tell companies what to do, then swoop out. It is also much easier to be the person at the top who dictates and controls the process or lack-thereof. The perspective of a worker bee, who has to get tasks done within the dictated framework, is a bit different and is something I don’t hear addressed often in the ongoing debate around process.
I have worked in both environments. I’ve worked in formal over-processed environments where I spent more time writing, rewriting, reviewing, and maintaining documents than I did building software. I have worked in companies that had no process, and I spent a lot of time guessing at what to work on, guessing at what the customer wanted, and reworking things because I guessed wrong. I have worked at very few places that operate somewhere inbetween, but those projects are the ones I’ve enjoyed the most.
I’m been thinking about this a lot this year as I transition between jobs. Where have I worked during my career. Which jobs do I remember mostly with fondness and which jobs do I still curse the day I set foot in the building.
I’ve worked for a company of ‘control’ where no matter how they wrapped it – they wanted a process where the top few controlled eveything and the rest followed like zombies. As one of the zombies, I found this to be a job that lacked respect and communication. It was very organized though, I followed a checklist of tasks, reported results in a database, and the ‘top’ guys reviewed the database. It was boring as hell!
I’ve worked for a company that balked at the word process and squelched suggestions of any organized communication. With a lot of effort on my part, I was able to forge some relationships that fostered communication and respect, but there was no organization at all. I did a lot of guesswork and rework. It was frustrating as hell!
Both envirnoments claimed they valued collaborative teams, but both places fostered an enviornment of individuals. In the first case, only a few individuals had any impact and the ‘team’ part consisted of doing what the top 3 individuals told you to do. The second place was a group of highly skilled individuals who did what they thought was best from their perspectives. When those pieces were integrated a lot of realizations occurred, a lot of reworking things was done, a lot of frustration was vented, at each other of course – creating such a pleasant environment (not!).
When I think about the projects that I’ve liked best, I realize that it isn’t process or lack there-of that has made the difference – it is respect, communication and organization. The projects that have gone the smoothest or been the most interesting for me are the ones where the project teams – the programmers, designers, QA, artists, and marketing – clicked. By clicked, I mean that we knew what each person was working on, our skills were complimentary, we knew who needed to know what when, and it was rare that anyone was “out of the loop.” I will say that in almost every case, these projects included individuals who had at least a few years experience building software and did not consist (in any area – even QA) of inexperienced (in other words, cheap) labor.
These projects did not require paperwork or process. We didn’t have to sit in a bullpen and overhear each other’s conversations to get information. In some cases, none of the team members were even in the same building (or the same town for that matter). The thing we did have is a clear schedule. The schedule was flexible and often changed, of course. However, everyone had a calendar and everyone synchronized their calendars at least once a week. We had a group of people who respected and understood each other’s roles. There was no tension between programmer and QA – we were on the same team, working toward the same goal. We had an ease of communication that occurred in person, via email, or via instant messaging. In some cases, most of our team communication was in a newsgroup or wiki – a virtual bullpen, only less interruptive and noisy. Everyone had access to all project information at any time.
We didn’t have detailed specs, but we usually had at least a bullet point list of requirements and acces to / good communication with the customers. We also usually discussed and agreed upon the priorities of the requirements and the quality level that needed to be delivered to the customer. This helped us stay on schedule or immediately recognize when we were off-schedule and we clearly knew what could be sacrificed if necessary.
These projects always had a shared bug database of some sort. In most cases, the bug database was very simple. It didn’t calcuate any fancy metrics that showed you to the minute the projected project completion date. The bug databases we used were a simple clear tool for giving the programmers specific ways to reproduce bugs, letting QA know when bugs were fixed, and letting the rest of the team view the open issues as part of project progress assessment.
As a group we did not have a ‘process.’ We did not call ourselves waterfall or agile. We did not do anything in IEEE format. We did not have to sit in specific configurations or go through chains of command to talk to someone else on the team. Our documents did not contain pretty screen shots. There was no sign-off. We didn’t call things ‘sprints’ and the customer could talk to us or change things during development. What we did have was respect, communication and organization. This lead to projects that were flexible, on-schedule, good quality, and successful. These projects also built teams who became synchronous, well-oiled machines. We continued to work together on projects and in some cases even at other companies. New team members integrated well, because the team was knowledgeable, famliliar, and relaxed.
No matter what the development fad of the day is bring respect, communication, and organization to your team. You can do this with or without process and it will contribute to the creation of great products in a pleasant and productive environment.