A client recently posed this question (and 4 others) to us - the internal discussion regarding this question is interesting ...
[AD: ]
I think there is likely a range of projects and a blend of approaches that would suit. For example I did a 20+ system solution and the approach is way different from an enhancement to a single system project.
[AB: ]
Most the stuff I have seen here is a waterfall/iterative approach... i.e. lets see how many times we can fall down the rapids... The Agile approach doesn't work that well as the upfront documentation requirements for funding and skill base of designer/developers probably isn't good enough for this.
[SM:]
a. I’d develop a table of basic indicators:
iv. Size of development team
v. Experience
vi. Length of development
vii. Amount of new technologies to be used (new to organisation, new to team)
viii. Required Longevity of solution
b. Then develop guidelines according to the powerpoint slides picture.
[JE: ]
The Capability of performing the job using the chosen methodology - It’s all well and good to choose a methodology, but if your team doesn’t buy into it, or has no experience in it then you’re going to have to get over the hurdle of applying it. The agile methods in particular recommend that you don’t use them without team and client buy-in, and some experience before hand. I personally wouldn’t attempt an agile project with a team I hadn’t worked with before. I also wouldn’t attempt a project if I couldn’t convince the team that it was possible to succeed using the chosen methodology.
Appropriate process to the state of the requirements and environment, availability of staff and attitude of staff to a given methodology - Following on from the first point, certain methodologies excel in a given circumstance. Agile methodologies are good at coping with unknown or changing requirements but aren’t necessary if the requirement is well understood and documented up front i.e. in the case of a system rebuild in a new environment / platform. Since this tends to be the case in large commercial organizations, I would expect an iterative/incremental delivery based development process would suit most organisations most often.
Reporting / Legislative requirements - Obviously if you have a legal requirement for a certain level of documentation and process, you need to make sure your process complies.
Technology - The enterprise architects / domain architects should have a high level idea of which technologies and platforms are appropriate and approved for use within the organisation. This should include the impact of legacy platforms on new construction. This information should be fed to the solution architects as an input, but there should also be the facility for the technical staff at the lower level to push back in situations where more appropriate or newer technology is available and known to the solution / application architects. There should also be scope at the beginning of a project to do research into the appropriate high-level design. The presence of an EA team and / or a centre of excellence in particular technologies can help smooth out this process. Of course, there are also political aspects to the technology choice – what are the staff familiar with, which vendors does the organisation have an existing relationship with, etc.
[SW:]
I find that is driven by the customer/sponsor of the project and the requirements. If the customer doesn't buy into Agile then they won't support its success. You can use Agile techniques in Waterfall projects. I would think a greenfields project is more suited to Agile and transformations/system rewrites would handle waterfall - ie. stability of the requirements.
[LC: ]
Each approach has its strengths and weaknesses. Each is geared towards certain project types and its suitability also depends on the interaction style between business and delivery teams. The most important of all is the commitment of everyone to follow the process and the flexibility to adapt the process when necessary.
Carl Rogers - Principal Consultant & Process Development Architect