For many years, those were your choices. But now there is a different choice for IT development – Agile. Calling them methodologies is probably too broad a word. It might be better to refer to them as approaches for doing development, or even philosophies.
There are four general beliefs that light methodologies have in common.
Develop in short cycles. Agile “sprints” usually take no more than 30 days each – or shorter. Partial solutions should be up and running in a very short time, with very tight iterative cycles designed to deliver continually working code that is built up to a final solution.
Value the people. People should be valued and treated with respect. Managers should trust them to do a good job and get out of the way. Agile teams work on a challenging but steady pace that can theoretically be sustained indefinitely.
Involve the client. If you are going to achieve the rapid results, the client must be an integral part of the project team. In fact, they should be assigned full-time and co-locate in the same physical space as the rest of the team.
Strive for simplicity. The basic thought is that if you have a choice between building something in a sophisticated way or a simple way, choose the simple way. Requirements should be simple, design work simple, and the coding techniques should be simple.
Over time, the Agile model has evolved to co-exist along with more traditional thinking of project management and development activities. You can also adopt hybrid mixtures of Agile and more traditional development approaches. This has made the movement more mainstream and safe for most organizations.
Can it work – yes! Can it fail – yes! I have spoken to companies that are highly successful and have cut development times dramatically. I have also spoken to organizations where Agile failed miserably. The bottom line – I think all IT organizations should have Agile projects. All projects are not candidates for Agile, but many are and every organization should probably be doing some Agile work or at least experimenting so that you see how it works.
Copyright © Tom Mochal, TenStep