What's your METHODOLOGY?

How do you organize development to reliably meet your goals?

Usually, we all develop with an approach that can be charitably characterized as pragmatic, and not-so-charitably as somnolent. Most organizations develop the way they've always developed, with very little introspection into how they do their thing, why they do it that way, or how they might improve.

It's worthwhile to see if you can clearly describe your development methodology, just as it is useful to design your product before you build it.

I've been privileged to work in many organizations. They've run the gamut from strictly waterfall, with formal gates, reviews and signoffs; to completely ad-hoc and unstructured. What works in a particular group, I find, is largely determined by the culture of that group. A company selling into the staid, risk-averse world of telecom or storage is likely to take their time getting the designs right, the Ts crossed and the Is dotted. In contrast, a purely-software organization selling a Mere App may find themselves proceeding in a more Agile fashion, with constant integration and regular, frequent releases.

Of course, these are generalizations and are as correct as generalizations often are. Exceptions abound. The interesting point is that each approach has its advantages and disadvantages, and each has valuable practices to offer the other.

I like to develop in a more agile fashion. The source is continuously integrated; the builds do not break. On the other hand, I have learned that significant time spent on design and up-front testing (unit-, system-, and stress-) is time well-spent in the grand scheme of things, and will help avoid issues in the product further on down the road. The up-front focus needs to be reinforced. We all (me included) have the tendency to want to set fingers to keyboard too quickly :)

I haven't worked in a purely Agile shop; it seems to me to be more appropriate for pure software, and most appropriate for online applications rather than something downloaded and used locally by users. It's certainly inappropriate for long-term development of items such as chips (although it could well work for FPGAs). It seems to me that Agile, without appropriate discipline, could descend into Chaotic.

On the other hand, the classical waterfall model seems way slow for today's market, and its lack of constant feedback from users is a clear weakness.

I think my preferred methodology is a combination: not pure Agile, but using aspects of it, particularly the focus on sprints to numerous smaller goals on the road to "completion".

Perhaps the most important lesson, though, is to think about how we do what we do, and constantly optimize--just like tuning software, tune your process regularly.