The education books still address academic sector without reflecting the reality of the work in developing software, therefore the methodologies that educational books moves around proof ineffectiveness on the ground. The waterfall for example referenced by many educational books as basic methodology to build software and an effective method in many ways. In contrast of the reality most software’s build over this methodology are fail to achieve business goals.
Although the organization of the Waterfall and easy to understand and manage and know the progress of the project, it has many back draws as any problem of any stage will reflected on other stages and present hight risk on the hole project, therefore the client is not involve in the development and he is waiting the final product that may not apply to what he need. Many modification applied on waterfall to solve methodology problems, but the main the problem is in the way of thinking and it cannot be solved until change the mindset.
Assuming the client knows what he wants (this rarely happened), and the developers knows what to build, the waterfall assume that no changes will happened in the middle, therefore it looks like a cannon ball hit once and it may reach to the goal and may not.
In addition to work in this methodology make part of the development team resources ideal in each stage because each one responsible to specific tasks in stages, thus the requirement engineer gather the requirements while the developer and analyst and tester are waiting and etc. Further each one in the team is task based oriented and he is responsible to his task not the hole project, thus unassigned tasks have no one to handle and when the project fails each team member assume he is not the responsible because he already make his tasks and carrying brunt on project manager or team leader, the fact everyone is responsible.
However there must complete change of the mindset, thus software engineers pioneers have meet in 2001 and publish the principles for the new mindset of Agile
Principles behind the Agile Manifesto as following:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development.
- Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
you can review the agile manifesto via link published in many languages from here, thus Agile is mindset is not methodology as Waterfall. However many frameworks are build over Agile mindset that follow the main principles. Part of it related to manage the team and how to deliver the product and treat the client (Managerial Frameworks) like Scrum, while the other related to development best practices (Engineering Frameworks) like XP.
In another hand applying agile required decision include management and technical team and starts gradually, therefore the values are clear but it need practice and get used of it.
Therefore we can follow SHU HA RI Aikido Japanese concept that based on follow the rules as it is, and then break the rules, and then has your own rule (be the rule), look like cooking as you can learn how to make specific cooked throw put the same items with specified required quantities, and then you can add more items or modify quantity, and then you can create your own specific cooked. However the same thing happen when you apply Agile.
Hope the blog is useful,
To the next blog
