6. Agile and Water Fall methodology

[1] Water Fall methodology is rigid regarding handing-off documents from one department to the other department in order to trigger a step.

For example, design departments must complete documents and officially handing off to testing departments to test codes or system formally.

This way creates slow learning curve in the test departments. However, they had produced good documents to read.

[2] Agile methodology is based on team meetings and rarely created good documents. They can transfer knowledge quickly within team members. However they would end up in explaining the same things over and over again to outsiders.

If a member quit job, a new comer would have hard time to catch up or ask same/basic questions to existing members.

[3] Each methodology has its good points. However I would combine their strengths.

* Document must be relatively good to reduce "asking questions" by other teams. I hate to answer the same questions day after day. I wrote detailed documents, so I was free to do other stuff.

* Invite a tester to some key design meetings with high level documents to make testers familiar with incoming products or features. Tester could provide some feedback as early validation. Btw, not all testers are familiar with too technical details.

* Team meetings regularly or occasionally for team members to exchange ideas or trouble shooting tips. It's not really for progress reporting period.

* Tasks must be clearly assigned to each team member.

* Managers and top boss like time estimate and project plans. However getting "time update and progress update every day" would slow down resolving key issues.

[4] Dynamic team

* we should organize in pool of resources or a department. However team member should be flexible in taking any tasks assigned. In the end, we have a multi-tasking pool.

* This way would help company to handle staff transferred to another department or leaving the company.

[5] Having software development process implemented is a good thing as team members know what to do and be organized. However, heavily process implemented would slow down development time.

* December 27, 2017: Agile used "User Story" with 1-2 lines of text plus a series of conversation.

Let's say each conversation meeting requires 0.5 hour - 1 hour of talk, that would consume around 2 hours of each participants for a series of meetings. However, future team members would request for similar "conversation" in order to understand the features to further enhance the products.

In brief, the author should have spent those 2 hours to write a good document or specification. This would save many hours of meetings for the current and future projects.

* January 29, 2018: "Scrum which is a specialized agile method, or we can say specialized Incremental Development process uses the term Sprint for its iterations, that is one development cycle in Scrum is called a Sprint. Sprint is Scrum specific, hence Sprint is iteration but not all forms of Iterations are Sprints."

This agile method is also borrowed from Water Fall methodology. We called those iterations "incremental releases". Of course, developers must study the whole system to make each release independent from each other. This would optimize development work, tests, etc.

* "Definition of Done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added steps allows the team to focus on what must be completed in order to build software while eliminating wasteful activities that only complicate software development efforts."

This task is also a common task in Water Fall methodology. All tasks and associated resources must be planned in advance. Based on documentation or technical specification, all development and test activities would be carried out effectively with high quality.

(Managers) QA & developers would come together to review outstanding bugs before deciding to fix or postpone to next phase before an official release of products to market.

* Those supported or promoted agile methodology as a huge invention just inflated themselves. They took things from another methodology and renamed those as GREAT INVENTION from agile.