I guess everybody understands how improvements are important in this fast changing IT world.
Have you heard the word Kaizen? It stands for "improvement", or "change for the better". This word came to business from Japanese and refers to approaches and practices that focus upon continuous improvement of processes in manufacturing, engineering, and business management. Especially it's very important that this philosophy can be applied to software development process.
Let's consider the usual waterfall model of software development. In this case customer comes to the development company (e.g. TYPO3 agency) with the project and company starts project specification process. Some times customer comes with more or less ready specification. In case of web projects it can be initial design with different type of pages for the future website.
After project specification is ready development company starts planning new project. Customer gets time estimation. By that time project will be ready. Let's say it will be finished in 6 months. After customer received this estimation he goes away to return in 6 months and developers start building the project.
What happens after 6 months? Let's imagine that project is ready as it's specified in documentation and ready to be shown to the customer. Most likely that after project demonstration customer would like to add or change something in the project to improve it. It can be user interface or some business logic. It's good when these changes are small, on the other hand it can happen that customer after demonstration absolutely changes his mind. E.g. from the beginning customer ordered CRM system and now he sees that actually he needs ECM.
In extremely fast changing IT world in 6 months changes a lot. In case of this customer he understands that he really needs completely different software and he can understand this only after 6 months of work. And this is error in requirements which is located on the very early stage of planning. Errors can happen even on the other stages like project architecture design, UI design, development, etc. Some of these all errors will be found only after 6 months of development. Mistakes that were done on very early stages (planning stages) are most expensive to fix.
In our example client spent money and development company time and resources for building not needed product. Of cause this is ultimate example, on the other hand there are such examples in my experience.
Agile methodology deeply supports this Kaizen philosophy. The scheme for this support is the following: we plan, we do, we receive some feedback on what is done and based on this feedback we improve. This circle is implemented in SCRUM by several SCRUM events.
In next posts we will cover each step in the scheme described above in terms of Agile methodology.
Please spend one minute to answer to our poll on usage of Agile methods in TYPO3 projects: https://www.facebook.com/questions/213795562090323/
No comments yet. Be the first to comment on this!