The story of one fakapa or why iteration is a necessary, but not sufficient condition for Agile

This article deals with iteration, which includes all stages of software development, from the inception of the idea to the release of the release. Not to be confused with the iterations that are used at the implementation stage in a cascade waterfall, the plan of such iterations is based on the already well-developed TK and architecture, and at the end of each iteration there is no feedback collection and requirements changes.

A small excursus: a young and small company, successfully applying Agile-approaches and Scrum in particular, led the entire software development by one department, divided into several Scrum-teams. Each Scrum-team developed its product and everything was fine.

The threat came from no waiting. In parallel with the development of software, the analytics department was formed and developed. At first, analysts were busy with methodological documents and had almost no influence on software development. Methodological documents were developed by request of one large software company. Development with them was carried out so tightly that our analysts and the management of our company could not fail to know how everything worked out for them. And everything was arranged according to the classic cascade waterfall. The software company was so large and authoritative that the management of our company took everything on faith and decided to implement their approach to development.

At first, perhaps, not understanding why, and later explaining this with the need for customized development, the company’s management adopted a dangerous cocktail of the following decisions:

• Instead of the role of the Product Owner, we need a Principal Analyst;
• Development teams are strictly prohibited to directly interact with the customer. Only analysts have this right;
• The development team should receive all tasks from the team of analysts. The results of these tasks should be surrendered to him;
• If Agile is so needed by developers, then let them use Agile inside, we will even leave the iterations and analysts will transfer to the developers not all TK entirely, but small portions of the requirements, adjusted to the latest demonstration of the test version of the program to the customer;
• The design of business processes, domain model and user interface models are engaged in analytics. They make it iterations. At transfer of each portion of requirements to developers, the documentation corresponding to them also is transferred.

All this led to the fact that two projects that could be done for the quarter, were made almost a year and never reached the first release for production. This is due to the fact that:

• From iteration to iteration, architectural solutions had to be changed, which sometimes led to very large refactoring and throwing large pieces of code into the basket. The developers did not see the whole picture, they were cut off from the customer, analysts did not participate in the process and did not see the whole TK. Analysts, not knowing the implementation, also could not foresee changes in architectural solutions;
• Often, simple things analysts have done incredibly difficult, partly because of the small experience in the development, and partly because of the new motto of the company “We solve complex problems!”;
• The chief analyst became a mega star and demanded a special approach to his person;
• Developers and how strange analysts were demotivated. Often conflicts flared up. For example, analysts began to complain that developers are asking a lot of questions and this greatly distracts them from current tasks. After the chief analyst complained to the authorities, it was decided that programmers could ask questions only during the transfer of the task, after the task was accepted, questions could not be asked!
• There were big problems with project manageability. Nobody wanted to take full responsibility for the project as a whole (including the project manager).

Total

The presence of iteration did not save these projects, but only aggravated the situation. As is well known, iterative development allows for a timely change in the direction of product development. This is achieved by releasing a release at the end of each iteration, as well as collecting and analyzing feedback. The change of direction in the iterative development is quite a frequent phenomenon, so there is no point in writing a detailed statement of work, it will become obsolete faster than being written. The absence of TK is compensated by a single information space of the team, in which knowledge is accumulated in small portions, thanks to the joint efforts of the whole team. Thus, iterativeness is a necessary, but not sufficient condition for Agile development, at least there should be a single development team (system analysts, designers, architects, programmers, testers)!
')
Cascade Falls and Agile are excellent software development methodologies themselves. Each of them has its pros and cons, according to which you can make the right choice in favor of one of them for each project. If you have a fixed budget, terms and requirements, then use a cascade waterfall. If you have no deadlines (the product develops continuously throughout the entire life cycle) and there is no need for strict fixation of requirements, then use Agile. But in no case do not mix these two approaches!