there are a lot of good practices in processes such as RUP, OpenUP, Scrum, Agile Modeling, XP, and if you follow those processes, you will probably find that you are more effective in your development, hence saving money.
But transitioning to a process is often seen as a huge and expensive undertaking. How long time will it take for my team to learn how to follow RUP? How costly will it be?
What we tried to accomplish with the book is to provide you with 20 practices, and for each practice, we describe how you can incrementally adopt that practice. Maybe you are at the basic level, and you would like to go to the intermediate level. You now how a very specific target for process improvement allowing you to improve in an area where you feel you need to improve, without having to take on a lot of cost, since the associated organiztional change is small.
In the book, we describe a framework (overall approach) for how you can leverage these practices to take on this type of incremental improvement, and how to identify the practices your organization should imorove first (what is right for your organization may not be right for the next organization). So, we think that if you use the book, you will more easily find low-hanging fruits for process improvements, allowing you to incrementally improve your process, and hence incremetally hpefully improve the software economics of your development organization.
Now, the book is a compliement to using normal mentors and trainers, and for using processes such as RUP and OpenUP. The goal has not been to replace these things, we do not describe all the practices in the depth we describe them in e.g. RUP, we do not provide templates, we do not replace the need for training, we do not provide tool-specific guidance....
I can't speak for the book, but I think that Agile Software Development reduces costs in a number of ways:
I agree with Per that some of the practices directly reduce costs. Test Driven Development, for example, radically reduces the number of bugs you introduce in the software, and thereby significantly reduces the amount of time you need to spend debugging.
Additionally, being quite humane approaches to software development, Agile approaches often lead to better motivated teams. I hope it's no secret that better motivated teams are more effective.
Last but not least, Agile practices do away with a lot of waste in software development. And I'm not only talking about tons of documents that are created but never used.
It is known that typically more than half the features of a software system are never or seldom used. It's not hard to imagine that for most of those it would have saved costs to not implement them.
Why are they implemented? Mostly, I think, because people don't know what they need, let alone what they will need in, say, a year from now. But when we tell them that they need to come up with their requirements now, and that it will be costly to change them later, we force them to come up with all those features they actually aren't sure they will really need, just in case.
Agile Software Development approaches change that - we only develop the set of most important features and then show them to the users to try them. Then they can learn from that experience and decide what else they need. We tell them that, as long as a feature isn't yet implemented, changing it or exchanging it for something totally different costs near to nothing. That way we dramatically improve the probability that the final system will really contain all important features, and we don't waste much time on features that aren't of use to anyone.
One more thing that doesn't reduce cost directly, but increases income, is that Agile teams work on having a releasable system from early on. If a system with the most important features implemented can be installed and used in a couple of weeks instead of months or years, we get earlier and more return for our investment.
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
passwords must contain 14 characters, a number, punctuation, a small bird, a bit of cheese and a tiny ad.
professionally read, modify and write PDF files from Java