As for the cases of failure, the answer is overwhelmingly, "of course it didn’t work; the project didn’t have enough good people."
This is of course followed with:
Good people can build good software no matter what methodology they use.
I think though that one of the things they miss that agile gives you the opportunity to do is fail fast. This is a tremendous advantage in helping predict paths features that customers won't find useful and to also determine when a particular technical path is the wrong way. But knowing this, if you decided you need to scale or need a platform, you are talking now of a major undertaking that won't really fit in the "Agile" world.
So if I were to say what the best software development process would be, I have to say that it has to be something that results in quick iterations for the design and experiment phase which would be followed by a planning process to convert this prototype into something becomes maintainable and meets more rigorous production requirements. Maintainability is key. Along with good documentation.
2 comments:
I learned with Webstore that it is absolutely all about the people, as I watched people unable to cope with change abuse agile to meet their personal comfort zone.
I've come to the conclusion that *the* process doesn't matter, so long as there is *a* process.
Yep, totally agree. To be honest, it would be interesting to see if instead of a framework for a process, someone could put together a list of objectives of implementing a process...
1) New employees can come up to speed in less than a month
2) All development is documented functionally and technically
3) All development has individual tests as well as system regression tests....
This sounds like something I should post on later... maybe make it a choose your own adventure where you select the criteria and then select various ways you can accomplish those goals. Maybe make it expandable, say with a wiki....
Post a Comment