SDLC Methodologies - Real world Experiences appreciated

[jirvan]

Hey guys,

I am at the beginning of starting a very large development project at work that will probably span about 24 to 36 months of development to full maturity. The company is very focused on constantly improving management practices, measuring success through metrics, and QC/Compliance has a huge role through all aspects of the company (We are in the Aerospace industry so you can imagine the diverse requirements our customers demand of us). Up till now, the software development projects I have managed have been small with durations of 45 to 60 days and were usually part of a much bigger IT project. Using a standard PMI project management methodology along with a standard Plan/Design/Code/Test/Deploy SDLC has been successful at that scale but I fear this project is just to large to follow that approach.

So I grabbed a book this weekend on Agile Software Development that uses the XP model and started digging in. This model seems sound, and I really like the philosophy behind it, except I fear that the approach we are taking (Smaller team with longer project duration) will not fit the model. Pair Programming is going to be tough to pull off. Also our company is just to small (~100 total employees across 5 sites) to have any semblance of a committed On-Site customer.

We are a Lean shop and practice it in most operational areas of our company. I have started to look at the Lean methodology but still need to spend more time reading before I comment on it's viability in this project. Fortunately, if it doesn't fit, our CEO is very progressive and does not require me to apply Lean to my team if it does not fit our needs.

We have just begun collecting functional business requirements from our users and I am still hiring the development team so If I am going to do this I need to start laying the framework now. I've kept up with this site and realize there are a lot of experienced developers here in the community. So I thought I would ask if any of you could offer any suggestions, real world experiences with different models or methodologies, or general expert feedback on this topic. I would really appreciate any feedback.

J

[xavier]

You don't need pair programming to use agile methodologies.

I'd also say that unless you expect your requirements to change significantly through the project (possibly as a result of stakeholder input during periodic review/testing), then standard waterfall still works just fine too. Agile is nice if you are not entirely sure up front what it is you will be building (i.e. the requirement specifics will be largely unknown until you can produce prototypes, etc).

Without knowing more about what you intend to develop, it would be hard to offer more than that.

[jirvan]

You don't need pair programming to use agile methodologies.

I'd also say that unless you expect your requirements to change significantly through the project

I understand that pair programming is not a requirement for agile methodologies, I believe that is more of an XP function actually. Which is why I am here asking for input and RW experiences. If I research every single methodology/process pairing I'll be next year starting the initial implementation of the process.

On your other comment, yes I expect this project to change drastically through the next 3 years. That's one of the reasons why I am looking at other systems besides waterfall. I need more flexibility in the process, I would like to get away from the traditional standards of project success measurements, and I need a better method of managing priority shifts from senior management (which happen about every 30 to 60 days).

[xavier]

OK so my experience with agile methods (SCRUM) in multiple companies has been that if you don't have complete buy-in from the management, and that they also understand what agile is, that you will end up with waterfall anyway, just tracking tasks on index cards instead of in Project. The reason is that unless the management understands that the actual definition of milestone deliverables can change because of discoveries during the process, that you will be signing up for a static set of features delivered by a certain date -- this is anathema to agile. Agile depends on the deliverables changing to reflect the changing requirements and discoveries -- the problem is that managers live by "if it can be measured, it can be managed" and dates and features are something that can be measured.

So the biggest hurdle is educating your managers on what to expect and how the process works -- it will likely be foreign to how they are used to operating, which is essentially long-term planning by feature implementation.

[jirvan]

So the biggest hurdle is educating your managers on what to expect and how the process works -- it will likely be foreign to how they are used to operating, which is essentially long-term planning by feature implementation.

</sarcasm>Ah, getting management to understand a technical process/deliverable, one of my favorites. </sarcasm off>

Seriously, thanks for the tip. I just found an active Yahoo group on the topic at work. If you are interested in this here is the link

http://tech.groups.yahoo.com/group/leanagile/

If anyone else has insight I would appreciate it. Otherwise I will continue my research over there since it is more topical.

Thanks,
J

[xavier]

Good luck -- in retrospect, I could have boiled all that blather down to "management likes to be able to plan by feature and date, and hard-and-fast planning on those terms is pretty much counter to any agile method I'm familiar with"