Married Inc.

There are two levels here: the macro level where the customers/users are involved (at least potentially), and the micro level where only the software development team operates.

At the macro level, I favour agile development. This requires that the customer be available. If you’re a product manager and can “be the customer yourself” there’s no problem, but not everyone is so lucky. Lots of software projects are given at least partial specs that they are required to follow, and getting changes made is often difficult.

At the micro level, my preferred method is to get top programmers and, apart from establishing certain standards such as proper source control, use whatever approach works well for *them*. Top programmers tend not to take kindly to having things forced on them just because the manager likes them. Furthermore, making a big change just because I like it will probably seriously interfere with productivity. The one exception here is that I like everyone to do unit testing: many programmers resist it, but it dramatically reduces the chances of bugs lurking undetected deep down in the code, which “makes it my business” as the manager.

I think I’m probably in the Waterfall camp on this. I’ve been reading alot of about Agile and the Pragmatic did a good article around Extreme Product Management a few months ago. I think part of the reason I’m inclined to use the Waterfall model is the size of the projects and complexity. I find it easier as as a product manager to understand the final product and understand its value. This might be a function of the position/environment I work-in. I’m responsible for the P/L of the product and any feature(s) need to have fairly clear business value. Ultimately I think lets me run more successfull products but maybe not bring them to market as fast as other approaches.

Rohan,
I think Agile development is about letting developers pick the technology and process they want. It only “enforces” certain things, like unit testing and fast, frequent iterations. Beyond that, I can’t fathom what makes sense to impose on a developer from a process standpoint. Have you encountered such restrictions before?

Colin,
With the Waterfall method, aren’t you always worried that you’ll get “it” wrong? Requirement and understanding the problem are all good, but my experience is, large projects included, that the requirements are often misunderstood. Frequently, developers get a 60 page requirements document and fall asleep on page 5. Another common problem is not totally getting what the right solution is until you’re playing with the product a bit. I’ve fallen into this trap numerous times. You think you know what to do, but you really don’t. Agile development is a little uncomfortable sometimes, because you “release” non-perfect, non-complete products. You just have to get used to imperfection. Paradoxically, it leads to perfection in the end.

Malgosia,
You asked “if Agile Development, what flavour?” and gave the example of Scrum. Scrum, Extreme Programming, and other flavours do impose various process things on developers, e.g. XP requires pair programming which many (most?) developers don’t like, and Scrum requires a daily “scrum” meeting, which although much less intrusive is still annoying to some, and may not even be practical if the developers are separated by geography and especially time zones.

Rohan,

I see your point… I agree with “pair programming” being very restrictive. The “scrum” meetings are indeed less so, and probably useful in most situations.

I have to admit that I myself have been guilty of trying to impose “structure” on the development process. I suppose to some degree it matters on the bag of developers you’ve been handed. If you get a group of independent, organized, techically proficient sorts then “hands off” does indeed seem to make most sense. I’ve dealt with unmotivated, mediocre, disorganized sorts as well, and the need to impose process seemed necessary. I suppose it’s the product manager’s job to feel out the dev group and apply the according process/structure. Do you agree?

I think you continually make mistakes but hopefully you’re effort upfront helps prevents them. Not sure its always perfect but its normally good enough.

On the developer strcuture/process, I’m becoming a big proponent of a hands off approach. Utimatley if they don’t deliver there not going to survive and participating in their disfunction ( as Steve Johnson phrases it ) doesn’t really help you understand the market.