My other question is, in what cases you should use agile methods? What happens when a team is already working with a different approach? Is it safe or good to change in the middle of a development process?
[Edit to provide meaningful topic] [ November 07, 2006: Message edited by: David O'Meara ]
Switching to an Agile approach in one big sweep can be done, and can be a good thing to do. It also costs a lot of resources, so whether it's a good thing to do in the middle of a project would depend on how well the project is currently going. Normally, I wouldn't want to do it, but when the project is in big trouble anyway, it might be the best way to get it back on track.
On the other hand, a process shouldn't be fixed, anyway. If you start a project with a process, and still work exactly the same way at the end of the project, you are missing a lot of learning experiences.
So a good team should always regularly reflect on its process during the curse of the project and adjust it accordingly, no matter what base process they are using.
If you do that, learning about Lean Software Development, or any other Agile or non-Agile process, will do at least two things for you:
- it will give you a new way to think about, a new perspective from which to look onto your project, hopefully generating new insights, and
- it will enhance your "bag of tricks", from which you can select when you encounter certain problems.
Does that help?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
When it comes right down to it, Lean is a state of mind, a way of looking at things. One of the most important things that Lean brings to software development is the idea that testing is not, and should never be, after-the-fact. Testing at all levels - from unit testing to continuous integration with a 10 minute test harness to longer acceptance test harnesses - should be done as an integral part of development, not after it is done.
It is never a bad idea to start moving testing forward as soon as you realize that it does not belong at the end of the development process. It is never a bad idea to think hard and act aggressively to reduce the time spent in regression testing so that it becomes feasible to implement small feature sets instead of big batches of features.
But changing your entire process is another matter. One frequent good reason we hear for changing to short iterations is that longer iterations are simply not doing the job. As crunch time comes and the work is not done, staged deployment can look very attractive.
Another variable would be whether or not you have intact teams that move together from one problem to the next. Such a team can determine when it wants to switch processes and how to go about it. Without intact teams, changing to a new process is much more difficult because people will have to figure out how to work together at the same time as they attempt a new way of doing things - always a challenge.
This is just a long way of saying that situations differ. But you can always learn and implement lean principles at any time.
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
I will suppress my every urge. But not this shameless plug: