From Traditional to Agile

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.

What happened in case of any stage problem in Waterfall

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.

Part of modifications on Waterfall to solve problems, i don’t recommend know the details !

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.

Cannon Ball
Wind changes while implement project that may change everything and prevent reach to achieve the main goal

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.

Traditional teams and Agile Teams

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

Meeting of Software Engineers Pioneers to format Agile Principles

Principles behind the Agile Manifesto as following:

  • Welcome changing requirements, even late in development.
  • Continuous attention to technical excellence and good design enhances agility.

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.

The way to change to agile
The way to change to agile

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