Which SDLC methodology to use?

Question

I'm moving to a new company where I will be the project manager/developer/tester/release management etc... for the projects I work on. Basically I'm everything. The programming manager doesn't care what you do as long as you deliver a product. So, I need to develop how I'm going to go about managing my projects. I also need to follow some methodology so that I'm not learning bad habits.

So, basically what kind of methodology should I use? Is there some resources out there I might look at for the situation I'm going to be in? Should I adopt agile or scrum? These projects will be fairly small.

As of right now, here is how I plan on doing things. Please comment on any of the following.

1. gather requirements
2. analyze requirements
3. fix/change requirements...start over at 1
4. design
5. development
6. unit testing
7. load testing
8. user acceptance testing/ fix bugs
9. move to production

Answer 1

I wonder if you need to enter the new company with your own brand new strategy, or if you can use whatever they are doing currently in order to get a feel for the place. From there, you can keep what works and change what is inefficient.

Here is a resource to help you remember the different Software Development Methodologies at your disposal.

Answer 2

I think it would be very damaging to go into a new company and attempt to implement development methodology 'x' without first understanding how the people that you will be managing currently develop software and deliver projects.
You cannot expect to walk in as a new manager and tell the guys doing the work that from tomorrow they are all doing things differently because you say so.
You are going to need to look at what they are doing now, what works, what doesn't work and then once you have earned a little trust and respect from the people you will be managing and have seen how they like to work you can start to point out where you think the holes are in what they are doing.
Ideally you should help them come to the conclusion that they need process 'a' or procedure 'b'. If they feel ownership and its bottom-up development of the processes then you might have a chance of them being followed. Top-down decree of a new process (now matter how good an evangelist you are for whatever methodology you choose) has a very low chance of success.

Answer 3

This may sound cliche, however, in my experience through being in a situation like yours and what I have learnt from academia, choosing a methodology is very difficult - the biggest two problems being, you can't really evaluate whether a methodology is appropriate until you have used it and gained experience and a successful use of a methodology is highly dependant on you and your surroundings - just because your boss is hands-off, what is the rest of the staff like? Have they been burned with poor IT projects before, what is the average competency / acceptance level of IT?

From my experience working in small teams;

Linear Methodologies (SSADM etc.)

Advantages

• Normally simple, rigid structure to follow (as detailed in your question)
• High levels of verbosity and ceremony = happy management (they normally think in phases/milestones that can be 'signed off')

Disadvantages

• Inherently averse to change late on (without cost / time)

Iterative Methodologies (RAD, UP)

Advantages

• Values constant change and improvement Delivering work in small but useful parts (happy management)

Disadvantages

• Requires self-discipline to follow what may seem 'un-natural' at first.
• Management's adversity to what may be perceived as 'new/risky'

How does this apply to you? It depends on how you feel you can manage yourself like this (have you had previous experience in being a sole developer like this?) - I personally find it very difficult to stick to a strict methodology once I have lost interest.

Although you mentioned that your management is quite hands off - this could actually be an issue - without someone taking a role in oversight - self-motivation may drop and I have found hands-off people tend to come down on you harder when the proverbial hits the fan!

You mentioned you didn't want to get into bad habits, this sounds like you may be suited to a more regimented methodology - so you may find the methodology I use quite often, also good. OpenUP is an iterative, but moderately documented methodology, with the cherry on the top that means you can customise the methodology to your needs - for example, out of the box it IS too heavyweight for a one man band - however it does have sound advice.

Requirements

I can't stress how much to document as much as you can and keep a good version control system (even if it means you create a new version of your word documents every significant change).

Embrace 'agile' analysis methods - whiteboards are your friend.

Also consider using rapid prototyping tools if are able to get time to use them with your end-users

Design & implementation

I would have to say that this is quite dependant on your tool set / platform. Just use tools you are comfortable with. And use Source Control.

Testing

If it all possible get a development and live system, this is even more important if you are doing something iterative, push your delivered parts of the code onto live while you play on development.

UAT

A minefield, you need to make sure that you don't get swamped with 'this button is 1 pixel too far to the right' kind of problems and focus on the core problems, prioritise them on complexity and time they will take to fix.

And my final piece - everyone hates it, everyone should do it, everyone says they will, nobody does - PLANNING. Every post-mortem if mine has been plan better.

Answer 4

What you are proposing is a waterfall schedule. There's enough threads around that will teach you why most organizations have shifted away from it in the past few years.

Here's another thought. Your attempts to implement a methodology in which you take on all the roles (PM, BA, Developer, QA, Support, Release) is bound for failure. You really can't do all of those jobs. There just isn't enough time in the day. Hey I know, as a team lead I get people pulling me in all those directions everyday :)

Furthermore, even if you could do all of those, you won't be able to them all very well. They are separate roles for a reason and they each provide a check and balance on one another. For example, you'll end up taking shortcuts as a developer that you'll conveniently not verify as the analyst. As QA, you'll only check the path through the application that you developed. And frankly, if you are a developer, you are going to be rushing through everything but the development because it is BORING.

I really would question the company's commitment if they are only hiring one person in Technology.

Answer 5

Most agile processes are for small teams working on a project - seems like you'll be a one-person team...so, you'll need to select a methodology for that. To be successful, I highly recommend:

• getting to know your sponsors, users and peers first - these are the people that will determine how successful you are and provide the help OR roadblocks
• get deep into the business - know what it is you're working on and why
• get deep into the environment, know how things are currently being done, what works and what doesn't
• set goals, but take short steps getting there (be ready to change your approach OR the goals as needed)
• don't worry about how things are currently done (understand why)