Process and The Three Bears: Going for Just Right

There is an interesting rant on O’Reilly Radar about process. The author’s premise is that process is killing the passion for building software in today’s developers, and that some people should be “above process”, free to do almost as they please because they are so talented. Apparently the author believes (or at least implies) that “process” is an all-or-nothing type of deal. You either do all of it, or you do virtually none of it, although they claim they aren’t interested in a “wild west approach”. Part of the premise of the article implies that you only selectively apply processes to people on a team that might need it, and leave some or all of it aside for those that don’t. I won’t go into the author’s apparent misunderstanding of what agile is, and their implication that a minimum set of features determined up front and external deadlines automatically mean a project isn’t agile anymore. The processes aren’t about just what’s right on paper, they have to work in the real world, and they do when used by skilled and motivated people.

For me, using and working with different processes and best-practices is similar to the theme of Goldilocks and the Three Bears: not too much, not too little, but just right. The challenge, though, is finding what is “just right” for your project or product. In some projects, the process needs to be extremely rigorous, because the health and safety or lives of people are involved. In others, you might dial it back a bit, but still have more than other projects because the financial viability of the company, its customers or some part of the national economy is at stake. For some projects, you can get away with very little process, simply because the end result may not be critical, or the failure of it is at best an inconvenience to the user.

The amount of process you choose should have nothing to do with the level of skill and experience of the team members, simply because it’s the product that matters in the end, and the risks associated with failure of that product. So, yes, if you are going to build a real-time software control system that manages the critical functions of an airplane, then test-driven development is important, and you will spend a significant amount of your time writing test cases, and building out all of the test and review infrastructure before you get to the “fun” stuff of the actual end-use software. If you’ve decided to use Scrum, then yes, you will have story editing, daily standups and will manage burn-down charts. You will care about test case and static test code coverage, and part of the code review process will be to remove code that tries to “game” the tools. You do this because, if you don’t, people could die. And it doesn’t matter if the team are people with decades of experience building these systems, or a group doing this more-or-less for the first time, or some combination of the two. Senior people make mistakes, too, and in a situation like this, a mistake could be fatal.

However, if you are building a simple game for the iPhone, then you probably won’t need much process at all, particularly if you’re taking care of design, coding, testing and release management all by yourself. You can still use a few things to make your job easier or to avoid some problems (like static code analysis, and a modicum of unit tests for the more critical pieces), but you don’t have to have a morning standup all by yourself, create personas and stories and tasks and all of that. In a situation like this, the processes are minimal to virtually non-existent, but that’s acceptable because of the nature of the project and the risks associated with failure.

Yes, there will be times where management or other senior staff will impose more process that is necessary for a project. Smart management will listen to a diverse group of voices, and make a rational and intelligent decision about what processes to adapt, knowing they have to balance the risk of the project and end-product with the risk of losing or breaking a good team. Smart team members will recognize that, in some cases, some process is necessary to help manage the risks. Sadly, not all people are smart, and some will impose too much, simply because they think “if some is good, more is better”. Others will refuse to follow any process without any cogent reasons other that “it stifles my creativity”. As with everything, there is a balance, and responsible and intelligent people can usually find the right balance.

This O’Reilly article isn’t the first time I’ve heard people rail against process, claiming all sorts of “bad things” are going to happen in terms of morale and motivation. While the author in this case is someone with a long resume and a lot of experience, I’ve also heard it from people relatively new to the business. This so-called “plea for sanity” is not restricted to senior curmudgeons. There are, and always will be, varying reactions to process. I’m a fan of using as little as you can get away with. I’ve worked with others that believe that the process is the most important part, almost wilfully overlooking the fact that a shipping product is what pays the bills, not the process that got it there. Most people I’ve worked with typically accept that some process is necessary, and like me, would like to have as little as needed. Like a product that requires a minimally viable feature set, I’m a fan of picking the minimally viable level of process appropriate to the job at hand. Goldilocks was on the correct path: you want “just right”.


One thought on “Process and The Three Bears: Going for Just Right

  1. Hi Geoff,

    I’ve lived the whole scrum thing over and over and I’m not interested. It works just fine in a factory where you’re pumping out feature after feature, but if you’re part of a small capable group of people that build fantastic software and not necessarily a tonne of it, I think adding big “P” process gets in the way.

    There’s a place for it to be sure, just nowhere near the place I want to be.

Comments are closed.